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.
