The famous exp(ln(2.02)) bug on the original HP35 resulted in HP printing an Errata, part of which said:

" The numbers are 0.7030975114 and 0.995033085 x 10E-2,
or integer multiples of the latter number through nine,
by itself, or when added to the former. "

I was curious as to whether there were any other numbers that
were not in the above "set" that would cause an incorrect answer
on the original HP35.

Doing a numerical search, I did find another number that does
not compute the exponential correctly on the original HP35.

exp(ln(1.12211)) = 1.111

After a little more number crunching, it seems the full list of original HP35 exp(ln(x)) errors are as follows. They all produce values that need to be multiplied by 1.01 to give the correct answer:

exp(ln(1.0201))

exp(ln(1.04060401))

exp(ln(1.12211))

exp(ln(2.02))

exp(ln(2.060602))

Only 5 numbers, from an astronomical number of correct results.

A true needle in a haystack problem.

For those who do not have an original HP35 (circa 1972) calculator, you can try the above numbers on this

HP35 Simulator.

If anyone can find more than the above 5 numbers - I would be very interested.

Story of the new number and the HP35 Errata.

Regards, Geoff Hitchcox (Christchurch, New Zealand).

Was this error barring internal rounding error? I tried exp(ln(3.2001)) and got 3.2000999999.
Does this fall under the "bug" category or does the result need to be "way off"?

Quote:

---

Was this error barring internal rounding error? I tried exp(ln(3.2001)) and got 3.2000999999.

---

Hi Chuck, I should have explained what the bug is. It's when you go
exp(Ln(x)) and get an answer that is not x, but needs to be multiplied by 1.01 to get back to x.

The example you gave is simply a "rounding" issue Chuck, if we take your answer of 3.200099999 and multiply by 1.01 we get 3.232101
which is not your starting number.

Quote:

---

Does this fall under the "bug" category or does the result need to be "way off"?

---

The "bug" is at the 1% level Chuck. It is fascinating to study why this bug happened, because it's every programmer's nightmare, where an issue way down in the 12th place, can suddenly become a very much larger error.

The original HP35 firmware was an absolute wonder (mainly by Dave Cochran)- even the exp(ln(x)) bug is still a salient lesson for modern programmers.

If interested, Jacques Laporte has a great web resource discussing the bug, and how the HP 35 works internally.

Regards, Geoff Hitchcox, (Christchurch, New Zealand).

Thanks for the link to Jacques Laport site. What a wealth of info!!!

Chuck wrote:

Quote:

---

I tried exp(ln(3.2001)) and got 3.2000999999

---

Well, this is one of the many cases where the calculator seems to give a wrong result just because it works perfectly correct. :-)



Your calculator does not evaluate exp(ln(3.2001)), but exp(1.163182059) - simply because every result carries at most ten significant digits, and 1.163182059 is the best possible 10-digit result for ln(3.2001). So, in the second step this 10-digit value is exponentiated, which equals 3.2000 99998 98425... or, rounded to ten digits, exactly the 3.20009 99999 you mentioned.



This also is the reason why even a perfect calculator with limited (n-digit) precision usually will not return the original value after evaluating some transcendent functions followed by their inverses. Try sqrt(5) on a 10-digit calculator: the exact result is right in the middle between 2.236067977 and ...78. Squaring these two values gives 4.999999998 resp. 5.000000002. So there simply is no 10-digit value whose square (even when rounded to 10 digits) equals exactly 5.



Dieter