Hello Geof,
Thank your for the kind words and encouraging feedback.
Regarding the famous bug, I spent a lot of time last year on that historical point.
The « errata sheet » and the letter from Ron Stevenson are pure marketing communication. The so called idiosyncrasy is clearly a bug and we know from Dijkstra (1968) that « Program testing can be used to show the presence of bugs, but never to show their absence! »
There are 2 malfunctions in this "exp(ln (2.02))=2" bug:
1- the floating point leak of precision in chaining Cordic for ln(x) and for exp(x),
2- the crash of the exp(x) cordic algorithm called with an unexpected pattern.
ln(2.02) = ln( 2 x 1.01) = ln(2) + ln(1.01)
by definition.
The Cordic implemented by Cochran performs the pseudo division process by successive subtractions (q1q2q3
the number of possible subtractions) (clock wise rotations) and next it will execute the rotations (counter clock wise) on the remainder.
The case of the bug is quite trivial:
q1= 2, q2=1.1, q3=1.01
Theoretically (no precision problem) to the number ln(2.02)= 0.7030975114
the algorithm first tries to subtract ln(2) stored as 0.693147180553 =OK, the result is 0.009950330847 and next, tries to subtract ln(1.1) = KO.
The next try is ln(1.01) stored as 0.00995033085090.
previous remainder = 0.009950330847 - 0.00995033085093
Which does not give zero as expected due to difference of precision: r < 0.00995033085093.
The constants in ROM are stored left aligned with a maximum of precision whereas ln(2.02) = 0.7030975114 has been computed previously hence normalized as C=07030975114999.
(the constants are stored in ROM with 12 digit precision while the intermediate normalized result is just 10 digits).
The rest of the story is sad the algorithm subtracts 9 times ln(1.001), 9 times ln(1.0001) and 5 times ln(1.00001).
The pseudo quotients are 599001 where they should be 000101 and this unexpected pattern causes a register overflowing in part 2 (cordic rotations) because the algorithm was not tailored accordingly.
Look at the correction, embarked in the HP-65, HP-21 & HP-25 (I will check in the 67) : it is just quick fix : the precision of the remainder (input of the second part) is reduced to avoid overflow.
Now, your question:
Is it possible with another couple of numbers?
The overflow can occur only with combinations of big pseudo quotients: number ln(2) ln(1.1) and ln(1.01) possibly multiplied by an integer value ; the rest of the pseudo quotients are too small to cause the overflow (AFAIK).
On my buggy HP35 exp(ln(2) * ln(1.1)) is Ok, only exp(ln(2)*ln(1.01)) is faulty.
It depends on the pseudo quotient decomposition pattern.
Best regards,
Jacques.
.