DECIMAL Function (Gnumeric)

=DECIMAL(x,base)

Gnumeric’s Engineering reference documents the arguments in exactly this order:

There is no documented optional argument or default base. Pass both arguments. These examples use commas as function separators in a decimal-point locale. If your Gnumeric locale uses a decimal comma, the argument separator may be a semicolon, such as =DECIMAL("FF";16). The Gnumeric project’s locale guidance documents this distinction.

The output is a number, unlike BASE, which returns a string. Every digit must make sense in the selected base: binary uses only 0 and 1; base 16 uses 0–9 and A–F; base 36 uses 0–9 and A–Z. The digit values and worked examples below are mathematical properties of positional notation; Gnumeric-specific character validation and error strings require native checking.

Suppose a small device exports hexadecimal sensor codes:

In B2 enter:

=DECIMAL(A2,16)

Fill down into B3 and B4. The expected numeric values are 26, 255 and 461, respectively. For A4, 01CD is 1×256 + 12×16 + 13 = 461; its leading zero does not change the number.

The following results were checked with independent base conversion calculations and not run in Gnumeric:

To format 461 as a padded hexadecimal display string and turn it back into an ordinary numeric quantity, use:

=DECIMAL(BASE(461,16,4),16)

The mathematically expected result is 461, because BASE is expected to produce the text "01CD", which DECIMAL interprets in base 16. This is a useful conceptual cross-check, not evidence the nested expression was executed in Gnumeric. In practice keep the BASE output as text if its leading zeros must be displayed or exported.

For a reusable sheet, place the text code in A2, the code’s base in B2, and use =DECIMAL(A2,B2) in C2. This avoids embedding 16 or 2 in every formula when different rows use different alphabets.

The official Gnumeric 1.12.62 source adds details that the shorter manual entry does not enumerate. Its DECIMAL callback checks the numeric base before converting it to an integer: bases below 2 or at least 37 produce a #NUM! source result; an accepted fractional base is truncated by the integer conversion. For clarity, use integer bases 2–36. The conversion helper limits nonempty input strings to 10 bytes and the parsed value to 0 through 2⁴⁰−1 (1,099,511,627,775). It treats an empty string as zero and rejects invalid digits, leading signs and surrounding whitespace with a #NUM! source result. These are implementation observations, not results from running Gnumeric. Use short unsigned digit strings rather than assuming Excel has identical limits.

• Wrong radix: The accepted base range in Gnumeric’s manual is 2–36. A value such as 1 or 37 is outside the documented domain; the manual does not specify the exact error displayed.
• Invalid digit for the base: A binary string such as "102" is not a valid base-2 numeral. Likewise, "G" is not a base-16 digit. These should be corrected before conversion; native testing is required to document Gnumeric’s exact error response.
• Losing leading zeros: Store the source code as text, for example "0011"; if a spreadsheet converts it to numeric 11 before the function reads it, the original display formatting is already lost.
• Wrong numeric interpretation: =DECIMAL("10",2) is 2, not decimal 10. The second argument determines the positional weights.
• Numbers beyond safe precision: Gnumeric normally uses finite-precision floating-point arithmetic; do not use this conversion to process extremely long, exact identifiers without independently checking precision and maximum input length.
• Case, whitespace, signs and non-integer bases: The current Gnumeric manual entry does not enumerate these rules; the version-specific source limits above cover several of them. Letter-case handling and application-level coercion remain untested here.
• Copy/paste parse failure: Check the locale-specific argument separator, straight quotation marks and whether the code cell contains text.
• Missing function: A catalogue entry does not guarantee that a particular plugin or package build exposes the function. Confirm the local application/version before relying on the page.

Gnumeric’s Engineering documentation explicitly calls DECIMAL OpenFormula-compatible. Although its public function catalogue labels DECIMAL Unique to Gnumeric, Microsoft’s current Excel DECIMAL documentation confirms that a similarly named function exists in supported modern Excel versions. Do not transfer Excel-specific limits (such as text length or numeric precision thresholds) to Gnumeric without native or source evidence; the Gnumeric entry gives a narrower published specification.

For the reverse operation, see BASE in the official Engineering manual. For narrower conversions, see BIN2DEC and HEX2DEC.

• Gnumeric Engineering manual — DECIMAL — exact syntax DECIMAL(x,base), input meaning and documented base range, ODF note; accessed October 12, 2026. The live manual page is not stamped with a release version per function.
• Gnumeric function catalogue — category, Gnumeric catalogue registration and No Testsuite classification; accessed October 12, 2026.
• Gnumeric 1.12 release archive — the research scope is the 1.12.62 release, latest item located October 12, 2026.
• Gnumeric numerical issues — general floating-point caution, not a DECIMAL-specific input limit; accessed October 12, 2026.
• Gnumeric locale guidance — historical project guidance for comma-versus-semicolon formula separator; accessed October 12, 2026.
• Microsoft Excel DECIMAL documentation — evidence of modern Excel support only; accessed October 12, 2026.

Verification status: Gnumeric documentation checked; displayed numeric examples independently calculated via positional arithmetic. Not executed in Gnumeric. No native test was run for invalid digits, decimal-base limits, letter-case handling, numeric overflow, blank or error-valued cells. No genuine Gnumeric screenshots are included; no mock application screenshots are used. Native testing remains outstanding.