WP 34S vs. DM42 decimal128 differences?

[rkf]

Today I stumbled about a footnote in Walter's WP 34S Owner's manual, where at Page 319 the result of the Calculator Forensics Test is mentioned. To my big surprise, the DP difference between the test result, and 9, is

for WP 34S: -6.2465E-29
for DM42: -6.2466E-29

But why the differerence of 1 ULP?? For the other example (1.0000001^2^27), there isn't any difference between the two models, BTW.

[Dieter]

(03-20-2018 09:15 AM)rkf Wrote:  Today I stumbled about a footnote in Walter's WP 34S Owner's manual, where at Page 319 the result of the Calculator Forensics Test is mentioned. To my big surprise, the DP difference between the test result, and 9, is

for WP 34S: -6.2465E-29
for DM42: -6.2466E-29

But why the differerence of 1 ULP?? For the other example (1.0000001^27), there isn't any difference between the two models, BTW.

Both calculators use 34-digit precision, but this does not mean that they return the same results. The trig functions may be implemented differently, and there is no claim (at least for the 34s) that all 34 digits are correct. The 34s also has different round modes that can be set, which will affect the result as well.

Dieter

[Paul Dale]

I believe the 34S is correct here. Free42 uses the Intel decimal library which rounds some functions incorrectly.

Well, the 34S used to get this correct but there were some changes to the trig code to better handle cases near multiples of \( \frac{\pi}{2} \), it is possible they threw it off.


Pauli

[Nigel (UK)]

This is addressed to Pauli:

I've noticed that sin (pi radians) in double-precision mode on the WP34S is only correct to 17 significant figures. This disturbs me more than I would have expected (given that I normally have the calculator set to give me answers to 4 sf only!).

If I change SINCOSDIGITS in decn.c to 69, all calculated digits are correct. Trig functions are slower (more so in double precision than in single precision).

If I use 69 digits in the function sincosTaylor() when the calculator is in double precision mode, but 39 digits in single precision, I seem to get the best of both worlds - correct answers in both single and double precision, with no slow-down in single-precision mode.

Is this a change worth making (once I've done some more extensive testing, and looked at the code for tan x as well)? Or is there a downside other than speed to using these extra digits?

Nigel (UK)

[Paul Dale]

(03-26-2018 09:51 PM)Nigel (UK) Wrote:  Is this a change worth making (once I've done some more extensive testing, and looked at the code for tan x as well)? Or is there a downside other than speed to using these extra digits?

I'd be concerned about overflowing the stack in other functions that call this. E.g. the gamma code can call this and gamma in turn is called from the statistical routines which are close to the limit already.

Using a smaller number of digits in single precision mode might also fall awry of this function's use elsewhere. If later digits carry an error they could cascade into the first sixteen.

I'll have to have a think about it...


Pauli

[rkf]

(03-26-2018 09:51 PM)Nigel (UK) Wrote:  This is addressed to Pauli:

I've noticed that sin (pi radians) in double-precision mode on the WP34S is only correct to 17 significant figures. ...

Although I'm not Pauli but the original poster, I don't get the point here. Typing in Rad mode pi sin gives on both WP 34S DBLON, and DM42, a result of about -1.158E-34.

For me as a plain user this result seems to have nevertheless 34 significant figures, all of them zeroes (one before the decimal point, and 33 thereafter).

Or do you compare the (exact) result of taking sin of a number, which is exactly pi rounded to 34 significant figures (thus to be expected in the ballpark around +/- 1E-34) with the result the calculator gives, and then -1.158028306006248941790250554076922E-34 itself is only correct to 17 figures? But that would be no problem at all for me.

[Nigel (UK)]

(03-27-2018 06:10 AM)rkf Wrote:  Or do you compare the (exact) result of taking sin of a number, which is exactly pi rounded to 34 significant figures (thus to be expected in the ballpark around +/- 1E-34) with the result the calculator gives, and then -1.158028306006248941790250554076922E-34 itself is only correct to 17 figures? But that would be no problem at all for me.

I'm counting significant figures from the first non-zero digit - i.e., what you say above.

I agree that it isn't likely to be a problem in any real-world application of the calculator. However, given that the WP34S has a double-precision mode it would be nice if the result was also correct to this level of precision, so long as this can be done without breaking the calculator's behaviour elsewhere. If you calculate sin (3.1415926536) on the HP28S (for example) you will get an answer correct to 12 non-zero significant digits, and Pauli has already adjusted the WP34S code to get cos (pi/2) (which is a similar case) correct to 34 sf. Most of the time the trig functions are correct to this level of precision, so trying to bring sin (pi) up to the same standard isn't unreasonable.

I think it would be nice to fix it, if it can be fixed.

Nigel (UK)

[rkf]

(03-27-2018 07:58 AM)Nigel (UK) Wrote:  ... I'm counting significant figures from the first non-zero digit - i.e., what you say above. ...

OK - thanks for the clarification! BTW, this very situation is discussed in detail at p. 184 of the HP-15C Advanced Functions Handbook (although for the HP-15C's 10 shown, and 13 internal digits - thus giving, depending from interpretation, either ten, or three significant digits). Since the WP 34S, and DM42 behave with respect to sin(pi) in complete accordance with the HP manual cited above, I'm fine with the status quo. :-)

[Paul Dale]

(03-27-2018 07:58 AM)Nigel (UK) Wrote:  However, given that the WP34S has a double-precision mode it would be nice if the result was also correct to this level of precision...

We don't make any commitments about accuracy or precision in double precision mode...

i'm still thinking...


Pauli

[Nigel (UK)]

To Pauli, and anyone else interested in this:

I've got full precision working correctly with just one 69-digit decNumber - x, in cvt_2rad_sincos. sincosTaylor itself isn't changed; its arguments are still pointers to SINCOS-digit decNumbers and the calculations in it are carried out to this precision.

I divide radian arguments to cvt_2rad_sincos by \(2\pi\) to 69-digit precision, and then do range reduction as with degrees and grads using fractions of a full circle as the thresholds. This means that any radian arguments that have a very small sine or cosine are mapped onto angles near zero, and so 69-digit precision isn't needed to calculate these functions correctly. I've included the constant 0.125 in consts.h and compile_consts.c for use as the \(45^\circ\) threshold.

I don't know whether the memory requirements will still be a problem. I've attached the modified source files in case you want to try them out yourself - if you don't, or you have a better approach of your own, that's fine as well!

Nigel (UK)

[Paul Dale]

An interesting approach, one I had considered when I added the range reduction to these functions. My concern, then and now, is that e.g. \( \frac{\pi}4 - x \) cannot be represented exactly and that this could change the result in some cases. You are dividing by \( 2\pi \) so the later range reduction will be exact, but this division step and the later inverse would be where the equivalent error occurs.

It is possible that at some level of extended precision, the errors become insignificant. Determining and proving this wouldn't be trivial.

It's quite a difficult problem Still, it is an approach that's worth chasing.


Pauli

[Nigel (UK)]

(03-29-2018 11:46 PM)Paul Dale Wrote:  An interesting approach, one I had considered when I added the range reduction to these functions. My concern, then and now, is that e.g. \( \frac{\pi}4 - x \) cannot be represented exactly and that this could change the result in some cases. You are dividing by \( 2\pi \) so the later range reduction will be exact, but this division step and the later inverse would be where the equivalent error occurs.

It is possible that at some level of extended precision, the errors become insignificant. Determining and proving this wouldn't be trivial.

It's quite a difficult problem Still, it is an approach that's worth chasing.


Pauli

I'm sure that I'm missing some of the subtleties but the situation doesn't seem too bad to me.

• The input to the function (xin) is a 34-digit decnumber.
• The reduction modulo \(2\pi\) is carried out to 69 digit precision and stored to this precision in x. The final digit might be unreliable.
• The range reduction will reduce the precision of x. However, because there aren't any long strings of 9s or 0s in any of \(\{\pi/4,\pi/2,\pi,2\pi\}\), x cannot be closer to a threshold than about \(10^{-34}\), and so 35 digits of precision should remain in the worst case, with the final digit unreliable.
• Multiplying by \(2\pi\) again might make the final digit still less reliable, but should still leave 34 correct digits - or maybe 33 on a really bad day.
• These digits are fed to sincosTaylor and since the range reduction ensures that if the trig function being calculated is small, the argument is small as well, there should be no further problems with precision.
  

Experiment (i.e., comparing the emulator results with newRPL set to 100 digits precision) consistently gives results correct to all 34 digits in both sine and cosine. I've only tried this about ten times and I realise that this proves nothing, but it is encouraging.

Incidentally, calculating \(\sin(\pi)\) with a 34-digit value of \(\pi\), using newRPL with 34 digits of precision, gives an answer also correct to 34 digits. Well done Claudio!

Nigel (UK)

[Claudio L.]

(03-30-2018 12:11 PM)Nigel (UK) Wrote:  Incidentally, calculating \(\sin(\pi)\) with a 34-digit value of \(\pi\), using newRPL with 34 digits of precision, gives an answer also correct to 34 digits. Well done Claudio!

Nigel (UK)

Thanks, but there's not much glory on that achievement. It simply uses \(\pi\) with twice the current precision, so the range reduction produces the angle with full required precision. It's easy to achieve when the whole system has variable precision.
Now if you set the system to maximum precision:

Code:


2000 SETPREC
π0 0 +       @ TO ROUND π0 TO 2000 DIGITS, JUST ADD ZERO
SIN

Now what do you see? Only 22 good digits (thanks to a few extra guard digits beyond 2000), but certainly not 2000 good digits as you would've expected. At the limit of the system precision, newRPL has the same issues of the wp34s. The only solution I found was to use 4000 digits for pi, but what's the point: if the system works with 4000 digits, then I'd rather let the user use them all, just warning them that if you use more than half of that, don't expect all corner cases to be accurate. Due to memory limitations, I chose 2000 digits as the system limit. If you use 1000 digits or less, all functions are guaranteed to give you correctly rounded results in all corner cases with the 1000 digits precision you expect.
On the wp34s it's exactly the same: they used double precision to guarantee single precision on all corner cases. But since it's available, why not let the user access it? after all it's good for 99% of the cases. Now people want perfect results at double precision, so Paul needs quad precision, and then why not let the user use quad?... and here we go again.

[Nigel (UK)]

Thank you for explaining the situation in newRPL, which is an extraordinary achievement.

In the WP34S source code \(2\pi\) is already present as a constant to 450 decimal places (or thereabouts). So why not use it to get double precision answers for trig functions of double precision arguments? All it seems to take is a few code changes and one quad precision variable in one function (although whether the calculator has the RAM needed to cope with this remains an open question).

I understand that in the absence of variable-precision arithmetic, chasing perfection is a way without an end. I'm also sure that Pauli has far more important things to think about. But in this case it seems that a few simple changes might make it work, and if so, why not?

Nigel (UK)

[Paul Dale]

(03-30-2018 04:44 PM)Nigel (UK) Wrote:  \In the WP34S source code \(2\pi\) is already present as a constant to 450 decimal places (or thereabouts). So why not use it to get double precision answers for trig functions of double precision arguments?

The many decimals are required to get accurate answers in single precision. E.g. try \(sin(10^{100})\). To get the same for double precision requires thousands of digits -- I'd guess about 8500 give or take. Making double precision trigonometric functions accurate across their entire range isn't feasible on the hardware, there isn't enough memory.

Still, you made a good argument for improving them where they are more typically used. I'll have to think it through in more detail. I'll also have to work out the worst case memory usage for functions that can call sine or cosine to see if the extra space required will fit. Were a few bytes from not fitting the stack in.


Pauli