PlanMaker BIN2OCT: Signed 32-Bit Conversion and Examples

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.

=BIN2OCT(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 source numerals in this guide are text. Format their input cells as text before typing them, and quote literals inside formulas. Valid binary digits are 0 and 1. Do not type a long bit pattern as a decimal numeric value: precision loss or automatic formatting can change it before conversion.

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.

Create BaseControls with Source in A1 and Converted in B1, Width_12 in C1. Set A2:A7 to text and enter the A strings exactly as shown; do not include quotation marks as part of the cell contents. Fill B2 =BIN2OCT(A2) through B7. Fill C2 =BIN2OCT(A2,12) through C7.

In a copy change A3 from 101010 to 101011. B3 becomes 53, and C3 becomes 000000000053. Row 4 remains a separate leading-zero control for the original 42.

The vendor’s =BIN2OCT("101010") gives 52. The groups 101 and 010 correspond to octal digits 5 and 2, so the value is 5×8+2=42. Adding leading zeroes to the binary input does not change that quantity.

Its negative example converts 11111111111111111111111111010110 to 37777777726, the octal representation of the same 32-bit two’s-complement pattern for −42. Eleven octal positions can be needed because 32 is not divisible by three. The most significant position does not represent three freely usable additional bits.

Do not replace this result with a ten-digit octal encoding from another spreadsheet’s negative-number rules. The specific word width is part of PlanMaker’s documented contract.

Create GroupedBits. Put text 111101001 in F2 and G2 =BIN2OCT(F2,3). The expected output is 751. The groups 111,101,001 become 7,5,1. Independently, 7×64+5×8+1=489.

In a copy change F2 to 111101000. G2 becomes 750, representing 488. The apparent decimal difference between displayed octal numerals is not a general way to compute changes. Convert or retain the underlying quantity before arithmetic.

For example, binary 111111111 becomes octal 777, while binary 1000000000 becomes octal 1000. The quantities are 511 and 512, only one apart. A three-position width fits the first but not the second.

The inverse check =OCT2DEC("37777777726") returns −42 under the matching PlanMaker 32-bit rule. The octal digits interpreted as an unsigned integer represent 4,294,967,254, so signed interpretation is essential.

For an external protocol, retain the raw binary source, expected word size and field meaning next to the converted display. These examples do not modify any operating-system permissions or assume that a particular octal grouping is a security policy.

=BIN2OCT("101010",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.

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.