Which HP calculator had "The New Accuracy" first?

[brouhaha]

(06-24-2020 05:35 PM)Valentin Albillo Wrote:  

(06-24-2020 12:51 PM)Nihotte(lma) Wrote:  If i try it on the less recent hp35s and hp12c+ (in RPN mode this time) it gives the same results by using the LN function. Otherwise, on the hp35s with the LOG available function, the result is 0 !!

In a number of HP calcs LOG seems to be more accurate than LN, for instance in the HP-15C that's frequently the case. Perhaps it has to do with BCD and LOG being Log₁₀.

I haven't studied the internal operations of HP's log and exponential functions in depth (even though I've transplanted them into modified 16C microcode), but I suspect the reason could be that argument range reduction for log10 is easy to do in base 10, while argument range reduction for ln would be much more difficult to do accurately in base 10.

The Briggs algorithm as used in the calculators covers a very limited domain, so logarithm arguments above the upper limit of the domain have to be divided by a big enough power n of the base of the logarithm to get them into the domain. After Briggs' algorithm is performed, the value n is added to the result. For base 10 on a BCD calculator, the reduction is simply using the exponent of the argument as n, and clearing the exponent.

Similarly, for 10^x on a BCD calculator, range reduction can be done by setting aside the integer portion of the argument as n, feeding the fractional part into the Briggs exponential routine, then adding n to the exponent of the result.

It would therefore make sense in a calculator to implement natural logs and exponentials as wrappers around common logs and exponentials, rather than vice versa. I can't say with any certainty that this is what's actually going on in the HP calculators.

The same reasoning is why some log and exp implementations on binary systems, in both software and hardware, implement both natural and common log/exp in terms of base 2 log/exp.