I went on a rabbit hole after finding this article about the accuracy of an Intel function called fsin which was less accurate than advertised when calculating the sine. I didn't realise how complicated this area was.
So I watched this video which goes into an overview of trigonometry in general and how it is calculated.
But it made me wonder - what were HP's implementation of transcendental functions over time. Has the algorithm changed much since the first pocket calculator? If anyone can point me to a resource, I am curious! I looked up the Intel Decimal Floating Point Library (used in Free42/Plus42/DM42) and found this interesting snippet below:
The overall domain of the Arcsinh function has been divided up into
six regions or paths as follows:
(1) (2) (3) (4) (5) (6)
|--------|------------|-----------|-----------|-------|----------|
0 small polynomial reduction asymptotic large huge
(Note: Although the domain of Arcsinh extends from -infinite to
+infinite, the problem can be considered one of only positive arguments
through the application of the identity asinh(-x) = - asinh(x). )
Within each region a unique approximation to the Arcsinh function is
used. Each is chosen for its error characteristics, efficiency and the
range over which it can be applied.
Trigonometric/transcendental function accuracy
-
- Posts: 795
- Joined: Wed May 03, 2017 7:46 pm
- Location: Malone, NY USA
Re: Trigonometric/transcendental function accuracy
HP used the CORDIC algorithm in the HP-35/45 and probably others as well
https://www.jacques-laporte.org/TheSecr ... rithms.htm
https://www.jacques-laporte.org/TheSecr ... rithms.htm
Tom L
Some people call me inept but I'm as ept as anybody!
DM10L SN: 059/100
DM41X SN: 00023 (Beta)
DM41X SN: 00506 (Shipping)
DM42 SN: 00025 (Beta)
DM42 SN: 00221 (Shipping)
WP43 SN: 00025 (Prototype)
Some people call me inept but I'm as ept as anybody!
DM10L SN: 059/100
DM41X SN: 00023 (Beta)
DM41X SN: 00506 (Shipping)
DM42 SN: 00025 (Beta)
DM42 SN: 00221 (Shipping)
WP43 SN: 00025 (Prototype)
Re: Trigonometric/transcendental function accuracy
Older HPs (the 41, and its emulator DM-41X) also show the problem for SIN(x) for x close to PI;
eg. PI SIN (in RAD mode of course..) returns -4.1E-10 on a 41.
I'm not sure which model was first, but certainly the 42S and its faithful simulator Free42 (and thus, the DM42) get it right, the latter even all 34 digits
PI = 3.141592653589793238462643383279503
SIN(PI) = -1.158028306006248941790250554076922E-34
PI + SIN(PI) = 3.1415926535897932384626433832795028841971693993751058209749445923078
Cheers, Werner
eg. PI SIN (in RAD mode of course..) returns -4.1E-10 on a 41.
I'm not sure which model was first, but certainly the 42S and its faithful simulator Free42 (and thus, the DM42) get it right, the latter even all 34 digits
PI = 3.141592653589793238462643383279503
SIN(PI) = -1.158028306006248941790250554076922E-34
PI + SIN(PI) = 3.1415926535897932384626433832795028841971693993751058209749445923078
Cheers, Werner
41CV†,42S,48GX,49G,DM42,DM41X,17BII,15CE, DM15L
-
- Posts: 47
- Joined: Sun Mar 11, 2018 5:37 pm
- Location: France
Re: Trigonometric/transcendental function accuracy
The HP-71B of course, the first with a Saturn CPU:
> P=3.14159265358 (mind the final 8)
> SIN(P)
9.79323846264E-12
No magic here, this comes from the internal double-precision PI value.
J-F
Re: Trigonometric/transcendental function accuracy
That's a fascinating article (needed to use the wayback machine to see the pictures though). I don't understand much of it, but it does blow my mind how tricky it must have been to calculate these values on the earliest technology.toml_12953 wrote: ↑Sat Mar 25, 2023 8:51 pmHP used the CORDIC algorithm in the HP-35/45 and probably others as well
https://www.jacques-laporte.org/TheSecr ... rithms.htm
SN:09075
Re: Trigonometric/transcendental function accuracy
Ah, yes I came across this related discussion about the HP33s and HP35s:
https://www.hpmuseum.org/cgi-sys/cgiwra ... ead=123814
And then on a related note about rounding, though this time a Casio rounding to a fraction of PI:
https://www.youtube.com/watch?v=7LKy3lrkTRA
SN:09075
Re: Trigonometric/transcendental function accuracy
Laporte's site has been reconstructed on hpcalc.orgdm319 wrote: ↑Mon Mar 27, 2023 10:14 amThat's a fascinating article (needed to use the wayback machine to see the pictures though). I don't understand much of it, but it does blow my mind how tricky it must have been to calculate these values on the earliest technology.toml_12953 wrote: ↑Sat Mar 25, 2023 8:51 pmHP used the CORDIC algorithm in the HP-35/45 and probably others as well
https://www.jacques-laporte.org/TheSecr ... rithms.htm
https://archived.hpcalc.org/laporte/The ... rithms.htm
Greetings,
Massimo
ajcaton
-+×÷ left is right and right is wrong Casted in gold
Massimo
ajcaton
-+×÷ left is right and right is wrong Casted in gold
Re: Trigonometric/transcendental function accuracy
Very interesting thread...
Back in the 80'es, I was implementing assembly code for a 8088 processor, to do floating point square root calculations.
Which is also why I remember \(\sqrt{13}\) with 12 10 (just checked) digits by heart still
But I which, I had come up with the notorious Quake Inverse Square Root algotithm, it is really ingenious.
Back in the 80'es, I was implementing assembly code for a 8088 processor, to do floating point square root calculations.
Which is also why I remember \(\sqrt{13}\) with 12 10 (just checked) digits by heart still
But I which, I had come up with the notorious Quake Inverse Square Root algotithm, it is really ingenious.
/Rudi
DM-42 (s/n 06999), HP-42S, HP-35s, HP-11c, HP-32SII (ex HP-41CV, ex HP-75C, ex HP-48G + a lot, really lot of a accessories)
Denmark
DM-42 (s/n 06999), HP-42S, HP-35s, HP-11c, HP-32SII (ex HP-41CV, ex HP-75C, ex HP-48G + a lot, really lot of a accessories)
Denmark
Re: Trigonometric/transcendental function accuracy
Ahh, the good ol' days.... I was binary coding the 8087 in BASIC (bloads I think) and used a 8087 C pre-processor to generate the necessary .asm files based on the masm pre-processed code (loads of db statements and executing thru that code - yeah, try that today!!). I think those days are gone.rudi wrote: ↑Mon Mar 27, 2023 11:56 amVery interesting thread...
Back in the 80'es, I was implementing assembly code for a 8088 processor, to do floating point square root calculations.
Which is also why I remember \(\sqrt{13}\) with 12 10 (just checked) digits by heart still
But I which, I had come up with the notorious Quake Inverse Square Root algotithm, it is really ingenious.
Re: Trigonometric/transcendental function accuracy
Can you tell me why you need to know this? Or else I will be forced to google notorious quake algorithm
PS have you come across Ken Sheriff's blog? He acid-removes 8086 and similar processors to look at how they worked. See here:
http://www.righto.com/2020/08/reverse-e ... intel.html
which looks at the adder on the 8086. He also has a nice page on the 8086/88:
http://www.righto.com/2020/08/reverse-e ... intel.html
SN:09075