▼
Posts: 3
Threads: 1
Joined: Jan 1970
I am wondering how often do errors occur in Calculators, I was reading a post here and it seems that one of the Calculators got the wrong answer. I currently have a 33S and a 50G and I am a college student. I see that there are errors on both of these calculators and they make me feel quite unconfident. Since I am a student and well one of the few people I know that uses HP instead of TI, how common are these errors to my failure. If my calculator is giving me wrong answers and everybody else is usuing a Ti then I am going to get screwed.
▼
Posts: 1,107
Threads: 159
Joined: Jan 1970
Unless of course, you care about the 100 something bugs in the TI-89
http://www.technicalc.org/buglist/bugs.pdf
One example for the TI-89 from that list is this:
"Integrate(1/(1+a*cos(x)),x,0,2pi) incorrectly returns zero"
So, if you're have to do that integral, you'll get the wrong answer on a TI-89, while your HP equipped fellow student might get the right answer.
All calculators (well, except the HP15c) have some errors or inputs they don't handle correctly because of an algorithm choice or just a plain bug.
A common scientific calculator from TI is the TI-36X (my son uses one in the 10th grade). Yet, it has a logarithm bug on many units. From datamath.org:
http://www.datamath.org/Story/LogarithmBug.htm
Even on TIcalc.org, you'll find this:
"ROM VERSIONS: From time to time, TI will update the internal code of their calculators to work around bugs, optimize functions, and even add features."
So, yes, HP and TI both have bugs in their calculators sometimes. That's one reason many of the higher end calculators are flash-based...to allow for upgrades of the ROM to fix bugs. Could/should HP do better? Yes! But TI is no shining counter example.
Want a calculator with no bugs? Other than the expensive HP15c and a few 4-function calculators, your choices are limited.
▼
Posts: 3
Threads: 1
Joined: Jan 1970
very good answer thanks so much,
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hello, Gene --
Thank you for the link at Datamath for the "TI logarithm bug":
http://www.datamath.org/Story/LogarithmBug.htm
I have a TI-36X purchased around 2000, which exhibits the same "bug" described. I suspect that the root problem is the absence of special calculating methods for input arguments to natural logarithm that are very near 1.00.
The example offers a fine illustration of the Taylor series
ln (1 + x) = x - x2/2 + x3/3 - x4/4 + ...
which converges for -1 < x <= 1, but slowly for large x within the range. Ten terms are needed to obtain ln(1.1) accurate to 10 significant digits (0.09531017980), but only three terms to obtain ln(1.0001) = 0.00009999500033.
The 1972 HP-35 can't quite match even the "buggy" TI models' substandard accuracy, but the 1976 original TI-30 is worse, giving the result of ln(1.00001) as exactly 0.00001, despite its 11-digit calculations. Sloppy math will nullify any benefit of extra digits carried in a calculation.
HP's after the mid-1970's nail these calculations, of course. All Saturn-based models will give ln (1 + 1E-11) = 9.99999999995E-12, which is correct to 12 significant digits. I suspect that there is an algorithmic refinement in which a truncated Taylor series or something comparable is used for very small x, instead of the usual CORDIC(?) routine for larger x. The HP-41, HP-42S, and RPL-based HP-28/48/49 made special methods directly available as a user function "ln(1+x)", which accommodates ln(1 + 1E-12) = 9.99999999999E-13, yet still gives correct answers for large values of x.
Still, this TI "Logarithm bug" pales in comparison to several of the bugs of the first-run HP-33S that were found and discussed here -- e.g., polar<->rectangular coordinate conversion and negative H.MS values.
-- KS
Edited: 3 Feb 2007, 2:46 p.m.
▼
Posts: 901
Threads: 113
Joined: Jun 2007
Quote:
The 1972 HP-35 can't quite match even the "buggy" TI models' substandard accuracy, but the 1976 original TI-30 is worse, giving the result of ln(1.00001) as exactly 0.00001, despite its 11-digit calculations. Sloppy math will nullify any benefit of extra digits carried in a calculation.
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. Page 24 of the Owner's Manual states:
"... The higher order mathematical functions use iterative calculations. The cumulative error from these calculations in most cases is maintained beyond the eight-digit display so that no inaccuracy is displayed. 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 whee y is within 10E-06 of 1."
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. I did not purchase a TI-30 at the time that device came on the market. So, my only experience with the device has been with devices that I obtained when I stated my collection. I do have a considerable amount of experience with the TI-59 which calculated thirteen digits and displayed ten digits. The Owner's Manual for the TI-59 made essentially the same points on the difference between the accuracy of the calculated value and the displayed value as was made in the Owner's Manual for the TI-30 and cautioned the user on use of all thirteen calculated digits. The user community found that the three guard digits were often quite accurate and could be used to attain results which TI had not claimed; for example, in the so-called "friendly competition" we were able to use the guard digits to factor thirteen digit integers with single precisiion calculations while the HP-67 and HP-41 could only factor ten digit integers in single precision calculations. However, both the HP-67 and the HP-41 could factor ten digit integers more rapidly than the TI-59 could, even when the TI-59 was used in fast mode. So, which calculator could provide the more powerful factor finder -- one which could factor larger integers or one that could only factor smaller integers, but faster?
Not everything that the manual stated or implied about the guard digits was true. Appendices C and D discussed the fact that t-register comparisons used the calculated values not the displayed values, and that in some cases that could lead to incorrect decisions due to differences in the guard digits. The example given was that the calculated values of the sine and cosine of 45 degrees were not equal, but were in fact different by 7E-13. The manual suggested that the problem could be circumvented by using the EE-INV-EE sequence which truncates the thirteen digit calculated values to the ten digit displayed values which are then equal. That works for 45 degrees, but I wondered if there could be sine and cosine values for which the EE-INV-EE sequence did not change unequal values to equal values. With a little effort I was able to find that
sin 39 degrees = 0.62932 03910 495
cos 51 degrees = 0.62932 03910 514
and the EE-INV-EE sequence will yield ten digit values of
sin 39 degrees = 0.62932 03910
cos 51 degrees = 0.62932 03911
I realized that if I did the EE-INV-EE sequence in Fix 8 mode then sin 39 would be equal to cos 51. Not surprisingly, with a little work one can find a sin x and cos (90 - x) combination which will not be made equal by the EE-INV-EE sequence in Fix 8 mode.
▼
Posts: 1,792
Threads: 62
Joined: Jan 2005
Hi again, Palmer --
Quote:
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.
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 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 [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 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.
-- KS
Edited: 6 Feb 2007, 11:36 p.m.
Posts: 53
Threads: 1
Joined: Sep 2005
Gene
In you excellent answer you state that the HP15c does not have errors. Is this the plea of a fan, or has there been a certification / verification process to the effect?
Thank you
Best regards
Peter
▼
Posts: 1,107
Threads: 159
Joined: Jan 1970
No errors or bugs have ever been found in the 15c to my knowledge. I don't believe it has any.
▼
Posts: 1,755
Threads: 112
Joined: Jan 2005
I concur.
After decades of heavily using one, with lots and lots of pretty complicated
programming making full use of its most obscure functionalities, I've never,
even once, seen a bug or improper operation, ever.
Can't say the same about any other software or hardware I have dealt with over my life-long career activities.
Best regards from V.
▼
Posts: 53
Threads: 1
Joined: Sep 2005
Thanks
Best regards
Peter
Posts: 122
Threads: 9
Joined: Aug 2005
What about the 11C and the rest of the Voyager family?
Posts: 3,229
Threads: 42
Joined: Jul 2006
Would this synthetic programming on the 15c count as a bug? It certainly isn't normal behaviour although it is sort of documented in the manual.
however, the bug free claim certainly has a deal of merit. I've experienced no numeric or operational problems.
- Pauli
Posts: 120
Threads: 11
Joined: Jan 1970
I don't have an exact answer, but I've gotten more errors out of Micro Soft Excel than I ever got out of all of my HP calculators combined.
Posts: 415
Threads: 19
Joined: Jan 2005
There will be times, when your calculator will fail. These are mostly errors handling complex situations, e.g. symbolic calculations.
Calculators are a tool, and you should know when to use them and when not to use them. You should as well know how to spot errors. If you are lacking the appropriate math skills, a calculator might not be of much help for you - it might even confuse you, since you don't know how to interpret results.
However basic calculations will be more or less accurate (all calculators come with only limited accuracy though) and bugs within the basic functions are very rare. So you could mostly trust your calculator when doing numerical calculations but should know what you are doing when doing symbolic stuff.
Posts: 291
Threads: 43
Joined: Jun 2007
Hello Vincent,
Most of the errors that are are brought up on this post are from calculations that are designed to push the limits of a calculators algorithims. (Such as the factorization of the gargantuan number mentioned recently, which was i think more than 30 digits long). In real world applications, such computations rarely come up.
When I was in school, my instructors weren't interested in anything beyond 3 decimal places! So use your HP's with confidence, knowing that in RPN mode (which I hope you're using) you can throw numbers around easier that your TI toting buddies can.
Best regards, Hal
▼
Posts: 122
Threads: 9
Joined: Aug 2005
Besides the 15C (which I just sold mine, darn it!... to keep the 11C instead), which are the most accurate to use professionally. I would rather want to use an LCD model instead of LED because they just seem a little more ergonomic. What about the 48GX, 32S/32SII, 41CX, and 11C?
Posts: 669
Threads: 63
Joined: Dec 2009
Speaking about errors I think this is appropriate:
from http://xkcd.com/c217.html
**vp
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
While the "bug" isn't fixed we might add the factor 1/1111 to the result :-)
Posts: 2,761
Threads: 100
Joined: Jul 2005
This is the real floating-point standard test:
e^(pi^(2413/7468)) - pi = 10/9
The HP-35 answer is 1.111111112. That's pretty good for the first scientific pocket calculator ever (the error of one unit in the least significant digit is below the maximum error the manual admits for these operations in section 2, page 21 of the manual). However, the HP-33S (CNA 411) returns 1.11111111141 ...
Of course, I won't take the time to check this on the HP-15C and HP-32SII as I am quite confident they pass the test ;-)
Gerson.
▼
Posts: 64
Threads: 8
Joined: Oct 2006
e^(Pi^(2413/7468))
on 11C = 1.111111112
on 50g in exact mode = 1.11111104137
on 50g in approx mode = 1.11111111141
I think my 50 has multiple personality disorder,
Very Respecfully,
David
▼
Posts: 2,448
Threads: 90
Joined: Jul 2005
What's the internal precision of Pi and of e in "exact" mode?
▼
Posts: 64
Threads: 8
Joined: Oct 2006
As near as I can tell, they are spot on to 12 significant digits. I think the difference happens with the XROOT function. In "exact" mode, it takes the fractional exponent of Pi^(2413/7468) and rewrites it as XROOT(7468,Pi)^2413.
That's it. Here's the breakout:
Pi^(2413/7468)=1.44755496066
XROOT(7468,Pi)^2413=1.44755494419
Very Respectfully,
David
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote:
e^(Pi^(2413/7468))
on 50g in exact mode = 1.11111104137
I got this too, the Pi^(2413/7468) got converted to:
XROOT(7468,x)^2413
which explains the loss of accuracy.
- Pauli
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
on 50g in exact mode = 1.11111104137
Same on the 49G.
I just hope the ;-) emoticon gave you a hint I was not serious about the "identity" :-)
Regards,
Gerson.
Edited: 4 Feb 2007, 10:47 p.m.
Posts: 64
Threads: 4
Joined: Jan 1970
My usual "alternative" contender, the Organiser II, says 1.11111111142
Posts: 2,448
Threads: 90
Joined: Jul 2005
Hi Gerson,
All the Pioneers get the same as the 33s.
The Voyagers do as the HP-35 does.
Regards,
Bill
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hello Bill,
I know this! I think I would have fooled a lot of people in 1972. They would have taken that for rounding error :-)
Some fractions to play with:
194/6930 (-0.33333335119)
1603/2022 ( 8.77777772331)
1624/4419 ( 1.44444449442)
3716/9750 ( 1.55555556853)
5108/5150 (19.3333333054 )
Regards,
Gerson.
Edited: 4 Feb 2007, 10:19 p.m.
▼
Posts: 230
Threads: 11
Joined: Jan 1970
That's funny, but of course not exact.
How do you find those near-equalities ?
Please do not say "brute force" !
Posts: 2,448
Threads: 90
Joined: Jul 2005
What do you make of this website: http://3.141592653589793238462643383279502884197169399375105820974944592.com/
(I didn't drill through the links though).
Edited: 4 Feb 2007, 10:01 p.m.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
At first I thought that was a mnemonic to remember pi to a lot of places :-)
Quote:
(I didn't drill through the links though).
Neither did I!
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote:
This is the real floating-point standard test:
e^(pi^(2413/7468)) - pi = 10/9
My 32Sii is at home but for those I've got to hand:
49g returns 1.11111111141
42s returns 1.11111111141
15c returns 1.111111112
12c returns 1.111111112
6s returns 1.111111111 (36) the last two being guard digits
- Pauli
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
6s returns 1.111111111 (36) the last two being guard digits
I'll remember to use the 6S when demonstrating the "identity" (but I won't mention the guard digits!) :-)
The 32SII returns the same 33S result. That's what I obtained with QBASIC:
1.11111111140003
Regards,
Gerson.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote:
I'll remember to use the 6S when demonstrating the "identity" (but I won't mention the guard digits!) :-)
Or set FIX 9 mode :-)
- Pauli
Posts: 37
Threads: 5
Joined: Jan 1970
Mmh, my 15C returns 1.111111111, not 1.111111112. Why?
Frank.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
What is the serial number? All of mine return 1.111111112.
Looks like you have a special 15C. Keep it!
Regards,
Gerson.
▼
Posts: 37
Threads: 5
Joined: Jan 1970
Serial number of the 15C is 2442A05...
My 33s (CNA411...) returns the already quoted result with 141 as last digits.
Frank.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
In fact I still have to test it on my 2343B***** 15C. Can you please show us a step-by-step calculation?
2413
pi
x<>y
7468 / 0.3231119443
y^x 1.447554961
e^x 4.252703766
pi - 1.111111112
Thanks,
Gerson.
▼
Posts: 416
Threads: 78
Joined: Mar 2006
My HP-11C (2848AXXXX) returns 1.111111112.
- Antonio
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Ciao, Antonio!
Quote:
(2848AXXXX)
For I moment I thought you were using roman numerals :-)
I've read there are at least a couple of HP-15C ROM versions, if I am not wrong. Frank's result may confirm this.
Best regards,
Gerson.
Posts: 37
Threads: 5
Joined: Jan 1970
ah, I did it in a more complicated way.
2413
7468
/
pi
x<>y
y^x
1
e^x
x<>y
y^x
pi
-
The crucial step is using "e^1" for y^x, and not e^x. Using e^x I get 12 as the two last digits.
Frank.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Thanks!
I thought you had a different ROM version (I read there were a couple of them). Anyway this might be useful to demonstrate the faithful 15C passes the test while newer calculators like the HP-50G don't :-)
Gerson.
-----------------
Actually the answers on 10-digit and 12-digit calculators should be 1.111111111 and 1.11111111140, respectively, given the result to 16 significant digits on the HP-200LX: 1.111111111400025.
Edited: 5 Feb 2007, 5:00 p.m.
Posts: 64
Threads: 4
Joined: Jan 1970
My HP-11C (SN 2544A*****) says 1.111111112
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
6s returns 1.111111111 (36) the last two being guard digits
By the way, the only other 10-digit calculator I have that returns the correct 10 significant-digit result on the display is the HP-12C Platinum:
1.111111111 (26)
Gerson.
▼
Posts: 32
Threads: 3
Joined: Jan 1970
A TI 83 gives 1.111111111. A TI 82 gives 1.111111110
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Thanks!
HP calculators have a few guard digits (except the first and most of the latest ones), but they round the answers to the number of digits of the display after each calculation. TI calculators also have some guard digits, but the previous answers are not rounded. This might explain the differences in the last significant digit.
Gerson.
Posts: 875
Threads: 37
Joined: Jul 2005
Gerson,
Did you find a secret Pi button on the 12CP? I wish there was one! Assuming there is not, what value did you use for Pi? That is somewhat of a rhetorical question, as I can replicate your result only by using 3.141592654, i.e., Pi rounded to ten digits. Another possibility would be to use Pi truncated to 10 digits. Also, since the 12CP carries 12 digits internally, utilizing Pi rounded or truncated to 12 digits might be a better test of the 12CP's capabilities. As I see it, the above four possibilities are summarized as follows:
Representation of Pi Displayed 10 digit Result Actual 12 digit result
3.141592653 1.111111112 1.11111111162
3.141592654 1.111111111 1.11111111126
3.14159265358 1.111111111 1.11111111142
3.14159265359 1.111111111 1.11111111141
The accurate result to 16 digits was given elsewhere in this thread as 1.111111111400025. So it seems that the most accurate result is obtained using Pi rounded to 12 digits, in which case the answer has 11 correct digits, with the 12 digit result off by 1 ulp. I'm not sure what this proves about the 12CP.
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
Did you find a secret Pi button on the 12CP?
Sorry! I thought I had mentioned I had used 3.141592654. My 12CP is loaded with my trig program, so I compute acos(-1) in radians mode when I want to get pi to more than 10 digits (I don't have the 12CP here, but I think there is an error of one unit in the 12th digit). But for this test I used the usual 10-digit approximation.
Regards,
Gerson.
Update:
I get 3.14159265360 for acos(-1), to which the expression yields 1.111111111 (40)
Edited: 7 Feb 2007, 2:44 p.m.
|
