[Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi

[Prof Brian Ripley]

Please note that you need to report your platforms (as per the posting 
guide), as the C function starts

#ifdef HAVE_COSPI
#elif defined HAVE___COSPI
double cospi(double x) {
     return __cospi(x);
}

And AFAICS the system versions on Solaris and OS X behave the same way 
as R's substitute.



On 01/12/2016 09:12, Martin Maechler wrote:
>>>>>> Martin Maechler <maechler at stat.math.ethz.ch>
>>>>>>     on Thu, 1 Dec 2016 09:36:10 +0100 writes:
>
>>>>>> Ei-ji Nakama <nakama at ki.rim.or.jp>
>>>>>>     on Thu, 1 Dec 2016 14:39:55 +0900 writes:
>
>     >> Hi,
>     >> i try sin, cos, and tan.
>
>     >>> sapply(c(cos,sin,tan),function(x,y)x(y),1.23e45*pi)
>     >> [1] 0.5444181 0.8388140 1.5407532
>
>     >> However, *pi results the following
>
>     >>> sapply(c(cospi,sinpi,tanpi),function(x,y)x(y),1.23e45)
>     >> [1] 1 0 0
>
>     >> Please try whether the following becomes all right.
>
>     > [..............................]
>
>     > Yes, it does  -- the fix will be in all future versions of R.
>
> oops.... not so quickly, Martin!
>
> Of course, the results then coincide,  by sheer implementation.
>
> *BUT* it is not at all clear which of the two results is better;
> e.g., if you replace '1.23' by '1' in the above examples, the
> result of the unchnaged  *pi() functions is 100% accurate,
> whereas
>
>  R> sapply(c(cos,sin,tan), function(Fn) Fn(1e45*pi))
>  [1] -0.8847035 -0.4661541  0.5269043
>
> is "garbage".  After all,  1e45 is an even integer and so, the
> (2pi)-periodic functions should give the same as for 0  which
> *is*  (1, 0, 0).
>
> For such very large arguments, the results of all of sin() ,
> cos() and tan()  are in some sense "random garbage" by
> necessity:
> Such large numbers have zero information about the resolution modulo
> [0, 2pi)  or (-pi, pi]  and hence any (non-trivial) periodic
> function with such a "small" period can only return "random noise".
>
>
>     > Thank you very much Ei-ji Nakama, for this valuable contribution
>     > to make R better!
>
> That is still true!  It raises the issue to all of us and will
> improve the documentation at least!
>
> At the moment, I'm not sure where we should go.
> Of course, I could start experiments using my own 'Rmpfr'
> package where I can (with increasing computational effort!) get
> correct values (for increasingly larger arguments) but at the
> moment, I don't see how this would help.
>
> Martin


-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford