|The HP-30S, rounding, and floating-point |
Message #3 Posted by Karl Schneider on 2 Dec 2006, 2:56 a.m.,
in response to message #2 by Vieira, L. C. (Brazil)
Hi, Luiz --
About the 'new breed' HP models with a 9.0000000... result. One of them - HP30S - had already been thge subject of an earlier thread (some time ago, IIRC was Karl the one who pointed that out) where its 32-bit internal precision was the issue, so I was not so taken by surprise in this case.
(NOTE: Corrected and updated with information from Rodger Rosembaum's post in reply.)
Several threads are found in Archive #15, including Rodger's original post on this topic.
The "forensics" expression, while straightforward, always seemed a bit arbitrary to me.
The HP-30S, with only two exponent digits, apparently uses an 80-bit extended-double floating-point representation. It allows extra precision -- up to 24 digits -- for the mantissa. The Saturn-processor 64-bit binary-coded decimal (BCD) representation with three exponent digits allows only 12 digits for the mantissa.
Here are several useful links:
Part of the reason that the HP-30S returns the exact answer of 9 for the forensics test is that the HP-30S takes the liberty of rounding results to integers that are in very close proximity, which provides answers that are reassuring to novice users. This was noted before by others, but here's my favorite example:
On a Saturn-processor calculator (or their KinHPo descendants), take "sin 3.14159265358" in radians mode. You will get the numerically-correct result of 9.79323846264 x 10-12 -- which not-coincidentally are the next 12 significant digits of pi, given that the input was not, in fact, exactly pi.
Now, try the same on the HP-30S. Start with "sin 3.1415926535". The displayed result is 8.979323846 x 10-11 -- correct to its 10-digit display. Then try "sin 3.14159265358". The answer returned is exactly zero! What happened? Rounding, for the sake of reassurance -- "This answer must actually be zero, so let's return that result to gratify the user."
"EXACTITUDE OF REPRESENTATION" -- BCD VS. FLOATING POINT
A nice thing about BCD is its exactitude and direct correspondence to the encoded value. This makes it well-suited for calculators, which usually display a result immediately after each calculation. In programs, a "test for zero" can't be bollixed by a tiny floating-point argument that wasn't quite represented as zero. In HP's 64-bit BCD, the mantissa of a zero is simply a string of 48 cleared bits.
Retrieve pi on a BCD calculator, then subtract the integer part and multiply the result by 10. Keep repeating, and you will see no additional digits: Pi to 12 digits is given as 3.14159265359, and nothing more.
Now, try the HP-30S. Retrieve pi, and keep revealing the extra digits as above. You'll obtain
3.14159 26535 89793 23846 264 8727...
The first 24 digits are correct, but the next four that follow should have been "3383". The limits of resolution have been exceeded, but the HP-30S will keep giving more incorrect digits if the procedure is continued.
HP-30S -- REPRESENTATION VS. COMPUTATION
The HP-30S' representational accuracy of 24 significant digits does not extend to the same computational accuracy.
The digit-revealing procedure after computing e^(1) on the HP-30S produces
2.7182 8182 8459 0452 018...
which strays from the correct value in the 18th significant digit:
2.7182 8182 8459 0452 353...
But, of course, there's a bottomless well of incorrect digits to be retrieved.
Going back to the forensics example, one can see on the HP-30S that
arcsin(arccos(arctan(tan(cos(sin(8.999999999)))))) = 8.9999999990528...
arcsin(arccos(arctan(tan(cos(sin(9.000000001)))))) = 9.0000000010528...
with error appearing in the 12th significant digit.
In summary, if there's a sound argument for using floating-point representation instead of BCD on a calculator (and particularly the slow, non-programmable, non-graphing HP-30S), I'd like to see it.
Edited: 2 Dec 2006, 9:40 p.m. after one or more responses were posted