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)

## Advertising

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