HEX2OCT in WPS Spreadsheet: Convert Hex Quantities Within the Signed Octal Range

• Introduced: documented by 2019-06-24 in the official WPS lesson; the first release is not established.
• Availability: Current WPS Windows documentation confirms this function. The historical lesson’s edition field is blank.
• Scope: exact current supported builds and other WPS clients remain unverified.
• Checked: October 14, 2026. Documentation and independent calculations; no native WPS execution.

=HEX2OCT(number,[places])

The lesson describes at most ten hexadecimal input characters with a forty-bit two’s-complement sign convention. For this conversion it states positive maximum 1FFFFFFF and negative minimum FFE0000000, corresponding to 536870911 and −536870912.

Places is optional. Omission uses the minimum necessary characters; a supplied larger width pads the result. Negative inputs ignore places and return ten octal characters, representing thirty bits.

Two error remarks in the historical page are malformed: one loses its comparison with places, and another names the function instead of the nonnumeric argument. Exact insufficient-width and nonnumeric-places error behavior is therefore left unverified rather than copied from Excel. The clear syntax, endpoints and width rules remain usable.

Enter only column A below as Text in A2:A6. Use =HEX2OCT(A2) in B2 and =HEX2OCT(A2,4) in C2, filling down.

The independently decoded quantities are 5, 37, 73, 165 and 300. Hex 12C gives 256+32+12=300; octal 454 gives 256+40+4=300.

Padding changes the output width, not its value. The four characters of 0454 are a representation requirement, not four decimal places of precision.

Put =HEX2DEC(A2) in D2 and =OCT2DEC(C2) in E2, then fill both through row 6. The expected sequences agree: 5, 37, 73, 165 and 300.

A rowwise comparison =D2=E2 has independently expected result TRUE for each chosen record. HEX2DEC and OCT2DEC apply separate base and sign conventions.

This checks the complete fixture. It does not validate every malformed string or certify an untested native precision boundary.

=HEX2OCT("1FFFFFFF")
=HEX2OCT("FFE0000000")

Independently expected strings are 3777777777 and 4000000000. They represent the positive and negative endpoints of the thirty-bit signed output model.

Hex 20000000 is positive 536870912, one above the specified positive conversion limit. It is still a valid hexadecimal representation for the separate decoder, but increasing places cannot make it fit this target interval. Its exact native out-of-range error is not established by the lesson’s clear wording.

For −5, the input’s unsigned forty-bit value is 2^40−5. The output’s thirty-bit value is 2^30−5. Both represent −5 when decoded with the correct width.

A valid supplied width such as 4 is ignored for these negative values. A short hex FB instead describes positive 251 and converts to octal 373. It must not be interpreted as a negative byte merely because its first digit is high-valued.

For the first positive table, =OCT2HEX(C2,3) gives expected hex strings 005, 025, 049, 0A5 and 12C. The quantities match the originals, while some textual widths change.

OCT2HEX supplies the explicitly requested output width. Keep the original strings if an exact import/export comparison must preserve their character counts.

The lesson clearly documents fractional places as truncated, so places 4.9 yields the same independently expected positive output as width 4. It also clearly identifies invalid hexadecimal input as #NUM! and negative places as #NUM!.

Its two malformed error remarks do not justify a general rejection of multi-character results or a guessed nonnumeric-argument rule. Those errors, zero places, text cleanup and native precedence remain unverified. The examples deliberately use valid explicit strings and sufficient integer widths, with source limitations visible instead of silently repaired from another product.

• WPS Academy: HEX2OCT, 2019-06-24 (Chinese).
• Current WPS Windows HEX2OCT introduction.
• Editorial testing standards.

Complete function-specific documentation reviewed. Worked outputs are independently calculated expectations, not captured native results. Formulas use English names and comma separators; check the installed locale. Product/client and source gaps retain their explicit scope.