Hmm, I fear I have entirely failed to explain my reading of the observation!
I believe we see here that C47 and WP43 both fall well short of expected accuracy, with an error of thousands of billions of ULPs. That's by comparison with Wolfram Alpha and with Free42. (I mention Free42 only because it's very accurate, and would expect there to be some intent to get close to the same accuracy, or better.)
Let's enter this value which is just less than pi:
3.141592653589793238462643383279502
and see what SIN makes of it (in radians)
WP43 and C47: 8.841971693993751E-34
or in full: 8.841971693993751000000000000000000E-34
whereas Wolfram Alpha gives us: 8.84197169399375105820974944592307816... × 10^-34
and Free42, the standard we might aspire to: 8.841971693993751058209749445923077e-34
I think this isn't a new observation - see this post from 2015. However, I do believe it shows an accuracy bug.
The same thing happens with COS of half pi (half the calculator's value for pi)
1.570796326794896619231321691639752
-5.57901415300312450000000000000000E-34
vs
-5.57901415300312447089512527703846e-34
vs the true value
-5.5790141530031244708951252770384609... × 10^-33
Another observation which perhaps shows this looks like something in the way of a mistake in range reduction, is to compare with the sin of 10 pi. In this case, the WP34S(*) and Free42 are in complete agreement and the WP34S(*) has full expected accuracy.
1pi:
3.141592653589793238462643383279503
Take sin in radians mode:
Free42: -1.158028306006248941790250554076922e-34
WP43: -1.158028306006248900000000000000000E-34
10pi:
31.41592653589793238462643383279503
Take sin in radians mode:
Free42: 1.158028306006248941790250554076922e-33
WP43: 1.158028306006248941790250554076922E-33
(*) Edit: oops, I meant WP43 of course
Trigonometric/transcendental function accuracy
Re: Trigonometric/transcendental function accuracy
Last edited by BigEd on Wed Jun 07, 2023 9:48 am, edited 1 time in total.
Re: Trigonometric/transcendental function accuracy
Thanks for reporting. Before bothering with errors of E-50, however, I'd recommend sorting out an error 50 orders of magnitude greater: you've confused the WP43 and WP34S, haven't you?BigEd wrote: ↑Tue Jun 06, 2023 9:24 pmHmm, I fear I have entirely failed to explain my reading of the observation!
I believe we see here that C47 and WP43 both fall well short of expected accuracy, with an error of thousands of billions of ULPs. That's by comparison with Wolfram Alpha and with Free42. (I mention Free42 only because it's very accurate, and would expect there to be some intent to get close to the same accuracy, or better.)
Let's enter this value which is just less than pi:
3.141592653589793238462643383279502
and see what SIN makes of it (in radians)
WP43 and C47: 8.841971693993751E-34
or in full: 8.841971693993751000000000000000000E-34
whereas Wolfram Alpha gives us: 8.84197169399375105820974944592307816... × 10^-34
and Free42, the standard we might aspire to: 8.841971693993751058209749445923077e-34
I think this isn't a new observation - see this post from 2015. However, I do believe it shows an accuracy bug.
The same thing happens with COS of half pi (half the calculator's value for pi)
1.570796326794896619231321691639752
-5.57901415300312450000000000000000E-34
vs
-5.57901415300312447089512527703846e-34
vs the true value
-5.5790141530031244708951252770384609... × 10^-33
Another observation which perhaps shows this looks like something in the way of a mistake in range reduction, is to compare with the sin of 10 pi. In this case, the WP34S and Free42 are in complete agreement and the WP34S has full expected accuracy.
1pi:
3.141592653589793238462643383279503
Take sin in radians mode:
Free42: -1.158028306006248941790250554076922e-34
WP43: -1.158028306006248900000000000000000E-34
10pi:
31.41592653589793238462643383279503
Take sin in radians mode:
Free42: 1.158028306006248941790250554076922e-33
WP43: 1.158028306006248941790250554076922E-33
While we're at it: please note WA calculates with an infinite number of digits.
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
Re: Trigonometric/transcendental function accuracy
Well, probably not an infinite number of digits, that would take a very long time...
--bob p
DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
Re: Trigonometric/transcendental function accuracy
Let's say with n >> 1000. Are you happy now?
WP43 SN00000, 34S, and 31S for obvious reasons; HP-35, 45, ..., 35S, 15CE, DM16L S/N# 00093, DM42β SN:00041
Re: Trigonometric/transcendental function accuracy
I wouldn't call it an error of E-50 but an error at the 18'th significant digit.Walter wrote: ↑Tue Jun 06, 2023 10:23 pmBigEd wrote: ↑Tue Jun 06, 2023 9:24 pmThanks for reporting. Before bothering with errors of E-50, however, I'd recommend sorting out an error 50 orders of magnitude greater: you've confused the WP43 and WP34S, haven't you?
While we're at it: please note WA calculates with an infinite number of digits.
/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
I think 4-8 significant digits would be precise enough to all problems I have encountered in my 30 active years.
So I would also be happy with 16 digits
/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
But the idea with the WP43, I think, is to offer 34 digits accuracy, or close, where possible.
Re: Trigonometric/transcendental function accuracy
Pauli did more than he admits to - he went ahead and fixed it.
I am summarising a GitLab conversation we had between developers (free for all to go find it):
Martin analysed the internal problem to be due to argument reduction: Let's call the value of pi stored by C47 as PIc:
PIc is 34 digits: 3.141592653589793238462643383279503, which is (PIc-𝝿) larger than 𝝿 and due to range reduction, the problem of sin(PIc) becomes -sin(PIc-𝝿). Range reduction is done with a 51 digit pi, therefore the problem changes in C47 to:
As you can see it IS accurate to 34 digits, with the 34/5th digit rounding up, carrying for 16 digits, rounding the 17th digit from 8 to 9. It is actually NOT inaccurate at 18 digits, it is inaccurate at 34th digit, which rounded up.
So in my book, this is no bug, as C47 does exactly what it is supposed to do with the constants it has and it is correct.
But also in my book, it is wrong because the argument became sin(1.158028306006248900000000000000000×10⁻³⁴) and not sin(1.15802830600624894179025055407692 × 10^-34).
Although Pauli did not mention fixing it in his post above, he undertook to increase the accuracy by increasing the internal digits and of the pi stored value for (1) argument reduction and (2) operations from 51 to 75 digits. The good news is, it is now accurate, do see below. The bad news, it will be slower, do see when we release the next version. Of course it has to, if it has to deal with more digits. And further bad news is that rounding will ALWAYS be there at some point unless you use infinite digits (good luck!). So the same thing will happen next time someone needs to calculate sin(𝝿 * × 10^20); of course you will run out of accuracy with the reduction and when you do, ask yourself: "why?" - at some point you have to say enough is enough.
Now, doing the same example used from above, for an angle in the 2nd quadrant, updated with new values:
I am summarising a GitLab conversation we had between developers (free for all to go find it):
Martin analysed the internal problem to be due to argument reduction: Let's call the value of pi stored by C47 as PIc:
PIc is 34 digits: 3.141592653589793238462643383279503, which is (PIc-𝝿) larger than 𝝿 and due to range reduction, the problem of sin(PIc) becomes -sin(PIc-𝝿). Range reduction is done with a 51 digit pi, therefore the problem changes in C47 to:
Code: Select all
sin(
3.141592653589793238462643383279503 -
3.14159265358979323846264338327950288419716939937511) = sin(1.1580283060062489×10⁻³⁴) =
-1.1580283060062488999999999999999999999999999999999999999999... × 10^-34, compared to C47:
-1.1580283060062489×10⁻³⁴.
So in my book, this is no bug, as C47 does exactly what it is supposed to do with the constants it has and it is correct.
But also in my book, it is wrong because the argument became sin(1.158028306006248900000000000000000×10⁻³⁴) and not sin(1.15802830600624894179025055407692 × 10^-34).
Although Pauli did not mention fixing it in his post above, he undertook to increase the accuracy by increasing the internal digits and of the pi stored value for (1) argument reduction and (2) operations from 51 to 75 digits. The good news is, it is now accurate, do see below. The bad news, it will be slower, do see when we release the next version. Of course it has to, if it has to deal with more digits. And further bad news is that rounding will ALWAYS be there at some point unless you use infinite digits (good luck!). So the same thing will happen next time someone needs to calculate sin(𝝿 * × 10^20); of course you will run out of accuracy with the reduction and when you do, ask yourself: "why?" - at some point you have to say enough is enough.
Now, doing the same example used from above, for an angle in the 2nd quadrant, updated with new values:
And as for the original problem of the sine of an argument value of just 1×10⁻³⁴ larger than above, we move into the third quadrant with a hair width (whose hair (and in m or in feet)) and this then needs the reduction:Let's enter this value which is just less than pi:
3.141592653589793238462643383279502
and see what SIN makes of it (in radians)
WP43 and C47: 8.841971693993751E-34
or in full: 8.841971693993751000000000000000000E-34
C47 NEW: 8.841971693993751058209749445923078E-34
whereas Wolfram Alpha gives us: 8.84197169399375105820974944592307816... × 10^-34
and Free42, the standard we might aspire to: 8.841971693993751058209749445923077e-34
sin(
3.141592653589793238462643383279503000000000000000000000000000000000000000000000000000000000 -
3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825) =
sin(
+1.15802830600624894179025055407692183593713791001371965175 × 10^-34
) =
-1.15802830600624894179025055407692183593713791001371965175... × 10^-34, from Wolfram Alpha (or Taylor) comparing to C47 to sin(PIc) =
-1.158028306006248941790250554076922E-34
Last edited by Jaymos on Wed Jun 07, 2023 8:00 pm, edited 1 time in total.
Jaco Mostert
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.
Elec Eng, South Africa
https://47calc.com C47 (s/n 03818 & 06199), WP43 (0015). In box: HP42S, HP32Sii, WP34S&C, HP28C, HP35s, EL-506P, EL-W506, PB700; ex: FX702P, 11C, HP67 & HP85; iOS: 42s Byron, Free42+, WP31S/34S, HCalc.