The "eln(2.02) = 2" bug fully elucidated

Re reading his summer my paper elucidating the bug in early HP 35 ROMs, I felt both proud and sad.

Proud to have given the solution of the enigma, by pure thought experiment (proofed later on a ROM simulator) ; but sad because I could have done it earlier.

As a matter of fact, I explained in an article in 1981 that the HP 35 was actually computing as , using two constants stored in ROM.

I gave also the digit by digit  algorithm, subtracting from  the 2 constants and simply forming the result .

What happened to the designer and to roughly 25000 early machines (1) was a simple consequence of the old saying “round numbers are always false”.

In fact, the result of the operation is rounded internally by a normalization routine and –chaining the operations - it is impossible to subtract exactly the two constants and forming because of their higher precision (2).

Instead, the algorithm derails and gives;
which unexpected pattern causes a register overflow and gives the false result .

Please see the full story here.

Jacques Laporte
24 September 2006.
revisited August 2007.

(1) In 1972 (probably by the fall of 1972) , when the problem was discovered, HP had sold some 25000 units, but only 5000 machines were returned to have their 3 ROM chips exchanged.

Bug free units were shipped starting January 1973 :
- Serial Number 1302AXXXXX (second week of 1973) and higher are error free,
- before that all units needed modifications.
The recall process started in February 1973: "We have taken immediate steps to correct the problem, and will have replacement read-only-memories available sometime after the first of the year" wrote Ron Stevenson Customer Service Manager, to the "Dear HP-35 Owner" (see photo below).

(2) The numbers  and are stored in the HP 35 ROM with 12 digit precision while the intermediate normalized result is just 10 digits.