However, in this case it is the use of %/% that is wrong: the fuzz
ts.eps is supposed to be used. Will alter (in R-devel for now).
On Tue, 20 Apr 2010, Peter Dalgaard wrote:
Patrick Aboyoun wrote:
I've stumbled across an issue with aggregate.ts that either is due to a
misuse of %/% or something deeper relating to numerical precision on
Windows. The test code is
x <- rep(6:10, 1:5)
as.vector(aggregate(as.ts(x), FUN = mean, ndeltat = 5))
On Linux and Mac I get the correct answer
> x <- rep(6:10, 1:5)
> as.vector(aggregate(as.ts(x), FUN = mean, ndeltat = 5)
[1] 7.2 8.8 10.0
> sessionInfo()
R version 2.11.0 RC (2010-04-18 r51771)
i386-apple-darwin9.8.0
locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
and on Windows I get an incorrect answer
> x <- rep(6:10, 1:5)
> as.vector(aggregate(as.ts(x), FUN = mean, ndeltat = 5))
[1] 7.0 8.5 9.5
> sessionInfo()
R version 2.11.0 beta (2010-04-11 r51685)
i386-pc-mingw32
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Walking through the aggregate.ts code I found this difference is due to
what 1 %/% 0.2 produces on the different platforms.
On Mac and Linux I get
> 1 %/% 0.2
[1] 5
and on Windows I get
> 1 %/% 0.2
[1] 4
I don't know if %/% supports floating point operands so I'm not sure how
to report this issue, but here it is anyway.
It's not as straightforward as that. I get 4 on one (32 bit) Linux, and
5 on another (64 bit). Based on samples of size one, I wouldn't want to
conjecture that "bitness" is the root cause, but it is probably not the
OS per se, rather the CPU or compiler version.
It is even more insidious: I see on the SAME system
1%/%0.2
[1] 4
1/0.2==5
[1] TRUE
so it isn't just the usual precision issue.
Of course, exact calculations with floating-point numbers is "unsafe at
any speed", but this is quite peculiar. Presumably, it comes about
because of intermediate storage in an extended precision register.
--
Peter Dalgaard
Center for Statistics, Copenhagen Business School
Phone: (+45)38153501
Email: pd....@cbs.dk Priv: pda...@gmail.com
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
