filter result has very small differences between fastR and GNU-R ?

[comicfans]

I've found that following code gives (very little) different value in fastR and GNU-R

x <- 1:6
lambda <- 0.33
init <- 0
result <- filter(lambda*x, filter = 1-lambda, method='recursive', init = init)

save GNU-R result and load into fast-R, execute same calculation fastRResult - gnuRResult

[1]  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00  0.000000e+00
[6] -8.881784e-16

is this very little differences an implementation defined behavior ,or a bug ?

[steve-s]

Hi comicfans,

it seems that this is caused by the conversion of decimal real numbers (e.g. 0.33) to their binary representation. There doesn't always have to be a binary representation for the given decimal number and the parser gives you the closest. We use the parsing from JDK, GNU-R uses some different algorithm, so this could be the explanation for the tiny difference. On my machine I get:

> options(digits=22)
> lambda <- 0.33
> lambda
[1] 0.3300000000000000155431

in FastR and

> options(digits=22)
> lambda <- 0.33
> lambda
[1] 0.3300000000000000277

in GNU-R. FastR result seems to be actually closer to 0.33, but note that another thing that comes to play is the algorithm for printing the numbers. I wouldn't be surprised if GNU-R (and FastR) gave slightly different results on different platforms. Please, re-open the issue if you'd like more clarification.