The HP30S, rounding, and floatingpoint 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 
Quote:
arcsin(arccos(arctan(tan(cos(sin(9))))))
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 32bit 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.
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=85973#85973
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=88282#88282
http://www.hpmuseum.org/cgisys/cgiwrap/hpmuseum/archv015.cgi?read=83934#83934
The "forensics" expression, while straightforward, always seemed a bit arbitrary to me.
The HP30S, with only two exponent digits, apparently uses an 80bit extendeddouble floatingpoint representation. It allows extra precision  up to 24 digits  for the mantissa. The Saturnprocessor 64bit binarycoded decimal (BCD) representation with three exponent digits allows only 12 digits for the mantissa.
Here are several useful links:
http://en.wikipedia.org/wiki/IEEE_Floating_Point_Standard
http://en.wikipedia.org/wiki/Binary_coded_decimal
Part of the reason that the HP30S returns the exact answer of 9 for the forensics test is that the HP30S 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 Saturnprocessor calculator (or their KinHPo descendants), take "sin 3.14159265358" in radians mode. You will get the numericallycorrect result of 9.79323846264 x 10^{12}  which notcoincidentally are the next 12 significant digits of pi, given that the input was not, in fact, exactly pi.
Now, try the same on the HP30S. Start with "sin 3.1415926535". The displayed result is 8.979323846 x 10^{11}  correct to its 10digit 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 wellsuited for calculators, which usually display a result immediately after each calculation. In programs, a "test for zero" can't be bollixed by a tiny floatingpoint argument that wasn't quite represented as zero. In HP's 64bit 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 HP30S. 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 HP30S will keep giving more incorrect digits if the procedure is continued.
HP30S  REPRESENTATION VS. COMPUTATION
The HP30S' representational accuracy of 24 significant digits does not extend to the same computational accuracy.
The digitrevealing procedure after computing e^(1) on the HP30S 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 HP30S 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 floatingpoint representation instead of BCD on a calculator (and particularly the slow, nonprogrammable, nongraphing HP30S), I'd like to see it.
 KS
Edited: 2 Dec 2006, 9:40 p.m. after one or more responses were posted
