WP 34S vs. DM42 decimal128 differences?

[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)