Errors in Calculators. « Next Oldest | Next Newest »

 ▼ Vincent Perricone Junior Member Posts: 3 Threads: 1 Joined: Jan 1970 02-02-2007, 04:26 PM 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. ▼ Gene Posting Freak Posts: 1,107 Threads: 159 Joined: Jan 1970 02-02-2007, 05:00 PM 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. ▼ Vincent Perricone Junior Member Posts: 3 Threads: 1 Joined: Jan 1970 02-02-2007, 06:07 PM very good answer thanks so much, Karl Schneider Posting Freak Posts: 1,792 Threads: 62 Joined: Jan 2005 02-03-2007, 03:23 AM 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. ▼ Palmer O. Hanson, Jr. Posting Freak Posts: 901 Threads: 113 Joined: Jun 2007 02-04-2007, 11:45 PM 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. ▼ Karl Schneider Posting Freak Posts: 1,792 Threads: 62 Joined: Jan 2005 02-05-2007, 03:16 AM 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. Peter Geiser Member Posts: 53 Threads: 1 Joined: Sep 2005 02-03-2007, 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 Best regards Peter ▼ Gene Posting Freak Posts: 1,107 Threads: 159 Joined: Jan 1970 02-03-2007, 10:36 AM No errors or bugs have ever been found in the 15c to my knowledge. I don't believe it has any. ▼ Valentin Albillo Posting Freak Posts: 1,755 Threads: 112 Joined: Jan 2005 02-03-2007, 02:08 PM 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. ▼ Peter Geiser Member Posts: 53 Threads: 1 Joined: Sep 2005 02-03-2007, 02:29 PM Thanks Best regards Peter Stephen Easterling Member Posts: 122 Threads: 9 Joined: Aug 2005 02-03-2007, 07:31 PM What about the 11C and the rest of the Voyager family? Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 02-04-2007, 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. - Pauli unspellable Member Posts: 120 Threads: 11 Joined: Jan 1970 02-02-2007, 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. Frank Boehm (Germany) Senior Member Posts: 415 Threads: 19 Joined: Jan 2005 02-02-2007, 05:02 PM 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. Hal Bitton in Boise Senior Member Posts: 291 Threads: 43 Joined: Jun 2007 02-02-2007, 07:20 PM 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 ▼ Stephen Easterling Member Posts: 122 Threads: 9 Joined: Aug 2005 02-02-2007, 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? Vassilis Prevelakis Senior Member Posts: 669 Threads: 63 Joined: Dec 2009 02-03-2007, 09:34 AM Speaking about errors I think this is appropriate: **vp ▼ bill platt Posting Freak Posts: 2,448 Threads: 90 Joined: Jul 2005 02-03-2007, 05:37 PM Love it! ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-03-2007, 07:02 PM While the "bug" isn't fixed we might add the factor 1/1111 to the result :-) Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-04-2007, 09:38 PM 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. ▼ bill platt Posting Freak Posts: 2,448 Threads: 90 Joined: Jul 2005 02-04-2007, 09:54 PM Hi Gerson, All the Pioneers get the same as the 33s. The Voyagers do as the HP-35 does. Regards, Bill ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-04-2007, 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) 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. ▼ GE Member Posts: 230 Threads: 11 Joined: Jan 1970 02-05-2007, 06:45 AM That's funny, but of course not exact. How do you find those near-equalities ? Please do not say "brute force" ! dbatiz Member Posts: 64 Threads: 8 Joined: Oct 2006 02-04-2007, 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, David ▼ bill platt Posting Freak Posts: 2,448 Threads: 90 Joined: Jul 2005 02-04-2007, 10:07 PM What's the internal precision of Pi and of e in "exact" mode? ▼ dbatiz Member Posts: 64 Threads: 8 Joined: Oct 2006 02-04-2007, 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, David Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 02-04-2007, 10:22 PM 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 Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-04-2007, 10:45 PM 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. Chris Roccati Member Posts: 64 Threads: 4 Joined: Jan 1970 02-05-2007, 12:39 PM My usual "alternative" contender, the Organiser II, says 1.11111111142 bill platt Posting Freak Posts: 2,448 Threads: 90 Joined: Jul 2005 02-04-2007, 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. ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-04-2007, 11:02 PM 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! Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 02-04-2007, 10:19 PM 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 ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-04-2007, 10:33 PM 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. ▼ Paul Dale Posting Freak Posts: 3,229 Threads: 42 Joined: Jul 2006 02-04-2007, 10:43 PM 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 Frank B. (Germany) Junior Member Posts: 37 Threads: 5 Joined: Jan 1970 02-05-2007, 05:24 AM Mmh, my 15C returns 1.111111111, not 1.111111112. Why? Frank. ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-05-2007, 07:53 AM What is the serial number? All of mine return 1.111111112. Looks like you have a special 15C. Keep it! Regards, Gerson. ▼ Frank B. (Germany) Junior Member Posts: 37 Threads: 5 Joined: Jan 1970 02-05-2007, 11:47 AM Serial number of the 15C is 2442A05... My 33s (CNA411...) returns the already quoted result with 141 as last digits. Frank. ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-05-2007, 12:05 PM 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. ▼ Antonio Maschio (Italy) Senior Member Posts: 416 Threads: 78 Joined: Mar 2006 02-05-2007, 12:32 PM My HP-11C (2848AXXXX) returns 1.111111112. - Antonio ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-05-2007, 12:53 PM 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. Frank B. (Germany) Junior Member Posts: 37 Threads: 5 Joined: Jan 1970 02-05-2007, 12:40 PM 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. ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-05-2007, 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 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. Chris Roccati Member Posts: 64 Threads: 4 Joined: Jan 1970 02-05-2007, 12:49 PM My HP-11C (SN 2544A*****) says 1.111111112 Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-06-2007, 08:27 PM 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. ▼ m currie Junior Member Posts: 32 Threads: 3 Joined: Jan 1970 02-07-2007, 12:08 AM A TI 83 gives 1.111111111. A TI 82 gives 1.111111110 ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-07-2007, 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. Jeff O. Posting Freak Posts: 875 Threads: 37 Joined: Jul 2005 02-07-2007, 12:18 PM 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. ▼ Gerson W. Barbosa Posting Freak Posts: 2,761 Threads: 100 Joined: Jul 2005 02-07-2007, 01:23 PM 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.

 Possibly Related Threads... Thread Author Replies Views Last Post HP Prime editor errors Alberto Candel 0 719 10-22-2013, 01:34 AM Last Post: Alberto Candel Paper on the errors in HP Calculators vs some older computer processors Les Koller 3 1,283 08-19-2013, 12:37 PM Last Post: Mike Morrow Estimating Accumulated Rounding Errors Egan Ford 13 2,372 08-16-2012, 01:49 PM Last Post: Egan Ford HP-28S Syntax Errors William N Strew 7 1,879 07-15-2012, 05:09 PM Last Post: Luiz C. Vieira (Brazil) Some errors about NOMAS, (c) of 71B ROM images Christoph Giesselink 4 1,272 06-13-2012, 04:10 AM Last Post: Valentin Albillo Errors reading with a HP 82153A Barcode Optical Wand aurelio 22 4,109 04-04-2012, 05:19 PM Last Post: Les Wright Rounding errors BruceH 4 1,255 11-22-2009, 11:24 AM Last Post: Vieira, Luiz C. (Brazil) Before I had HP calculators, I had Sharp calculators hecube 7 1,567 08-26-2009, 06:57 AM Last Post: Mark Edmonds Torsten Manz 15c emulator errors...? McBenney 1 608 06-24-2009, 09:52 PM Last Post: Thomas Okken HP49G+ Conn4x errors Matthew Beech 3 907 08-27-2004, 03:24 PM Last Post: Matthew Beech

Forum Jump: