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.
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.