IMPOWER

Microsoft publishes '=IMPOWER("2+3i", 3)' with the result -46+9.00000000000001i, and its own Description column concedes the exact answer in parentheses: "(-46 + 9i)". Both are asserted correctly by the same derivation, and the gap between them is the point of this case. Exactly: (2+3i)^3 = 8 + 36i + 54i^2 + 27i^3 = 8 + 36i - 54 - 27i = -46 + 9i, an exact Gaussian integer. But the page also documents the ALGORITHM -- z^n = r^n(cos(n*theta) + i*sin(n*theta)) with r = sqrt(x^2+y^2) and theta = atan(y/x) -- and that polar route does not land on an integer in double precision: r = sqrt(13) = 3.60555127546398929312 (double: 3.6055512754639891), theta = atan2(3,2) = 0.98279372324732906799 (double: 0.9827937232473291), and the imaginary part evaluates in double precision to 9.000000000000009 rather than 9 -- 9.000000000000007 by the r^n*sin(n*theta) route, 9.000000000000009 by exp(n*ln z); both render at 15 significant digits as 9.00000000000001, which is the published digit string. So the published string is not a typo: it is the fingerprint of the documented polar algorithm carried out in IEEE doubles, and reproducing it is what confirms the derivation followed Excel's stated method rather than an algebraic shortcut. 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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.

Exact: z^0 = 1 for every non-zero z, and the polar form gives r^0(cos 0 + i sin 0) = 1 + 0i with no rounding anywhere -- r^0 is exactly 1 for any finite positive r, and cos(0)/sin(0) are exact in IEEE arithmetic. The imaginary part is exactly zero, so the format collapses the result to a bare "1". 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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.

The page documents "Number can be an integer, fractional, or negative", so the negative exponent is a documented branch rather than an edge case. Derived exactly: (2+3i)^-1 = 1/(2+3i) = (2-3i)/((2+3i)(2-3i)) = (2-3i)/13, i.e. 2/13 - (3/13)i. In exact rational arithmetic 2/13 = 0.153846153846153846... and 3/13 = 0.230769230769230769..., which round at 15 significant digits to 0.153846153846154 and 0.230769230769231. The double-precision polar route gives the same two doubles. 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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.

The page documents that number may be fractional. The value asserted is Microsoft's OWN published IMSQRT("1+i") result, reused here as a cross-function consistency check: the principal square root and the 1/2 power are the same operation under the documented polar formula (r^0.5 at half the argument), so if the two functions disagree the engine is inconsistent with itself. Derived independently at 40 digits: r = 2^(1/2), theta = pi/4, so the answer is 2^(1/4)(cos(pi/8) + i sin(pi/8)) = 1.0986841134678099660 + 0.45508986056222734130i. 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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: "If number is nonnumeric, IMPOWER returns the #VALUE! error value." The only error branch the IMPOWER page states, and the only one asserted here.

Microsoft publishes '=IMPOWER("2+3i", 3)' with the result -46+9.00000000000001i, and its own Description column concedes the exact answer in parentheses: "(-46 + 9i)". Both are asserted correctly by the same derivation, and the gap between them is the point of this case. Exactly: (2+3i)^3 = 8 + 36i + 54i^2 + 27i^3 = 8 + 36i - 54 - 27i = -46 + 9i, an exact Gaussian integer. But the page also documents the ALGORITHM -- z^n = r^n(cos(n*theta) + i*sin(n*theta)) with r = sqrt(x^2+y^2) and theta = atan(y/x) -- and that polar route does not land on an integer in double precision: r = sqrt(13) = 3.60555127546398929312 (double: 3.6055512754639891), theta = atan2(3,2) = 0.98279372324732906799 (double: 0.9827937232473291), and the imaginary part evaluates in double precision to 9.000000000000009 rather than 9 -- 9.000000000000007 by the r^n*sin(n*theta) route, 9.000000000000009 by exp(n*ln z); both render at 15 significant digits as 9.00000000000001, which is the published digit string. So the published string is not a typo: it is the fingerprint of the documented polar algorithm carried out in IEEE doubles, and reproducing it is what confirms the derivation followed Excel's stated method rather than an algebraic shortcut. 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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.

Exact: z^0 = 1 for every non-zero z, and the polar form gives r^0(cos 0 + i sin 0) = 1 + 0i with no rounding anywhere -- r^0 is exactly 1 for any finite positive r, and cos(0)/sin(0) are exact in IEEE arithmetic. The imaginary part is exactly zero, so the format collapses the result to a bare "1". 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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.

The page documents "Number can be an integer, fractional, or negative", so the negative exponent is a documented branch rather than an edge case. Derived exactly: (2+3i)^-1 = 1/(2+3i) = (2-3i)/((2+3i)(2-3i)) = (2-3i)/13, i.e. 2/13 - (3/13)i. In exact rational arithmetic 2/13 = 0.153846153846153846... and 3/13 = 0.230769230769230769..., which round at 15 significant digits to 0.153846153846154 and 0.230769230769231. The double-precision polar route gives the same two doubles. 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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.

The page documents that number may be fractional. The value asserted is Microsoft's OWN published IMSQRT("1+i") result, reused here as a cross-function consistency check: the principal square root and the 1/2 power are the same operation under the documented polar formula (r^0.5 at half the argument), so if the two functions disagree the engine is inconsistent with itself. Derived independently at 40 digits: r = 2^(1/2), theta = pi/4, so the answer is 2^(1/4)(cos(pi/8) + i sin(pi/8)) = 1.0986841134678099660 + 0.45508986056222734130i. 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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: "If number is nonnumeric, IMPOWER returns the #VALUE! error value." The only error branch the IMPOWER page states, and the only one asserted here.

Microsoft publishes '=IMPOWER("2+3i", 3)' with the result -46+9.00000000000001i, and its own Description column concedes the exact answer in parentheses: "(-46 + 9i)". Both are asserted correctly by the same derivation, and the gap between them is the point of this case. Exactly: (2+3i)^3 = 8 + 36i + 54i^2 + 27i^3 = 8 + 36i - 54 - 27i = -46 + 9i, an exact Gaussian integer. But the page also documents the ALGORITHM -- z^n = r^n(cos(n*theta) + i*sin(n*theta)) with r = sqrt(x^2+y^2) and theta = atan(y/x) -- and that polar route does not land on an integer in double precision: r = sqrt(13) = 3.60555127546398929312 (double: 3.6055512754639891), theta = atan2(3,2) = 0.98279372324732906799 (double: 0.9827937232473291), and the imaginary part evaluates in double precision to 9.000000000000009 rather than 9 -- 9.000000000000007 by the r^n*sin(n*theta) route, 9.000000000000009 by exp(n*ln z); both render at 15 significant digits as 9.00000000000001, which is the published digit string. So the published string is not a typo: it is the fingerprint of the documented polar algorithm carried out in IEEE doubles, and reproducing it is what confirms the derivation followed Excel's stated method rather than an algebraic shortcut. 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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.

Exact: z^0 = 1 for every non-zero z, and the polar form gives r^0(cos 0 + i sin 0) = 1 + 0i with no rounding anywhere -- r^0 is exactly 1 for any finite positive r, and cos(0)/sin(0) are exact in IEEE arithmetic. The imaginary part is exactly zero, so the format collapses the result to a bare "1". 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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.

The page documents "Number can be an integer, fractional, or negative", so the negative exponent is a documented branch rather than an edge case. Derived exactly: (2+3i)^-1 = 1/(2+3i) = (2-3i)/((2+3i)(2-3i)) = (2-3i)/13, i.e. 2/13 - (3/13)i. In exact rational arithmetic 2/13 = 0.153846153846153846... and 3/13 = 0.230769230769230769..., which round at 15 significant digits to 0.153846153846154 and 0.230769230769231. The double-precision polar route gives the same two doubles. 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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.

The page documents that number may be fractional. The value asserted is Microsoft's OWN published IMSQRT("1+i") result, reused here as a cross-function consistency check: the principal square root and the 1/2 power are the same operation under the documented polar formula (r^0.5 at half the argument), so if the two functions disagree the engine is inconsistent with itself. Derived independently at 40 digits: r = 2^(1/2), theta = pi/4, so the answer is 2^(1/4)(cos(pi/8) + i sin(pi/8)) = 1.0986841134678099660 + 0.45508986056222734130i. 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 written as a formatter in Python by batch D and validated against seven independently published Microsoft strings (IMCOS, IMCOSH, IMCOT, IMCSC, IMCSCH, IMEXP, IMLN); batch E re-ran that validation and then extended it, reproducing THIRTEEN MORE published Microsoft strings byte for byte (IMLOG10, IMLOG2, IMPOWER, both IMPRODUCT examples, IMSEC, IMSECH, IMSIN, IMSINH, IMSQRT, IMSUB, IMSUM, IMTAN) before predicting anything -- twenty published strings in all. ONE REFINEMENT BATCH E HAD TO MAKE: batch D fed the formatter the EXACT value computed at 40 digits, which happened to render identically to the IEEE double for all seven of its strings. That is not true here. A spreadsheet engine holds a double, not the exact value, and two of this batch's published strings only come out right if the derivation rounds to the nearest double BEFORE formatting: IMPOWER("2+3i",3) is exactly -46+9i in exact arithmetic but Microsoft publishes -46+9.00000000000001i, which is what exp(3*ln(2+3i)) gives in double precision; and IMSEC("4+3i") has an exact real part of -0.06529402785794704644..., whose 15-digit rounding ends ...47, while the correctly-rounded double -0.065294027857947051 rounds to ...471, which is what Microsoft publishes. So every value in this batch is derived exactly with mpmath at 40 digits, THEN rounded to the double an engine actually holds, THEN formatted. 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: "If number is nonnumeric, IMPOWER returns the #VALUE! error value." The only error branch the IMPOWER page states, and the only one asserted here.