IMCOS

Microsoft publishes '=IMCOS("1+i")' with the result 0.833730025131149-0.988897705762865i. Derived independently with mpmath at 40 digits from cos(x+yi) = cos(x)cosh(y) - i*sin(x)sinh(y), the identity the page renders as an image: the real part is cos(1)cosh(1) = 0.83373002513114904888 and the imaginary part is -sin(1)sinh(1) = -0.98889770576286509638. Rendered through this corpus's independent implementation of Excel's complex-string format, that is byte-identical to Microsoft's published string. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value.

cos(0) = 1 with a zero imaginary part. Asserted as the string "1" because that is what Excel's documented output format produces for a result whose imaginary part vanishes -- not "1+0i". EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value.

Excel documents, on this page specifically: "If inumber is a logical value, IMCOS returns the #VALUE! error value." This is a deliberate refusal to coerce, and it is the sort of guard an engine drops: TRUE coerces to 1 in almost every other numeric context, so an implementation that simply converts its argument to a number computes cos(1) = 0.54030230586814 and returns a plausible answer where Excel raises an error. EXECUTED RESULT, and a SILENT WRONG ANSWER: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return the string "0.54030230586814" -- that is cos(1), i.e. TRUE was coerced to 1 and fed to the function -- where the page documents #VALUE!. The same coercion happens on this batch's IMCOSH, IMCOT, IMCSC and IMCSCH when they are called under their unprefixed names (returning cosh(1), cot(1), csc(1) and csch(1) respectively), so it is one behaviour across the complex family rather than a slip in one function.

Microsoft publishes '=IMCOS("1+i")' with the result 0.833730025131149-0.988897705762865i. Derived independently with mpmath at 40 digits from cos(x+yi) = cos(x)cosh(y) - i*sin(x)sinh(y), the identity the page renders as an image: the real part is cos(1)cosh(1) = 0.83373002513114904888 and the imaginary part is -sin(1)sinh(1) = -0.98889770576286509638. Rendered through this corpus's independent implementation of Excel's complex-string format, that is byte-identical to Microsoft's published string. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value.

cos(0) = 1 with a zero imaginary part. Asserted as the string "1" because that is what Excel's documented output format produces for a result whose imaginary part vanishes -- not "1+0i". EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value.

Excel documents, on this page specifically: "If inumber is a logical value, IMCOS returns the #VALUE! error value." This is a deliberate refusal to coerce, and it is the sort of guard an engine drops: TRUE coerces to 1 in almost every other numeric context, so an implementation that simply converts its argument to a number computes cos(1) = 0.54030230586814 and returns a plausible answer where Excel raises an error. EXECUTED RESULT, and a SILENT WRONG ANSWER: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return the string "0.54030230586814" -- that is cos(1), i.e. TRUE was coerced to 1 and fed to the function -- where the page documents #VALUE!. The same coercion happens on this batch's IMCOSH, IMCOT, IMCSC and IMCSCH when they are called under their unprefixed names (returning cosh(1), cot(1), csc(1) and csch(1) respectively), so it is one behaviour across the complex family rather than a slip in one function.

Microsoft publishes '=IMCOS("1+i")' with the result 0.833730025131149-0.988897705762865i. Derived independently with mpmath at 40 digits from cos(x+yi) = cos(x)cosh(y) - i*sin(x)sinh(y), the identity the page renders as an image: the real part is cos(1)cosh(1) = 0.83373002513114904888 and the imaginary part is -sin(1)sinh(1) = -0.98889770576286509638. Rendered through this corpus's independent implementation of Excel's complex-string format, that is byte-identical to Microsoft's published string. EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value.

cos(0) = 1 with a zero imaginary part. Asserted as the string "1" because that is what Excel's documented output format produces for a result whose imaginary part vanishes -- not "1+0i". EXCEL'S COMPLEX-STRING FORMAT, which this corpus derives rather than assumes: a result is rendered as the real part, then the sign, then the imaginary coefficient followed by the suffix, with each part printed to at most 15 significant digits and trailing zeros stripped; a zero real part is omitted entirely, a zero imaginary part reduces the result to a bare real number, and an imaginary coefficient of exactly 1 or -1 prints as "i" / "-i" with no digit. That rule was not taken on faith -- it was written as a formatter in Python and validated against SEVEN independently published Microsoft strings in this batch alone (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP and IMLN), which it reproduces byte for byte, before being used to predict any value this corpus asserts. String results are compared exactly, so a formatting-only difference (a trailing zero, "1i" for "i", a different digit count) fails the case and is recorded as its own divergence class, separate from a wrong numeric value.

Excel documents, on this page specifically: "If inumber is a logical value, IMCOS returns the #VALUE! error value." This is a deliberate refusal to coerce, and it is the sort of guard an engine drops: TRUE coerces to 1 in almost every other numeric context, so an implementation that simply converts its argument to a number computes cos(1) = 0.54030230586814 and returns a plausible answer where Excel raises an error. EXECUTED RESULT, and a SILENT WRONG ANSWER: all four LibreOffice builds (24.2.0.3, 24.8.7.2, 25.2.0.3, 25.8.7.3) return the string "0.54030230586814" -- that is cos(1), i.e. TRUE was coerced to 1 and fed to the function -- where the page documents #VALUE!. The same coercion happens on this batch's IMCOSH, IMCOT, IMCSC and IMCSCH when they are called under their unprefixed names (returning cosh(1), cot(1), csc(1) and csch(1) respectively), so it is one behaviour across the complex family rather than a slip in one function.