IMEXP Function (Gnumeric)

IMEXP(z) computes e raised to a complex exponent z = a + bi. In exponential form, e^(a+bi) = e^a [cos(b) + i sin(b)]. It changes both magnitude and phase: e^a controls magnitude while b controls the phase in radians. For example =IMEXP("0+1i") has the expected value approximately 0.5403023059+0.8414709848i (independent calculation, not a Gnumeric observation). The official Gnumeric manual states this purpose and the one-argument signature (official complex manual, checked 2026-10-13).

=IMEXP(z)

z (required): one complex-number value, such as text "2-1i", a cell reference containing a valid complex value, or a value returned by COMPLEX. There are no optional arguments or defaults. This function is not EXP on just the real part; the imaginary coefficient participates in the calculation. The manual describes invalid z but does not define every accepted import/coercion representation, so avoid treating arbitrary words or locale-formatted text as valid. Gnumeric manual (checked 2026-10-13).

The figures are complex-number components rounded to 10 decimal places. Actual display strings can differ, including omission of zero components. Check numeric components with IMREAL and IMAGINARY, not exact string equality.

For A4 = 2-1i, calculate the magnitude factor e² ≈ 7.3890560989, cosine cos(-1) ≈ 0.5403023059 and sine sin(-1) ≈ -0.8414709848. Their products give 3.9923240484-6.2176763124i. In a signal-model worksheet, B might describe log-amplitude and C phase: use =IMEXP(COMPLEX(B2,C2)) to convert the two components to a complex phasor. This is a mathematical use case, not proof of device-specific signal processing accuracy.

A round-trip check is =IMEXP(IMLN(A2)), mathematically returning A2 for nonzero complex A2. Because the logarithm is taken on a principal branch and floating-point arithmetic is approximate, verify the recovered coefficients with a tolerance rather than assuming identical text. Related Gnumeric guide: IMLN, COMPLEX, IMREAL, and IMAGINARY.

Additional limit: A very large positive real coefficient can cause exponential overflow; a large negative one may underflow toward zero. Exact thresholds and returned error text are implementation/version dependent and were not tested. Use a bounded input range and test on the target installation.

Create a blank Gnumeric sheet. Enter these complex-number text literals without a leading = in column A. Use plain English-formatted samples with a period as decimal separator; inspect your locale’s input conventions before adapting them.

Enter the article’s function formula in D2 and copy to rows 3–5 if desired. For a constructed input, enter =COMPLEX(B2,C2) in D7 and use the article’s function around D7. COMPLEX’s manual signature is COMPLEX(x,y,i) with the suffix defaulting to i. The comma shown follows the English-language Gnumeric manual; locales may change separators and decimal conventions. This article does not claim to have tested other locale syntaxes. Sources: COMPLEX documentation; locale documentation (checked 2026-10-13).

• Unparseable text: The online Gnumeric 1.12 manual says #VALUE! for invalid complex input. The checksum-verified official 1.12.62 source returns #NUM! for malformed complex strings; other unsupported value types may yield #VALUE!. This resolves the release-source provenance question, but is not a native execution result.
• Quoted numeric-looking strings: Ensure your input contains a valid complex representation ("3+4i" or "2-1i"), not a stray unit, spreadsheet formula, or text with thousands separators. The i/j convention belongs inside the complex text; do not append it to an ordinary LN/LOG result.
• Locale/import: Formula syntax and text parsing can vary with decimal separators. The one-argument function signature stays one argument, but nested COMPLEX(B2,C2) uses a delimiter that your localized installation may represent differently. Test an imported worksheet rather than silently replacing commas with semicolons; consult Gnumeric locale documentation.
• Precision and formatting: Calculated complex results are floating-point approximations; displayed digits, placement of i or j, and very small residual coefficients can vary. For verification compare real and imaginary components numerically (e.g. IMREAL/IMAGINARY) rather than comparing raw strings.
• Compatibility: The manual marks this function Excel compatible, but this is Gnumeric’s documented classification. It does not establish identical parsing, error codes, version support, formatting, or calculations in another spreadsheet. Confirm a workbook separately in each target product.
• Testing boundary: All expected values on this page were independently derived using Python’s standard cmath/math modules and analytic identities. Native Gnumeric checks: 0. Errors described as unresolved are deliberately not disguised as tested results.

1. Gnumeric Complex manual — signature, purpose, input note, compatibility and principal branch where stated.
2. Official function catalogue — IMEXP: Complete / Exhaustive (upstream catalogue status, not observed execution).
3. Gnumeric 1.12.62 release announcement — general complex-function compatibility improvements, not a claim of per-example native testing.
4. Official Gnumeric 1.12.62 source archive — inspected complex callbacks and shared parser in plugins/fn-complex/functions.c; release archive checked against its official SHA-256 checksum.
5. Gnumeric download policy and locale documentation — platform availability and locale caveats.

Native validation remains outstanding: exact displayed results, error cells, locale behavior and workbook round-trips have not been checked in a running Gnumeric installation.