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 <rip...@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 <maech...@stat.math.ethz.ch>
>>>>>>> on Thu, 1 Dec 2016 09:36:10 +0100 writes:
>>
>>
>>>>>>> Ei-ji Nakama <nak...@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, rip...@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>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
