IMSUM

Microsoft publishes '=IMSUM("3+6i","5-2i")' with the result 8+4i. Derived from the identity the page renders as an image, (a+bi) + (c+di) = (a+c) + (b+d)i: 3+5 = 8 and 6-2 = 4. Exact integer arithmetic, so this case tests the addition and the string format and nothing else. 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's syntax is IMSUM(inumber1, [inumber2], ...) and states "Inumber1 is required, subsequent numbers are not", so a single argument is a documented call, not a degenerate one. The sum of one number is that number, and it must come back in Excel's own printed form -- which for a coefficient of exactly 1 is "1+i", the real part printed and the imaginary digit dropped. 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: (1+i) + (2+2i) = 3+3i. The syntax line says "1 to 255 complex numbers to add"; supplying them as a range is the form a real spreadsheet uses, and it exercises the argument-flattening path rather than the literal-parsing one. The two operands are stored as TEXT cells, which is what the x+yi format means in practice. 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's description says "in x + yi or x + yj text format". The arithmetic is identical to Microsoft's published example -- 8 and 4 -- and the answer must carry the same suffix it was given. 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.

Microsoft publishes '=IMSUM("3+6i","5-2i")' with the result 8+4i. Derived from the identity the page renders as an image, (a+bi) + (c+di) = (a+c) + (b+d)i: 3+5 = 8 and 6-2 = 4. Exact integer arithmetic, so this case tests the addition and the string format and nothing else. 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's syntax is IMSUM(inumber1, [inumber2], ...) and states "Inumber1 is required, subsequent numbers are not", so a single argument is a documented call, not a degenerate one. The sum of one number is that number, and it must come back in Excel's own printed form -- which for a coefficient of exactly 1 is "1+i", the real part printed and the imaginary digit dropped. 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: (1+i) + (2+2i) = 3+3i. The syntax line says "1 to 255 complex numbers to add"; supplying them as a range is the form a real spreadsheet uses, and it exercises the argument-flattening path rather than the literal-parsing one. The two operands are stored as TEXT cells, which is what the x+yi format means in practice. 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's description says "in x + yi or x + yj text format". The arithmetic is identical to Microsoft's published example -- 8 and 4 -- and the answer must carry the same suffix it was given. 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.

Microsoft publishes '=IMSUM("3+6i","5-2i")' with the result 8+4i. Derived from the identity the page renders as an image, (a+bi) + (c+di) = (a+c) + (b+d)i: 3+5 = 8 and 6-2 = 4. Exact integer arithmetic, so this case tests the addition and the string format and nothing else. 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's syntax is IMSUM(inumber1, [inumber2], ...) and states "Inumber1 is required, subsequent numbers are not", so a single argument is a documented call, not a degenerate one. The sum of one number is that number, and it must come back in Excel's own printed form -- which for a coefficient of exactly 1 is "1+i", the real part printed and the imaginary digit dropped. 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: (1+i) + (2+2i) = 3+3i. The syntax line says "1 to 255 complex numbers to add"; supplying them as a range is the form a real spreadsheet uses, and it exercises the argument-flattening path rather than the literal-parsing one. The two operands are stored as TEXT cells, which is what the x+yi format means in practice. 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's description says "in x + yi or x + yj text format". The arithmetic is identical to Microsoft's published example -- 8 and 4 -- and the answer must carry the same suffix it was given. 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.