Old TI30 accuracy & HP33S Message #6 Posted by Karl Schneider on 5 Feb 2007, 3:16 a.m., in response to message #5 by Palmer O. Hanson, Jr.
Hi again, Palmer 
Quote:
Once again I will quote from the manual. The Owner's Manual for the TI30 explains that calculations produce an 11digit result but that only an 8digit rounded result is displayed.
The exact quote is,
"Each calculation produces an 11digit result. These 11 digits are more than are displayed. The result is therefore rounded to a(n) 8digit standard display or to 5 digits for scientific notation."
It's not clear whether the intended meaning is that the displayed value is the actual value after rounding (as though a RND function was used), or that the displayed value is merely a rounded representation of the actual value.
HP calculators with FIX/SCI/ENG display will round a value for display as necessary, but do not change the internal representation. That is, significant digits are retained.
Quote: So, the only benefit that was claimed for the ninth through eleventh digits was to protect the accuracy of the eight most significant digits which are displayed.
That paraphrasing is not an accurate statement. The LED TI30 may display a rounded result that is accurate to eight digits, but is not retaining eight significant digits.
Enter 1.00001 [lnx]  see "0.00001." Then, do [*] 100000 [=]  see "1."
The corresponding results from a 10digit HP35:
"9.9999 06" and ".99999"
The corresponding results from a 10digit HP11C in FIX 7:
"0.0000100" and "0.9999950".
Recall that the leading zeroes after the decimal point are not significant. Clearly, the LED TI30 is not producing and retaining even six significant digits (let alone eight) in the result of this calculation. Whether that is a result of imprecise mathematics or illadvised rounding that loses significant digits for purposes of formatting a display, it's still sloppiness.
PreSaturn HP's after the mid1970's will generally give results accurate to 10 significant digits; Saturnbased HP's will give 12 significant digits almost always.
The more I've thought about this issue that apparently was hotly debated in the past, the more I see the wisdom in HP's approach "Using sophisticated mathematical algorithms, produce a result accurate to as many significant digits as the display can accommodate, then display them all." If the user is bothered that 7[1/x][1/x] returns "7.00000000001" in ALL display mode on a 12digit Saturnbased machine, or "6.999999998" in FIX 9 on a 10digit preSaturn machine, then the user can set FIX 10 or FIX 8 to see "7.0000000000" or "7.0000000", in effect using the last digit as a guard digit.
The quote from the old TI30 manual:
"Most calculations are accurate to +/1 in the eighth digit as long as the calculator is not in scientific notation. The only exceptions are the tangent function as it approaches undefined limits and y^x where y is within 10E06 of 1."
I'm not sure why the display mode should affect computational accuracy, unless they're really referring to the displayed value. The statement about "y^x where y is within 10E06 of 1" may explain the loss of accuracy for [lnx] near 1.00.
Here are some results using the TI36X bug test for the LED TI30 and HP32S (to provide "golden gospel" to 12 digits):
n ln (1 + 1/n) (1 + 1/n)^n HP32S
10,000 0.000099995 2.7181459186 2.71814592683
100,000 1E05 2.7182818301 2.71826823717
1,000,000 1E06 2.7182818301 2.71828046932
10,000,000 1E07 2.7182818301 2.71828169254
100,000,000 1E08 2.7182818301 2.71828181487
1,000,000,000 9E10 2.4596031101 2.71828182710
10,000,000,000 1E10 2.7182818301 2.71828182832
Only three of the TI30 results (n = 1E+04, 1E+08, 1E+10) are correct to eight digits, and only the first one represents an accurate calculation. All the rest (save for the inexplicable result with n = 1E+09) are equal to the TI30's evaluation of e using [1][INV][lnx]  in which the first eight digits are correct, but the three guard digits are not.
So why am I "beating this dead horse"? Because the germane issue keeps reappearing. Recent lowend TI models have faulty math routines, as pointed out in the link above, and the HP33S also exhibits similarly curious behavior for trigonometric functions approaching threshold values:
HP33S: more examples of previous bugs
Unsophisticated aritmhmetic and sloppy handling of numbers: Not good  either yesteryear or today.
 KS
Edited: 6 Feb 2007, 11:36 p.m.
