Re: [Maxima-discuss] bfloat accuracy, %pi

[Georg S. <der...@gm...>]

--------------------------------------------------
Richard Fateman <fa...@be...> wrote:
(05/06/2018 00:27)

> ... There is a big than expected error near
> special points like n*%pi/2.
> I'll try to figure it out, assuming the code (from 1974!)
> is familiar to me.
> 
> RJF
> 
> ------------------------------------------------------------------------------
I suspect hundreds of extra-digits of 2/%pi may be needed in order to 
reduce a huge argument of a trig-function accurately to the range 
[-%pi/2,%pi/2), in which the trig-functions are usually evaluated 
numerically, particularly if the huge argument is close to a multiple 
of %pi/2. It is of less importance whether the argument reduction is 
to the range [-%pi/2,%pi/2) or to [-%pi/4,%pi/4).
An algorithm for accurate range reduction has been published by K.C. 
Ng in 1992, which aims at 64 bit floats; a text only version can be 
found on the web:
http://www.validlab.com/arg.txt
The reasoning that only addresses IEEE 64bit binary floats starts at 
section 4.0, but I hope it can be extended to cover Maxima's bfloats 
as well.

A hall of shame in which the catastrophic failure of modern processor 
trig-instructions for arguments near %pi/2 (this is not huge!!) is 
demonstrated can be viewed here:
http://notabs.org/fpuaccuracy/
http://notabs.org/fpuaccuracy/scatterplots/intel/plots.htm
http://notabs.org/fpuaccuracy/scatterplots/amd/plots.htm    

I do not know whether the relevant GNU mpfr routines 
https://www.mpfr.org/
may be implemented in Maxima.

All the best
Schorsch