Errors in Calculators.



#17

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.


#18

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.


#19

very good answer thanks so much,

#20

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.


#21

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.


#22

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.

#23

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


#24

No errors or bugs have ever been found in the 15c to my knowledge. I don't believe it has any.


#25

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.


#26

Thanks

Best regards

Peter

#27

What about the 11C and the rest of the Voyager family?

#28

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

#29

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.

#30

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.

#31

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


#32

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?

#33

Speaking about errors I think this is appropriate:

from http://xkcd.com/c217.html

**vp


#34

Love it!


#35

While the "bug" isn't fixed we might add the factor 1/1111 to the result :-)

#36

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.


#37

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


#38

What's the internal precision of Pi and of e in "exact" mode?


#39

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

#40

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

#41

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.

#42

My usual "alternative" contender, the Organiser II, says 1.11111111142

#43

Hi Gerson,

All the Pioneers get the same as the 33s.

The Voyagers do as the HP-35 does.

Regards,

Bill


#44

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.


#45

That's funny, but of course not exact.

How do you find those near-equalities ?

Please do not say "brute force" !

#46

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.


#47

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!

#48

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


#49

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.


#50

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

#51

Mmh, my 15C returns 1.111111111, not 1.111111112. Why?

Frank.


#52

What is the serial number? All of mine return 1.111111112.
Looks like you have a special 15C. Keep it!

Regards,

Gerson.


#53

Serial number of the 15C is 2442A05...

My 33s (CNA411...) returns the already quoted result with 141 as last digits.

Frank.


#54

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.


#55

My HP-11C (2848AXXXX) returns 1.111111112.

- Antonio


#56

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.

#57

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.


#58

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.

#59

My HP-11C (SN 2544A*****) says 1.111111112

#60

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.


#61

A TI 83 gives 1.111111111. A TI 82 gives 1.111111110


#62

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.

#63

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.

#64

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 1,004 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,828 08-19-2013, 12:37 PM
Last Post: Mike Morrow
  Estimating Accumulated Rounding Errors Egan Ford 13 3,469 08-16-2012, 01:49 PM
Last Post: Egan Ford
  HP-28S Syntax Errors William N Strew 7 2,669 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,849 06-13-2012, 04:10 AM
Last Post: Valentin Albillo
  Errors reading with a HP 82153A Barcode Optical Wand aurelio 22 6,189 04-04-2012, 05:19 PM
Last Post: Les Wright
  Rounding errors BruceH 4 1,729 11-22-2009, 11:24 AM
Last Post: Vieira, Luiz C. (Brazil)
  Before I had HP calculators, I had Sharp calculators hecube 7 2,551 08-26-2009, 06:57 AM
Last Post: Mark Edmonds
  Torsten Manz 15c emulator errors...? McBenney 1 831 06-24-2009, 09:52 PM
Last Post: Thomas Okken
  HP49G+ Conn4x errors Matthew Beech 3 1,210 08-27-2004, 03:24 PM
Last Post: Matthew Beech

Forum Jump: