[Rd] Different results for cos,sin,tan and cospi,sinpi,tanpi
Prof Brian Ripley
ripley at stats.ox.ac.uk
Thu Dec 1 10:31:00 CET 2016
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
More information about the R-devel
mailing list