The Museum of HP Calculators

HP Forum Archive 16

 Errors in Calculators.Message #1 Posted by Vincent Perricone on 2 Feb 2007, 4:26 p.m. 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.

 Re: Errors in Calculators.Message #2 Posted by Gene on 2 Feb 2007, 5:00 p.m.,in response to message #1 by Vincent Perricone Unless of course, you care about the 100 something bugs in the TI-89 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: 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.

 Re: Errors in Calculators.Message #3 Posted by Vincent Perricone on 2 Feb 2007, 6:07 p.m.,in response to message #2 by Gene very good answer thanks so much,

 Re: Errors in Calculators.Message #4 Posted by Karl Schneider on 3 Feb 2007, 3:23 a.m.,in response to message #2 by Gene Hello, Gene -- Thank you for the link at Datamath for the "TI logarithm bug": 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.

 Re: Errors in Calculators.Message #5 Posted by Palmer O. Hanson, Jr. on 4 Feb 2007, 11:45 p.m.,in response to message #4 by Karl Schneider 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.

 Old TI-30 accuracy & HP-33SMessage #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 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: Unsophisticated aritmhmetic and sloppy handling of numbers: Not good -- either yesteryear or today. -- KS Edited: 6 Feb 2007, 11:36 p.m.

 Re: Errors in Calculators.Message #7 Posted by Peter Geiser on 3 Feb 2007, 4:40 a.m.,in response to message #2 by Gene 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

 Re: Errors in Calculators.Message #8 Posted by Gene on 3 Feb 2007, 10:36 a.m.,in response to message #7 by Peter Geiser No errors or bugs have ever been found in the 15c to my knowledge. I don't believe it has any.

 Re: Errors in Calculators.Message #9 Posted by Valentin Albillo on 3 Feb 2007, 2:08 p.m.,in response to message #8 by Gene 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.

 Re: Errors in Calculators.Message #10 Posted by Peter Geiser on 3 Feb 2007, 2:29 p.m.,in response to message #9 by Valentin Albillo Thanks Best regards Peter

 Re: Errors in Calculators.Message #11 Posted by Stephen Easterling on 3 Feb 2007, 7:31 p.m.,in response to message #8 by Gene What about the 11C and the rest of the Voyager family?

 Re: Errors in Calculators.Message #12 Posted by Paul Dale on 4 Feb 2007, 7:39 p.m.,in response to message #8 by Gene 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

 Re: Errors in Calculators.Message #13 Posted by unspellable on 2 Feb 2007, 5:01 p.m.,in response to message #1 by Vincent Perricone 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.

 Re: Errors in Calculators.Message #14 Posted by Frank Boehm on 2 Feb 2007, 5:02 p.m.,in response to message #1 by Vincent Perricone 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.

 Re: Errors in Calculators.Message #15 Posted by Hal Bitton on 2 Feb 2007, 7:20 p.m.,in response to message #1 by Vincent Perricone 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

 Re: Errors in Calculators.Message #16 Posted by Stephen Easterling on 2 Feb 2007, 9:12 p.m.,in response to message #15 by Hal Bitton 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?

 Re: Errors in Calculators. (e^pi - pi)Message #17 Posted by Vassilis Prevelakis on 3 Feb 2007, 9:34 a.m.,in response to message #1 by Vincent Perricone Speaking about errors I think this is appropriate: **vp

 Re: Errors in Calculators. (e^pi - pi)Message #18 Posted by bill platt on 3 Feb 2007, 5:37 p.m.,in response to message #17 by Vassilis Prevelakis Love it!

 Re: Errors in Calculators. (e^pi - pi)Message #19 Posted by Gerson W. Barbosa on 3 Feb 2007, 7:02 p.m.,in response to message #18 by bill platt While the "bug" isn't fixed we might add the factor 1/1111 to the result :-)

 Re: Errors in Calculators. (e^pi - pi)Message #20 Posted by Gerson W. Barbosa on 4 Feb 2007, 9:38 p.m.,in response to message #17 by Vassilis Prevelakis 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.

 Re: Errors in Calculators. (e^pi - pi)Message #21 Posted by bill platt on 4 Feb 2007, 9:54 p.m.,in response to message #20 by Gerson W. Barbosa Hi Gerson, All the Pioneers get the same as the 33s. The Voyagers do as the HP-35 does. Regards, Bill

 Re: Errors in Calculators. (e^pi - pi)Message #22 Posted by Gerson W. Barbosa on 4 Feb 2007, 10:14 p.m.,in response to message #21 by bill platt 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.

 Re: Errors in Calculators. (e^pi - pi)Message #23 Posted by GE on 5 Feb 2007, 6:45 a.m.,in response to message #22 by Gerson W. Barbosa That's funny, but of course not exact. How do you find those near-equalities ? Please do not say "brute force" !

 Re: Errors in Calculators. (e^pi - pi)Message #24 Posted by dbatiz on 4 Feb 2007, 9:54 p.m.,in response to message #20 by Gerson W. Barbosa 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

 Re: Errors in Calculators. (e^pi - pi)Message #25 Posted by bill platt on 4 Feb 2007, 10:07 p.m.,in response to message #24 by dbatiz What's the internal precision of Pi and of e in "exact" mode?

 Re: Errors in Calculators. (e^pi - pi)Message #26 Posted by dbatiz on 4 Feb 2007, 10:31 p.m.,in response to message #25 by bill platt 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

 Re: Errors in Calculators. (e^pi - pi)Message #27 Posted by Paul Dale on 4 Feb 2007, 10:22 p.m.,in response to message #24 by dbatiz 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

 Re: Errors in Calculators. (e^pi - pi)Message #28 Posted by Gerson W. Barbosa on 4 Feb 2007, 10:45 p.m.,in response to message #24 by dbatiz 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.

 Re: Errors in Calculators. (e^pi - pi)Message #29 Posted by Chris Roccati on 5 Feb 2007, 12:39 p.m.,in response to message #24 by dbatiz My usual "alternative" contender, the Organiser II, says 1.11111111142

 Re: Errors in Calculators. (e^pi - pi)Message #30 Posted by bill platt on 4 Feb 2007, 10:00 p.m.,in response to message #20 by Gerson W. Barbosa 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.

 Re: Errors in Calculators. (e^pi - pi)Message #31 Posted by Gerson W. Barbosa on 4 Feb 2007, 11:02 p.m.,in response to message #30 by bill platt 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!

 Re: Errors in Calculators. (e^pi - pi)Message #32 Posted by Paul Dale on 4 Feb 2007, 10:19 p.m.,in response to message #20 by Gerson W. Barbosa 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

 Re: Errors in Calculators. (e^pi - pi)Message #33 Posted by Gerson W. Barbosa on 4 Feb 2007, 10:33 p.m.,in response to message #32 by Paul Dale 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.

 Re: Errors in Calculators. (e^pi - pi)Message #34 Posted by Paul Dale on 4 Feb 2007, 10:43 p.m.,in response to message #33 by Gerson W. Barbosa 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

 Re: Errors in Calculators. (e^pi - pi)Message #35 Posted by Frank B. (Germany) on 5 Feb 2007, 5:24 a.m.,in response to message #32 by Paul Dale Mmh, my 15C returns 1.111111111, not 1.111111112. Why? Frank.

 Re: Errors in Calculators. (e^pi - pi)Message #36 Posted by Gerson W. Barbosa on 5 Feb 2007, 7:53 a.m.,in response to message #35 by Frank B. (Germany) What is the serial number? All of mine return 1.111111112. Looks like you have a special 15C. Keep it! Regards, Gerson.

 Re: Errors in Calculators. (e^pi - pi)Message #37 Posted by Frank B. (Germany) on 5 Feb 2007, 11:47 a.m.,in response to message #36 by Gerson W. Barbosa Serial number of the 15C is 2442A05... My 33s (CNA411...) returns the already quoted result with 141 as last digits. Frank.

 Re: Errors in Calculators. (e^pi - pi)Message #38 Posted by Gerson W. Barbosa on 5 Feb 2007, 12:05 p.m.,in response to message #37 by Frank B. (Germany) 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.

 Re: Errors in Calculators. (e^pi - pi)Message #39 Posted by Antonio Maschio (Italy) on 5 Feb 2007, 12:32 p.m.,in response to message #38 by Gerson W. Barbosa My HP-11C (2848AXXXX) returns 1.111111112. - Antonio

 Re: Errors in Calculators. (e^pi - pi)Message #40 Posted by Gerson W. Barbosa on 5 Feb 2007, 12:53 p.m.,in response to message #39 by Antonio Maschio (Italy) 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.

 Re: Errors in Calculators. (e^pi - pi)Message #41 Posted by Frank B. (Germany) on 5 Feb 2007, 12:40 p.m.,in response to message #38 by Gerson W. Barbosa 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.

 Re: Errors in Calculators. (e^pi - pi)Message #42 Posted by Gerson W. Barbosa on 5 Feb 2007, 1:14 p.m.,in response to message #41 by Frank B. (Germany) 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.

 Re: Errors in Calculators. (e^pi - pi)Message #43 Posted by Chris Roccati on 5 Feb 2007, 12:49 p.m.,in response to message #38 by Gerson W. Barbosa My HP-11C (SN 2544A*****) says 1.111111112

 Re: Errors in Calculators. (e^pi - pi)Message #44 Posted by Gerson W. Barbosa on 6 Feb 2007, 8:27 p.m.,in response to message #32 by Paul Dale 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.

 anotherMessage #45 Posted by M. Currie on 7 Feb 2007, 12:08 a.m.,in response to message #44 by Gerson W. Barbosa A TI 83 gives 1.111111111. A TI 82 gives 1.111111110

 Re: anotherMessage #46 Posted by Gerson W. Barbosa on 7 Feb 2007, 10:56 a.m.,in response to message #45 by M. Currie 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.

 Re: Errors in Calculators. (e^pi - pi)Message #47 Posted by Jeff O. on 7 Feb 2007, 12:18 p.m.,in response to message #44 by Gerson W. Barbosa 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.

 Re: Errors in Calculators. (e^pi - pi)Message #48 Posted by Gerson W. Barbosa on 7 Feb 2007, 1:23 p.m.,in response to message #47 by Jeff O. 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.

Go back to the main exhibit hall