Trig algorithms on HP RPN?

[MinkLib]

Can someone tell me if the trig algorithms for HP (and other RPN calculators) are all done in radians (behind the scenes). The reason I ask is I've been trying out the Mike Sebastian Forensic test.
It is of course meant to find the underlying chip used, regardless of brand name. But it gives a (very) rough estimation of accuracy, and the results I get using 0.15707 radians are startlingly better than with 9 degrees.

HP-25 degrees 9.0040 error 0.05%
HP-25 radians 8.9999 error 0.00003%

Any Soviet Elektronika programmable RPN (eg B3-34) degrees 9.0881 error 1%
Any Soviet Elektronika programmable RPN (eg B3-34) radians 9.0000 error 0.0003%

Sinclair Scientific radians 8.9381 error 0.7% (no degree mode)

Thanks.

[Idnarn]

(Yesterday 01:39 PM)MinkLib Wrote:  Can someone tell me if the trig algorithms for HP (and other RPN calculators) are all done in radians (behind the scenes).

While the answer cannot be generalized as it may depend on the particular calculator, if you want an example, see the paper "Algorithms and Accuracy in the HP-35" by David S. Cochran (example, here: https://www.keesvandersanden.nl/calculat..._HP-35.pdf) which describes trigonometry function calculation on the HP-35. I read somewhere (was it an interview with William Kahan?) that the HP 15C code derived from it.

You can also browse Jacques Laporte's excellent reverse engineering of the HP-35 here: https://archived.hpcalc.org/laporte/index.html

https://archived.hpcalc.org/laporte/Trigonometry.htm

[naddy]

See this thread where I asked the same seven weeks ago:
https://www.hpmuseum.org/forum/thread-22486.html

[Thomas Klemm]

(Yesterday 01:39 PM)MinkLib Wrote:  Can someone tell me if the trig algorithms for HP (and other RPN calculators) are all done in radians (behind the scenes).

Although the HP-35 only uses degrees for trigonometric functions, it still seems to use the \(\tan^{-1}\) values ​​in radians:

Code:

0-0716 0730  load constant 7        reg['C'] = 0x00700000000000
0-0717 1030  load constant 8        reg['C'] = 0x00780000000000
0-0720 0530  load constant 5        reg['C'] = 0x00785000000000
0-0721 0330  load constant 3        reg['C'] = 0x00785300000000
0-0722 1130  load constant 9        reg['C'] = 0x00785390000000
0-0723 1030  load constant 8        reg['C'] = 0x00785398000000
0-0724 0130  load constant 1        reg['C'] = 0x00785398100000
0-0725 0630  load constant 6        reg['C'] = 0x00785398160000
0-0726 0330  load constant 3        reg['C'] = 0x00785398163000
0-0727 0530  load constant 5        reg['C'] = 0x00785398163500

And then a bit later:

Code:

0-0617 1030  load constant 8        reg['C'] = 0x00099668666666
0-0620 0630  load constant 6        reg['C'] = 0x00099668666666
0-0621 0530  load constant 5        reg['C'] = 0x00099668656666
0-0622 0230  load constant 2        reg['C'] = 0x00099668652666
0-0623 0430  load constant 4        reg['C'] = 0x00099668652466
0-0624 1130  load constant 9        reg['C'] = 0x00099668652496

This is output from running x11-calc-35 with the -t option:

Code:

  -t,                      trace

Compare this to (using RAD):

1 ATAN

0.78539816340

0.1 ATAN

0.09966865249

From my understanding of CORDIC we might as well use angles in degrees.
Honestly, I don't know why that wasn't used instead.