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.
Errors in Calculators.


« Next Oldest  Next Newest »

▼
02022007, 04:26 PM
▼
02022007, 05:00 PM
Unless of course, you care about the 100 something bugs in the TI89 http://www.technicalc.org/buglist/bugs.pdf One example for the TI89 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 TI89, 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 TI36X (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 flashbased...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 4function calculators, your choices are limited. ▼
02022007, 06:07 PM
very good answer thanks so much,
02032007, 03:23 AM
Hello, Gene  Thank you for the link at Datamath for the "TI logarithm bug": http://www.datamath.org/Story/LogarithmBug.htm I have a TI36X 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  x^{2}/2 + x^{3}/3  x^{4}/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 HP35 can't quite match even the "buggy" TI models' substandard accuracy, but the 1976 original TI30 is worse, giving the result of ln(1.00001) as exactly 0.00001, despite its 11digit calculations. Sloppy math will nullify any benefit of extra digits carried in a calculation. HP's after the mid1970's nail these calculations, of course. All Saturnbased models will give ln (1 + 1E11) = 9.99999999995E12, 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 HP41, HP42S, and RPLbased HP28/48/49 made special methods directly available as a user function "ln(1+x)", which accommodates ln(1 + 1E12) = 9.99999999999E13, 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 firstrun HP33S 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. ▼
02042007, 11:45 PM
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. 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 eightdigit 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 10E06 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 TI30 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 TI59 which calculated thirteen digits and displayed ten digits. The Owner's Manual for the TI59 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 TI30 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 socalled "friendly competition" we were able to use the guard digits to factor thirteen digit integers with single precisiion calculations while the HP67 and HP41 could only factor ten digit integers in single precision calculations. However, both the HP67 and the HP41 could factor ten digit integers more rapidly than the TI59 could, even when the TI59 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 tregister 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 7E13. The manual suggested that the problem could be circumvented by using the EEINVEE 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 EEINVEE 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 EEINVEE 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 EEINVEE 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 EEINVEE sequence in Fix 8 mode.
▼
02052007, 03:16 AM
Hi again, Palmer 
Quote: 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: 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.
n ln (1 + 1/n) (1 + 1/n)^n HP32S 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.
02032007, 04:40 AM
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 ▼
02032007, 10:36 AM
No errors or bugs have ever been found in the 15c to my knowledge. I don't believe it has any. ▼
02032007, 02:08 PM
I concur.
After decades of heavily using one, with lots and lots of pretty complicated Can't say the same about any other software or hardware I have dealt with over my lifelong career activities. Best regards from V.
02032007, 07:31 PM
What about the 11C and the rest of the Voyager family?
02042007, 07:39 PM
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.
02022007, 05:01 PM
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.
02022007, 05:02 PM
There will be times, when your calculator will fail. These are mostly errors handling complex situations, e.g. symbolic calculations. 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.
02022007, 07:20 PM
Hello Vincent, ▼
02022007, 09:12 PM
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?
02032007, 09:34 AM
▼
02032007, 05:37 PM
Love it!
02042007, 09:38 PM
This is the real floatingpoint standard test:
e^(pi^(2413/7468))  pi = 10/9 The HP35 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 HP33S (CNA 411) returns 1.11111111141 ... Of course, I won't take the time to check this on the HP15C and HP32SII as I am quite confident they pass the test ;) Gerson.
▼
02042007, 09:54 PM
Hi Gerson, All the Pioneers get the same as the 33s. The Voyagers do as the HP35 does. Regards, Bill ▼
02042007, 10:14 PM
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) Regards, Gerson.
Edited: 4 Feb 2007, 10:19 p.m.
02042007, 09:54 PM
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, ▼
02042007, 10:07 PM
What's the internal precision of Pi and of e in "exact" mode? ▼
02042007, 10:31 PM
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,
02042007, 10:22 PM
Quote: I got this too, the Pi^(2413/7468) got converted to:
XROOT(7468,x)^2413 which explains the loss of accuracy.
02042007, 10:45 PM
Quote: 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.
02052007, 12:39 PM
My usual "alternative" contender, the Organiser II, says 1.11111111142
02042007, 10:00 PM
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. ▼
02042007, 11:02 PM
At first I thought that was a mnemonic to remember pi to a lot of places :)
Quote: Neither did I!
02042007, 10:19 PM
Quote:
My 32Sii is at home but for those I've got to hand: 49g returns 1.11111111141
▼
02042007, 10:33 PM
Quote: I'll remember to use the 6S when demonstrating the "identity" (but I won't mention the guard digits!) :)
1.11111111140003 Regards, Gerson. ▼
02042007, 10:43 PM
Quote: Or set FIX 9 mode :)
02052007, 05:24 AM
Mmh, my 15C returns 1.111111111, not 1.111111112. Why? Frank. ▼
02052007, 07:53 AM
What is the serial number? All of mine return 1.111111112. Regards, Gerson. ▼
02052007, 11:47 AM
Serial number of the 15C is 2442A05... My 33s (CNA411...) returns the already quoted result with 141 as last digits. Frank. ▼
02052007, 12:05 PM
In fact I still have to test it on my 2343B***** 15C. Can you please show us a stepbystep calculation?
Thanks, Gerson. ▼
02052007, 12:32 PM
My HP11C (2848AXXXX) returns 1.111111112.  Antonio ▼
02052007, 12:53 PM
Ciao, Antonio!
Quote: For I moment I thought you were using roman numerals :) I've read there are at least a couple of HP15C ROM versions, if I am not wrong. Frank's result may confirm this. Best regards, Gerson.
02052007, 12:40 PM
ah, I did it in a more complicated way.
2413 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. ▼
02052007, 01:14 PM
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 HP50G don't :) Gerson.  Actually the answers on 10digit and 12digit calculators should be 1.111111111 and 1.11111111140, respectively, given the result to 16 significant digits on the HP200LX: 1.111111111400025.
Edited: 5 Feb 2007, 5:00 p.m.
02052007, 12:49 PM
My HP11C (SN 2544A*****) says 1.111111112
02062007, 08:27 PM
Quote: By the way, the only other 10digit calculator I have that returns the correct 10 significantdigit result on the display is the HP12C Platinum:
1.111111111 (26) Gerson.
▼
02072007, 12:08 AM
A TI 83 gives 1.111111111. A TI 82 gives 1.111111110 ▼
02072007, 10:56 AM
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.
02072007, 12:18 PM
Gerson, Representation of Pi Displayed 10 digit Result Actual 12 digit resultThe 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. ▼
02072007, 01:23 PM
Quote: 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 10digit 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. 