SCM

Forum: open-discussion

Monitor Forum | Start New Thread Start New Thread
RE: merge.zoo bug when the indexes have different classes? [ Reply ]
By: Simone Giannerini on 2020-08-27 16:00
[forum:48559]
Dear Achim,


thank you for the prompt resolution of the bug, I will try out the new version.

Kind regards

Simone



RE: merge.zoo bug when the indexes have different classes? [ Reply ]
By: Achim Zeileis on 2020-08-27 01:28
[forum:48067]
I have now addressed this in r1162 in the following way:

(a) merge.zoo() now handles the case of all indexes being integer or numeric by coercing the integer indexes to numeric.

(b) zooreg(x) now allows to create an integer index if start (and end, if any) are integer and the implied deltat is not numerically different from an integer value.

This avoids the reported issue (see below). But after all I stuck with a "numeric" time index for zooreg(x) by default. While this is somewhat inconsistent with the default "integer" time index for zoo(x), it is consistent with the "ts" class. And as zooreg() is the most important vehicle for mapping to "ts" and back, I decided that "ts" compatibility is more important here.

This means that we now get:

R> x1 <- zooreg(2:6)
R> x2 <- zoo(3:7)
R> merge(x1, x2)
x1 x2
1 2 3
2 3 4
3 4 5
4 5 6
5 6 7
Warning message:
In merge.zoo(x1, x2) :
Index vectors are of different classes: numeric integer

where the resulting zoo object has a "numeric" rather than an "integer" index. If you want to preserve the "integer" index you can do now:

R> x1i <- zooreg(2:6, start = 1L)
R> merge(x1i, x2)
x1i x2
1 2 3
2 3 4
3 4 5
4 5 6
5 6 7

If you want to try this out, you can install the devel version of "zoo" from R-Forge:

install.packages("zoo", repos="http://R-Forge.R-project.org")

RE: merge.zoo bug when the indexes have different classes? [ Reply ]
By: Achim Zeileis on 2020-08-24 10:59
[forum:48065]
Good point, Simone, thanks for raising this issue. I guess it would be more consistent to let zooreg() generate an "integer" index by default rather than a "numeric" index.

Then one would avoid the ambiguity between numeric/integer altogether.

Gabor, what do you think?

merge.zoo bug when the indexes have different classes? [ Reply ]
By: Simone Giannerini on 2020-08-24 08:57
[forum:48064]

When the indexes have different classes merge.zoo uses its own index starting from 1970-01-02.

Minimal reproducible example:


R version 4.0.2 (2020-06-22) -- "Taking Off Again"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

[...]

> library(zoo)

Attaching package: ‘zoo’

The following objects are masked from ‘package:base’:

as.Date, as.Date.numeric

> x1 <- zooreg(2:6)
> x2 <- zoo(3:7)
> x3 <- zoo(4:8)
## expected
> merge(x2,x3,all=FALSE)
x2 x3
1 3 4
2 4 5
3 5 6
4 6 7
5 7 8
## bug?
> merge(x1,x2,all=FALSE)
x1 x2
1970-01-02 2 3
1970-01-03 3 4
1970-01-04 4 5
1970-01-05 5 6
1970-01-06 6 7
Warning message:
In merge.zoo(x1, x2, all = FALSE) :
Index vectors are of different classes: numeric integer

> sessionInfo()
R version 4.0.2 (2020-06-22)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18363)

Matrix products: default

locale:
[1] LC_COLLATE=Italian_Italy.1252 LC_CTYPE=Italian_Italy.1252 LC_MONETARY=Italian_Italy.1252
[4] LC_NUMERIC=C LC_TIME=Italian_Italy.1252

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] zoo_1.8-9

loaded via a namespace (and not attached):
[1] compiler_4.0.2 grid_4.0.2 lattice_0.20-41


Kind regards

Simone Giannerini

Thanks to:
Vienna University of Economics and Business Powered By FusionForge