OCT2DEC Function (Gnumeric)
Decode octal text with Gnumeric OCT2DEC, including numeric output, ten-digit signed values, native boundary tests and handling of leading zeroes.
Verification status: 17 reference, boundary and advanced-check formulas were recalculated through Gnumeric 1.12.57 ssconvert with retained native formula identities and ODF results. Independent arithmetic and 1.12.62 source were also checked; 1.12.62 was not executed. How formula examples are checked
Quick answer: =OCT2DEC("377") returns 255 in Gnumeric 1.12.57. The result is numeric.
Availability and version history
- Introduced: First release not established.
- Supported in: Gnumeric 1.12.62, with no retirement established.
- Scope: Desktop Gnumeric with the Engineering plugin; English comma-separated formulas are used below.
- Checked: October 14, 2026. The reference and boundary tables plus the explicit roundtrip or recurrence were recalculated through 1.12.57 ssconvert and compared with native formula records, source and independent arithmetic. 1.12.62 is source-checked only.
What OCT2DEC returns
OCT2DEC converts an octal representation into an ordinary decimal number. Octal 715 is decimal 461. Its result is numeric, so it can be used in arithmetic; source padding is not part of that numeric result. Versioned function help.
Syntax and arguments
=OCT2DEC(x)
There is one required argument, x, and no places argument. Quoted strings may contain at most ten octal digits. Prefer text input when the source is an identifier, because numeric-cell coercion can discard leading zeroes or fractional information before conversion. Function implementation.
Reproducible examples
Results are decimal numbers; input padding is not retained. All eight reference rows below were recalculated in the stated 1.12.57 build.
| Formula | Gnumeric 1.12.57 result |
|---|---|
=OCT2DEC("0") |
0 |
=OCT2DEC("7") |
7 |
=OCT2DEC("10") |
8 |
=OCT2DEC("377") |
255 |
=OCT2DEC("715") |
461 |
=OCT2DEC("3777777777") |
536870911 |
=OCT2DEC("4000000000") |
-536870912 |
=OCT2DEC("7777777777") |
-1 |
Practical worksheet
Suppose A2 contains the text 00100. =OCT2DEC(A2) gives decimal 64. Preserve A2 if the five-character source width matters. Calculations should use the numeric 64, while exports that require the original field should use the saved text.
The difference between bases is visible even without letters: =OCT2DEC("10") is 8, not ten. Label the source column “Octal text” and the result column “Decimal value” to avoid mixing the two.
Advanced checks and interpretation
The executed check =DEC2OCT(OCT2DEC("00100"),5) returns 00100. The five-place argument deliberately reconstructs the saved width; OCT2DEC itself cannot remember it.
Ten-digit octal input follows a signed convention. 3777777777 is the largest positive encoding, 536870911; 4000000000 is −536870912; 7777777777 is −1. The transition is a sign boundary, not an arithmetic discontinuity in ordinary unsigned octal counting.
Boundaries and troubleshooting
The empty string "" produced numeric 0, but an actually empty reference F5 produced #NUM!. Those two inputs are not interchangeable. The numeric input 20.9 was truncated to 20 before being interpreted as octal, giving decimal 16.
The eleven-character string 00000000001 failed even though its mathematical value is only 1. Digits outside 0–7, surrounding spaces, a literal minus sign and Boolean TRUE also fail in the listed tests. Decide explicitly whether blank fields and excess padding are missing data or valid zeroes before converting a column.
In the following tests F5 is an actually empty cell. The empty string "", when present, is an explicit string argument.
| Formula | Gnumeric 1.12.57 result |
|---|---|
=OCT2DEC("8") |
#NUM! |
=OCT2DEC("-1") |
#NUM! |
=OCT2DEC(" 17 ") |
#NUM! |
=OCT2DEC("") |
0 |
=OCT2DEC(F5) |
#NUM! |
=OCT2DEC(20.9) |
16 |
=OCT2DEC("00000000001") |
#NUM! |
=OCT2DEC(TRUE()) |
#VALUE! |
Conversion and version limits
The shared conversion helper controls parsing, complement handling and width checks. The individual function entry is unchanged between the inspected 1.12.57 and 1.12.62 sources, but the shared digit-extraction helper changed. These native results therefore establish 1.12.57, not automatic equivalence for every 1.12.62 boundary. A stale SUM cache and an uncached SUM formula both recalculated correctly, with original function identities retained. Other locales, GUI entry and extreme values beyond the listed cases were not tested.