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

[Ei-ji Nakama]

hi,

my environment...
> sessionInfo()
R version 3.3.2 (2016-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Debian GNU/Linux 8 (jessie)

locale:
 [1] LC_CTYPE=ja_JP.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=ja_JP.UTF-8        LC_COLLATE=ja_JP.UTF-8
 [5] LC_MONETARY=ja_JP.UTF-8    LC_MESSAGES=ja_JP.UTF-8
 [7] LC_PAPER=ja_JP.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=ja_JP.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

It's not a very good example...

f0<-function(x,y)exp(complex(real=x,imag=y))
f1<-function(x,y)complex(real=exp(1)^x*cos(y),imag=exp(1)^x*sin(y))
f2<-function(x,y)complex(real=exp(1)^x*cospi(y/pi),imag=exp(1)^x*sinpi(y/pi))

f0(700,1.23)
f1(700,1.23)
f2(700,1.23)

f0(700,1.23e23)
f1(700,1.23e23)
f2(700,1.23e23)

Garbage number is required.

Thank you!

2016-12-01 18:31 GMT+09:00 Prof Brian Ripley <ripley at stats.ox.ac.uk>:
> 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



-- 
Best Regards,
--
Eiji NAKAMA <nakama (a) ki.rim.or.jp>
"\u4e2d\u9593\u6804\u6cbb"  <nakama (a) ki.rim.or.jp>