|Old TI-30 accuracy & HP-33S|
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 --
Once again I will quote from the manual. The Owner's Manual for the TI-30 explains that calculations produce an 11-digit result but that only an 8-digit rounded result is displayed.
The exact quote is,
"Each calculation produces an 11-digit result. These 11 digits are more than are displayed. The result is therefore rounded to a(n) 8-digit 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.
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 TI-30 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 10-digit HP-35:
"9.9999 -06" and ".99999"
The corresponding results from a 10-digit HP-11C in FIX 7:
"0.0000100" and "0.9999950".
Recall that the leading zeroes after the decimal point are not significant. Clearly, the LED TI-30 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 ill-advised rounding that loses significant digits for purposes of formatting a display, it's still sloppiness.
Pre-Saturn HP's after the mid-1970's will generally give results accurate to 10 significant digits; Saturn-based 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 12-digit Saturn-based machine, or "6.999999998" in FIX 9 on a 10-digit pre-Saturn 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 TI-30 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 10E-06 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 10E-06 of 1" may explain the loss of accuracy for [lnx] near 1.00.
Here are some results using the TI-36X bug test for the LED TI-30 and HP-32S (to provide "golden gospel" to 12 digits):
n ln (1 + 1/n) (1 + 1/n)^n HP-32S
10,000 0.000099995 2.7181459186 2.71814592683
100,000 1E-05 2.7182818301 2.71826823717
1,000,000 1E-06 2.7182818301 2.71828046932
10,000,000 1E-07 2.7182818301 2.71828169254
100,000,000 1E-08 2.7182818301 2.71828181487
1,000,000,000 9E-10 2.4596031101 2.71828182710
10,000,000,000 1E-10 2.7182818301 2.71828182832
Only three of the TI-30 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 TI-30's evaluation of e using [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 low-end TI models have faulty math routines, as pointed out in the link above, and the HP-33S also exhibits similarly curious behavior for trigonometric functions approaching threshold values:
HP-33S: more examples of previous bugs
Unsophisticated aritmhmetic and sloppy handling of numbers: Not good -- either yesteryear or today.
Edited: 6 Feb 2007, 11:36 p.m.