Fellow calculator enthusiasts --

Recently, I was using Microsoft Word macro, when a Microsft Visual Basic error message came up:

"Run-time error 80004005 (-2147467259) ....."

I fixed the problem, but the simple math exercise intrigued me. It clearly looked like an eight-digit (32-bit) hexadecimal code converted to a signed decimal-integer equivalent. This task is basically the extraction of a typical C-language "long int" variable. How efficiently can various calculators with *built-in* binary ("base") conversions obtain the desired result? My findings may be disconcerting to the reader...

First up: the "gold standard"

**HP-16C**

The user hits DEC, enters "32" and hits WSIZE to set a 32-bit word. Then, the user can choose "2's" complement, and verify these settings using STATUS. Then, the user hits HEX, enters "80004005", hits DEC to convert and reads,

-47467259 .d (in Window 0)

-21 d. (in Window 1)

for a complete value of -2,147,467,259 -- the correct result.

Granted, it's a minor annoyance that the output is displayed in two parts. However, eight digits is a digestible size for "chunks" of long integers, and the user is given exacting control over the format of data. The "DEC" mode offers a true integer range up to 19 digits.

VERDICT: Rigorous and trustworthy.

**Pioneer models:**

On a 32SII, keying in "80004005" after selecting HEX, then converting with DEC yielded 2,147,500,037. That's the correct __unsigned__ integer, but not the correct (2's complement) signed integer.

Experimentation (or RTFM) reveals that the Pioneer models use a 36-bit 2's-complement integer representation. This makes perfect sense with the 12-digit display, allowing full 12-digit octal and 9-digit hexadecimal. Decimal conversions return to normal floating-point mode (not decimal integer), but the results will not exceed 11 digits. Up to 36 binary digits can be entered or converted, displayable by scrolling 12-digit chunks.

However, 36 bits is not the same as 32 bits. To properly represent this particular complemented, signed integer requires that the hex value be preceded by an "F". This provides a sign bit and three leading complemented bits in the correct positions.

HEX, "F80004005", DEC yields -2,147,467,259.00 on the 20S, 27S, 32S, 32SII, and 42S (and probably the 22S?). The 33S performs the same way.

VERDICT: The approach is not unreasonable, but the user must take caution to avoid incorrect results.

**RPL-based models**

I tried the 28C, 48G, and 49G.

The user can set word sizes from 1 to 64 bits using "STWS", but the values are treated only as unsigned. Thus, the RPL-based models cannot automatically handle signed integers. Also, these calculators will accept extra input digits beyond the word boundaries, then simply discard the superfluous high-order bits. The HP-16C and Pioneers do not accept invalid input.

After entering/selecting "HEX" and setting the word size if desired, the user must precede the entered value by a "#" and enter it onto the stack from the input buffer.

Even after setting the word to 32 bits, entering "#80004005" in HEX mode, then entering/selecting "DEC" gives the incorrect result of "#2147500037d" due to unsigned-integer representation.

The HP-48 and HP-49 models allow the user to do a "change sign" on a binary integer to get a 2's-complement conversion, but the HP-28C doesn't -- the user must do a "NOT", then add 1. Either of these approaches will give the result "#2147467259d", which is correct except for the missing sign.

The user would have to write an RPL program to automate this type of conversion.

VERDICT: Awful! Some simple problems are made complicated -- the functionality is there, but it's not implemented thoughtfully.

**Non-HP "cheapos"**

I also have several low-end calc's with base conversions built in -- a Casio fx-115MS and a Texas Instruments TI-36X. Both of these models are NCEES-approved for standardized EIT/FE and PE exams.

Each of these calculators limits the size of arguments in the respective bases by their 10-digit display length, not by bit count. So, on both calculators, base-2 binary integers are 10 bits, and base-8 octal integers are 30 bits. Base-16 hexadecimal integers are 32 bits on the Casio, and 40 bits on the TI. Integers are represented as signed 2's-complement on both.

Observing the 40-bit word length, the TI returned the correct -2147467259 when provided "FF80004005" as HEX-mode input, converted to floating-point using DEC.

Almost by happenstance, the Casio handled this particular problem most adroitly of any unit I tried. Its fixed 32-bit hexadecimal, 2's-complement signed integers and 10-digit display made it ideally suited for the task. "80004005=" entered in HEX mode and converted with DEC yielded -2147467259. Other values (e.g., 32-bit unsigned integers or shorter signed integers) would not be converted as conveniently; adjustments to input or output would be required.

The different word sizes can produce curious results. For example, -1 decimal on these units displays as octal "7777777777" or binary "1111111111", suggesting that a string of 30 bits can be represented as a string of 10 bits! Another consequence: what is representable on these calculators as hexadecimal might __not__ be representable as octal, decimal, or binary. Attempts to convert "downward" a hexadecimal number within the uppermost range of representable values can produce a non-recoverable and bogus message of "Math Error" (Casio) or "Error" (TI).

One more thing: the Casio will simply return "Math Error" upon buffer entry after blithely accepting superfluous input digits.

VERDICT: The unwitting schoolkids and testees could be flummoxed.

------------------------------------------------------------------

In summary, let's acknowledge the fine and distinctive HP-16C, which also recognizes unsigned and 1's-complement signed integers (which were not yet antiquated in the 1980's).

Comments, experiences?

-- KS

*Edited: 27 Aug 2005, 3:17 p.m. after one or more responses were posted*