[LONG] Signed integers: HP16C vs. "the rest" Message #1 Posted by Karl Schneider on 27 Aug 2005, 1:07 a.m.
Fellow calculator enthusiasts 
Recently, I was using Microsoft Word macro, when a Microsft Visual Basic error message came up:
"Runtime error 80004005 (2147467259) ....."
I fixed the problem, but the simple math exercise intrigued me. It clearly looked like an eightdigit (32bit) hexadecimal code converted to a signed decimalinteger equivalent. This task is basically the extraction of a typical Clanguage "long int" variable. How efficiently can various calculators with builtin binary ("base") conversions obtain the desired result? My findings may be disconcerting to the reader...
First up: the "gold standard"
HP16C
The user hits DEC, enters "32" and hits WSIZE to set a 32bit 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 36bit 2'scomplement integer representation. This makes perfect sense with the 12digit display, allowing full 12digit octal and 9digit hexadecimal. Decimal conversions return to normal floatingpoint 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 12digit 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.
RPLbased 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 RPLbased models cannot automatically handle signed integers. Also, these calculators will accept extra input digits beyond the word boundaries, then simply discard the superfluous highorder bits. The HP16C 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 unsignedinteger representation.
The HP48 and HP49 models allow the user to do a "change sign" on a binary integer to get a 2'scomplement conversion, but the HP28C 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.
NonHP "cheapos"
I also have several lowend calc's with base conversions built in  a Casio fx115MS and a Texas Instruments TI36X. Both of these models are NCEESapproved for standardized EIT/FE and PE exams.
Each of these calculators limits the size of arguments in the respective bases by their 10digit display length, not by bit count. So, on both calculators, base2 binary integers are 10 bits, and base8 octal integers are 30 bits. Base16 hexadecimal integers are 32 bits on the Casio, and 40 bits on the TI. Integers are represented as signed 2'scomplement on both.
Observing the 40bit word length, the TI returned the correct 2147467259 when provided "FF80004005" as HEXmode input, converted to floatingpoint using DEC.
Almost by happenstance, the Casio handled this particular problem most adroitly of any unit I tried. Its fixed 32bit hexadecimal, 2'scomplement signed integers and 10digit display made it ideally suited for the task. "80004005=" entered in HEX mode and converted with DEC yielded 2147467259. Other values (e.g., 32bit 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 nonrecoverable 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 HP16C, which also recognizes unsigned and 1'scomplement 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
