HEXREP Function (Gnumeric)

• Introduced: Gnumeric 1.11.0 release notes explicitly record this function being added.
• Supported in: Gnumeric 1.12.62, with no retirement established.
• Scope: Desktop Gnumeric with the Engineering plugin; English comma-separated formulas are shown. HEXREP is a documented debugging function with build-dependent output.
• Checked: October 14, 2026. Reference and boundary tables plus the explicit advanced-check formula were recalculated through 1.12.57 ssconvert. Current 1.12.62 source was inspected; that later release was not executed.

HEXREP is a worksheet debugging function that exposes a numeric value’s representation as text. It is not a decimal-to-hexadecimal integer converter. Its official help explicitly warns that the layout can change and can depend on the Gnumeric build. Versioned function help.

=HEXREP(x)

Exactly one numeric x is required. The table below is specific to the tested 1.12.57 binary64 build. That implementation writes the value as little-endian double bytes and formats those bytes as hexadecimal. The resulting string should not be interpreted as an ordinary hexadecimal integer. Function implementation.

Strings are shown exactly as captured in the 1.12.57 build, including all zeroes.

HEXREP exposes the numeric representation used by the tested build. For two different values, =HEXREP(0.1) returned 9a9999999999b93f, while =HEXREP(0.1+0.2) returned 343333333333d33f. These strings help diagnose representation differences; they are not human-friendly decimal values.

Keep the ordinary numeric value and a sufficiently precise decimal display beside the debugging output. A string comparison can expose a difference in that exact build, but it does not explain whether the difference matters to the calculation.

The executed expression =HEXREP(0.1+0.2-0.3) returned 000000000000903c in 1.12.57, corresponding to a small nonzero binary64 residual. The underlying independently reproduced arithmetic residual is 2^−54, approximately 5.551115123126E-17. It is a consequence of binary floating-point approximations, not an error in decimal subtraction as mathematics.

The format changed in later source. The pinned 1.12.62 binary-radix branch uses C-style hexadecimal floating-point formatting through %a; its decimal-radix branch uses a shortest decimal representation. The older table’s byte strings must not be presented as verified 1.12.62 outputs or used as a portable file format.

The XLSX formula =HEXREP(-0) was canonicalized to =hexrep(0) in the saved native XML and shared the literal-zero expression. Its all-zero result therefore does not establish preservation of a negative-zero sign bit. The original input formula and this normalization are both retained in the test record.

The function is useful for diagnosis, but its documented build dependence makes it unsuitable as a stable identifier, interchange format or cross-product equality test. Do not decode its output with a worksheet integer-base function. If byte-level reproducibility matters, specify the application version and numeric build explicitly.

F5 below is an actually empty cell. The listed errors are native error results, not mathematical zeroes.

• Worksheet entry
• Numeric or argument-handling source
• 1.12.57 byte-format implementation

The retained workbook results include a deliberately stale SUM cache and an uncached SUM formula, both recalculated correctly. Native evidence covers the named 1.12.57 build and listed cases; cell-reference layouts and other explanatory compositions are instructions or independent mathematical checks unless explicitly identified as executed. Other locales, direct GUI entry and later-release output were not tested.