PlanMaker HEX2OCT: 32-Bit Conversion, Width and Worked Examples
HEX2OCT converts hexadecimal input to octal using PlanMaker's signed 32-bit convention. Work through complete datasets, padding controls and explicit sign boundaries.
Verification status: See the evidence and test scope described in this guide. How formula examples are checked
HEX2OCT converts hexadecimal input to octal using PlanMaker’s signed 32-bit convention. Work through complete datasets, padding controls and explicit sign boundaries.
Availability and verification
The PlanMaker 2026 manual, 2024 manual and 2021 manual were retrieved on October 15, 2026. They document this function in those manual families. They do not establish its original introduction or a last-working-version endpoint; both historical endpoints remain unverified. Support in every FreeOffice/mobile edition or individual desktop build is outside this check.
No native PlanMaker execution was performed. Expected values below are independently checked mathematical controls, not captured application results. Formulas use the English manual’s commas; verify localized names and separators in the installed product.
Syntax and signed domain
=HEX2OCT(Number [, Digits])
Number is required. Supply hexadecimal text, using only 0–9 and A–F. Quote literals inside formulas and set source cells to text before entering them. This avoids automatic decimal interpretation or loss of long numeral strings.
The documented domain is signed −2,147,483,648 through 2,147,483,647. Negative inputs and results use a 32-bit two’s-complement word. The manual’s encoded endpoint notation identifies signed values; it is not an increasing interval of ordinary unsigned hexadecimal magnitudes. These are PlanMaker-specific rules, not assumed limits of another product with the same function name.
Digits is optional: omitted means the required width is chosen automatically. A supplied Digits must be greater than zero. Fractional Digits are truncated. If a positive result needs more significant places than the requested width, the documented error is #NUM!. Negative values use their 32-bit representation and ignore Digits. This guide tests that rule with positive widths; it does not infer precedence when a negative Number is combined with an invalid width.
Complete conversion worksheet
Create BaseControls with Source in A1, Converted in B1 and Width_12 in C1. Format A2:A7 as text and enter the exact strings below. Fill B2 =HEX2OCT(A2) and C2 =HEX2OCT(A2,12) through row 7.
| Row | A: source text | Expected B | Expected C |
|---|---|---|---|
| 2 | 0 | 0 | 000000000000 |
| 3 | 2A | 52 | 000000000052 |
| 4 | 002A | 52 | 000000000052 |
| 5 | 3FF | 1777 | 000000001777 |
| 6 | FFFFFFD6 | 37777777726 | 37777777726 |
| 7 | 80000000 | 20000000000 | 20000000000 |
In a copy change A3 from 2A to 2B. B3 becomes 53, and C3 becomes 000000000053. Row 4 remains an independent leading-zero control for the original 42.
Rebuild the source examples
=HEX2OCT("2A") is 52, and =HEX2OCT("2A",4) is 0052. Both represent 42: 2×16+10=5×8+2. A one-place request cannot hold two significant octal digits, so =HEX2OCT("2A",1) gives the documented #NUM! error.
The manual’s negative control =HEX2OCT("FFFFFFD6") is 37777777726. Both strings encode signed −42 as a 32-bit two’s-complement word. Eleven octal digits may be required because 32 bits do not divide into complete three-bit groups; the initial octal digit is a partial group.
Advanced: keep a counter’s value through a base change
On CounterDisplay, enter text 1FF,200,201 in F2:F4. Fill G2 =HEX2OCT(F2,4) through G4. Expected outputs are 0777,1000,1001, representing decimal 511,512,513. Each source quantity rises by one despite the multi-digit carry.
A three-place request can hold 777 but not 1000. Do not select a receiver’s field width from its first sample alone. At the hexadecimal boundary FF→100, the octal values are 377→400, corresponding to decimal 255→256.
Advanced: group the same bits another way
Hexadecimal 1A5 expands to binary 110100101. Grouping those bits in threes gives 110,100,101, hence octal 645. Independently, 1×256+10×16+5=6×64+4×8+5=421.
This mathematical cross-check explains why a conversion is correct without assuming a native export retained the original text. Retain leading-zero source fields if they carry layout information: conversion preserves the represented value, not an external identifier’s exact original spelling.
Fractional width is a separate argument rule
=HEX2OCT("2A",8.9) has independent expected output 00000052, because truncating 8.9 gives width 8. This does not establish how a fractional source Number or a text numeral containing a decimal point is handled. Use explicit integer widths in production worksheets.
Errors and troubleshooting
Invalid digits, prefixes, whitespace, Boolean values, blanks and numeric-text coercion outside the source examples do not have a complete documented error matrix here. No exact error token is invented for those cases. Inspect the raw input when a conversion seems wrong; a numeric cell that has already changed the source text cannot be repaired merely by choosing another output base.
Record the installed build, edition, language and workbook format before native reproduction. Check displayed strings and saving/export separately. A mathematically correct representation does not prove that an external receiver accepts the word size or preserves leading zeroes.