PlanMaker DEC2OCT: Signed 32-Bit Conversion and Examples
DEC2OCT converts decimal input to octal. PlanMaker documents a signed 32-bit domain and two's-complement negative values. The represented quantity and the written numeral are different things; preserve the source and its sign convention when converting.
Verification status: See the evidence and test scope described in this guide. How formula examples are checked
DEC2OCT converts decimal input to octal. PlanMaker documents a signed 32-bit domain and two’s-complement negative values. The represented quantity and the written numeral are different things; preserve the source and its sign convention when converting.
Availability and evidence
The PlanMaker 2026 reference, 2024 reference and 2021 reference were retrieved and read on October 15, 2026. These establish documented support in those manual families, not the original introduction or a last-working-version endpoint. Both historical endpoints remain unverified. Specific FreeOffice/mobile editions and every desktop build are outside the checked scope.
No native PlanMaker execution, screenshot or file transfer was performed. The expectations below are independently checked integer encodings consistent with the documentation. English formulas use commas; localized separators and function names require checking in the installed build.
Exact syntax and input domain
=DEC2OCT(Number [, Digits])
Number is required. The documented signed domain is −2^31 through 2^31−1, or −2,147,483,648 through 2,147,483,647. The binary/hexadecimal/octal strings for negative values encode the 32-bit two’s-complement word, rather than an ordinary minus-prefixed numeral.
The input column contains numeric decimal integers. The reference explicitly describes the converted output as text, even when it contains only digits. Keep the original numeric column for sums and comparisons. The documented truncation of Digits does not establish how a fractional Number is treated.
Digits controls output width
Digits is optional. When omitted, PlanMaker determines the required width. It must be greater than zero; fractional Digits are truncated rather than rounded. A positive input whose significant representation is wider than Digits gives #NUM!, as shown in the vendor examples.
For a negative value the 32-bit representation is used and Digits is ignored. The examples use ordinary positive width requests when checking that rule; they do not settle validation precedence for a simultaneously invalid width. Number’s numeric value and Digits’ display requirement remain separate.
Complete reproducible worksheet
Create BaseControls with Source in A1 and Converted in B1, Width_12 in C1. Enter the numeric A inputs below. Fill B2 =DEC2OCT(A2) through B7. Fill C2 =DEC2OCT(A2,12) through C7.
| Row | A: source | Expected B | Expected C |
|---|---|---|---|
| 2 | 0 | 0 | 000000000000 |
| 3 | 1 | 1 | 000000000001 |
| 4 | 42 | 52 | 000000000052 |
| 5 | 255 | 377 | 000000000377 |
| 6 | 1023 | 1777 | 000000001777 |
| 7 | -42 | 37777777726 | 37777777726 |
In a copy change A4 from 42 to 43. B4 becomes 53, and C4 becomes 000000000053. Only that input row changes.
Reproduce the documented width behavior
The vendor gives =DEC2OCT(42) as 52, and =DEC2OCT(42,8) as 00000052. Two significant positions are required, so =DEC2OCT(42,1) produces the documented #NUM! error.
For −42, the result is 37777777726, encoding the same signed 32-bit word in octal. It occupies eleven octal positions. A positive Digits request is ignored for a negative Number, so the requested width does not shrink that representation to eight positions.
Do not substitute a ten-digit negative octal pattern from another spreadsheet product. A base-eight digit represents three bits, and the partial most-significant group is why a 32-bit word can require eleven positions.
Advanced: inspect an octal carry boundary
Create OctalCounter with numeric 511,512,513 in F2:F4. Fill G2 =DEC2OCT(F2,4) through G4. The expected strings are 0777,1000,1001. Each source value increases by one, even though the first transition changes every significant digit.
The independent expansion is 7×64+7×8+7=511, followed by 1×512=512. A three-position request fits 777 but cannot fit 1000. Choose output width from the receiver’s largest permitted value, not just the first record in a sample.
As another control, =DEC2OCT(341,4) gives 0525, since 5×64+2×8+5=341. Perform arithmetic on the original numeric column instead of assuming an octal display’s decimal appearance preserves differences or divisibility rules.
Advanced: preserve the signed domain
The independent endpoint controls are 2,147,483,647 → 17777777777, −2,147,483,648 → 20000000000, and −1 → 37777777777. These are encodings of the signed values, not an ordered list of unsigned octal magnitudes.
For a deliberate inverse check, =OCT2DEC("37777777726") has expected result −42. The agreement depends on the same 32-bit interpretation in both functions. It does not certify an external protocol, native export or receiver’s treatment of leading zeroes.
A function can correctly encode a number that is invalid for a particular field. Keep any receiver-specific width, allowed range and sign policy as separate checks rather than assuming conversion alone validates the record.
A documented fractional-width control
=DEC2OCT(42,8.9) has independently expected output 00000052 because the documented Digits truncation gives width 8. This is a width example, not evidence for truncating a fractional source Number. Keep an explicit integer width in routine formulas for readability.
Errors and verification limits
Respect the documented signed range and source base. The short reference does not give a complete native error/coercion matrix for malformed strings, prefixes, blanks, Boolean values, arrays or fractional Number inputs. No exact error token is invented for those cases. A source with too many bits or an invalid digit is outside the documented contract even when its intended meaning seems obvious.
Before reuse, record the exact PlanMaker build, edition, platform, language and workbook format. Recreate the original cells, inspect whether source text survived entry, and apply each changed-input control separately. Test saving and the receiving application’s interpretation independently; neither follows from a correct mathematical encoding.