[Rd] Issue with aggregate.ts and/or %\% on Windows

[Peter Dalgaard]

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.mes at cbs.dk  Priv: PDalgd at gmail.com