HP y^x Bug?



#2

I have started collecting HP calcs recently, and just obtained a few erlier HP. I have noticed that when I enter y^x functions that it is not calculating them correctly. For instance, if I enter 7^8, it answers 5764800.985 rather than 5764801, 9^3 is 728.9999992 instead of 729. Is this common of the LED HPs? My HP-41C does not exhibit this.


#3

I tried your two examples on my calculators with the following results (calculators set to FIX 9 or DSP 9 except the 35):

model      (7^8)            (9^3)
35* 5764800.986 728.9999993
35 5764800.985 728.9999992
45 same same
25 same same
65 same same
67 5764801.000 729.0000000
34C same same

*35 with ROM bug

It looks like HP changed the algorithm along the way and finally fixed it. I expect it is just a matter of checking for whole numbers first, to save embarrassment!


#4

It's not a bug at all, any numerical algorithm is bound to
give only a limited precision, as both approximations to trascendental functions (log, sin, etc) and rounding errors caused by finite precision affect the overall accuracy attainable.

HP programmers were fully awara of the situation, and there were several articles in the "HP Journal" dealing with this topic. You may want to read these two:

"Algorithms and Accuracy in the HP-35"
"Making 2^3 = 8"

The last one deals with exactly the situation you describe.

#5

I think that HP went to internal accuracy greater than the display capability of their calculators to prevent things like this from happening. Such as an 11c having a 10 digit display but having 12 digit internal accuracy or something along those lines. Then, the rounding would make the display read the correct answer.

#6

When HP calculators first appeared, most science and engineering calculations where done on slide rules which yielded 3-4 digits if you were careful. The early calculators were mostly bought by people who were used to these limits. Besides most real-world measurements that they use in their calculations don't exceed 2 to 4 digits of precision anyway, and scientists understand the concept of significant digits.

I think the drive to more accuracy came mostly when calculators became cheap enough for students. Then calculators became less of an engineering tool and more of a pure math tool and many of the owners got calculators before learning about significant digits and also before learning that floating point numbers are approximations. This lead to improved accuracy and also to the "trick" of calculating more digits than you will allow the user to see. (If the user doesn't like or understand the approximate nature of floating point - hide it.)

By the way, back when "The Pentium Bug" was all the rage, someone reported finding "The Pentium Bug" in the HP-48. He did 1 divided by 3 times 3 and got (gasp!) .999999999999 instead of 1.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP Prime graphing bug BruceH 1 582 11-19-2013, 08:14 AM
Last Post: Joe Horn
  HP Prime - another cosmetic bug BruceH 3 739 11-12-2013, 02:18 PM
Last Post: Ken Shaw
  HP Prime Bug bluesun08 19 2,237 10-14-2013, 10:48 PM
Last Post: Han
  HP Prime bug in EDITMAT Han 7 1,149 09-27-2013, 10:15 AM
Last Post: Han
  [HP 39Gii] - Bug report Jean-Michel 1 618 08-28-2013, 10:53 AM
Last Post: Tim Wessman
  Is the HP-35S bug free? Matt Agajanian 22 2,499 07-01-2013, 04:03 PM
Last Post: Andrés C. Rodríguez (Argentina)
  Has anyone reported this bug to HP? Allen L. 4 718 01-10-2013, 07:41 PM
Last Post: Manolo Sobrino
  HP-15C Bug with MATRIX 5 Thomas Klemm 17 1,992 02-04-2012, 05:07 PM
Last Post: Paul Dale
  Another HP-15C LE bug? Benoit Maag 58 4,456 10-03-2011, 05:26 PM
Last Post: Steve Simpkin
  Is the HP-50g bug free now? Jim Yohe 9 1,020 02-06-2011, 04:03 PM
Last Post: Jim Yohe

Forum Jump: