IMLOG2 Function (Gnumeric)

IMLOG2(z) calculates the principal base-2 complex logarithm: log₂(z) = ln(z) / ln(2). It is not a function for converting a number into binary digits. For =IMLOG2("3+4i"), the independently calculated expectation is 2.3219280949+1.3378042125i. Gnumeric lists IMLOG2(z) in its Complex manual and classifies the implementation Complete / Exhaustive in the function catalogue. Manual; catalogue, checked 2026-10-13.

=IMLOG2(z)

z (required): a valid complex-number value represented by an i/j suffixed text literal, a cell reference containing one, or a constructed COMPLEX value. There are no optional parameters or defaults. The base is fixed at 2, which must not be confused with a second argument. For real positive z, the mathematical imaginary coefficient is zero, but a Gnumeric complex result’s display/underlying value representation needs validation rather than an assumption that it becomes an ordinary number. Official manual, checked 2026-10-13.

The decimal results come from independent Python calculations and are rounded; they are not Gnumeric-native observations. A cell’s displayed representation may omit zero components or use different precision.

For A2 = 3+4i, calculate =IMREAL(IMLOG2(A2)): mathematically ln(5)/ln(2) ≈ 2.3219280949. The independent check =LN(IMABS(A2))/LN(2) gives the same mathematical real coefficient, provided Gnumeric parses A2 as intended. Its imaginary coefficient is =IMAGINARY(IMLOG2(A2)) with expected 0.9272952180/ln(2) ≈ 1.3378042125. A further identity is IMLOG2(z) * ln(2) = IMLN(z) on a consistent principal branch. Because complex-number outputs may be formatted text, use component extraction (IMREAL, IMAGINARY) and numeric multiplication for your comparison rather than multiplying unparsed strings.

If you are interpreting digital signal measurements, this is useful for expressing a complex magnitude in base-2 logarithmic units. Do not call this an ordinary bit count or treat a complex phase as a frequency without a separate model.

Related guides: IMLN, IMLOG10, IMABS, IMREAL. Gnumeric manual, checked 2026-10-13.

Zero and branch limitation: No finite logarithm exists for z=0; exact Gnumeric error output was not observed. Complex principal logarithms have a branch cut, so values with phases near ±π can differ discontinuously in the imaginary coefficient. Overflow, underflow and rounding depend on installation and should be tested for boundary inputs.

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 — IMLOG2: 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.