Warning issued - Incompatible methods ("Ops.zoo", "Ops.xts")

[minimenchmuncher]

Description

I'm getting a warning for Incompatible methods ("Ops.zoo", "Ops.xts") when attempting to do Ops methods (+-/* etc) when one argument is zoo and the other is xts.

Expected behavior

Seeing as how xts is a subclass of zoo, I would expect Ops methods to be compatible without complaint (barring of course, differences in dimensions, size of coredata, etc). However this is not the case, and I'm worried about just using suppressWarnings without understanding more about why these Ops methods might be incompatible, or the nature of this warning is in more detail.

The following example shows this behavior, the end result is as expected

Minimal, reproducible example

zoo(as.matrix(1:10), order.by = as.yearmon(2020:2029)) + xts(1:10, order.by = as.yearmon(2020:2029))

Jan 2020  2
Jan 2021  4
Jan 2022  6
Jan 2023  8
Jan 2024 10
Jan 2025 12
Jan 2026 14
Jan 2027 16
Jan 2028 18
Jan 2029 20
Warning message:
Incompatible methods ("Ops.zoo", "Ops.xts") for "+" 

## because the zoo object was first (I believe), the return of `+` is of type zoo as well

Session Info

R version 4.0.4 (2021-02-15)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.10

Matrix products: default
BLAS:   /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8    LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

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

other attached packages:
[1] xts_0.12.1 zoo_1.8-8 

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

[joshuaulrich]

This warning is an artifact of there being an Ops.zoo() and Ops.xts() method. From ?Ops:

The classes of both arguments are considered in dispatching any member of this group. For each argument its vector of classes is examined to see if there is a matching specific (preferred) or 'Ops' method. If a method is found for just one argument or the same method is found for both, it is used. If different methods are found, there is a warning about 'incompatible methods': in that case or if no method is found for either argument the internal method is used.

So when one argument is an xts object and the other is zoo, R find both methods and warns you. Then it uses the method from the class of the first argument.

z <- zoo(as.matrix(1:10), order.by = as.yearmon(2020:2029)) 
x <- xts(1:10, order.by = as.yearmon(2020:2029))
z + x
##
## Jan 2020  2
## Jan 2021  4
## Jan 2022  6
## Jan 2023  8
## Jan 2024 10
## Jan 2025 12
## Jan 2026 14
## Jan 2027 16
## Jan 2028 18
## Jan 2029 20
## Warning message:
## Incompatible methods ("Ops.zoo", "Ops.xts") for "+" 
x + z
##          [,1]
## Jan 2020    2
## Jan 2021    4
## Jan 2022    6
## Jan 2023    8
## Jan 2024   10
## Jan 2025   12
## Jan 2026   14
## Jan 2027   16
## Jan 2028   18
## Jan 2029   20
## Warning message:
## Incompatible methods ("Ops.xts", "Ops.zoo") for "+" 

Notice that the results are different depending on whether z or x is the first argument. The result is a zoo object if z is first and it's an xts object if x is first.

This can be fixed so that it doesn't throw a warning, but it's a bit of work. You can ignore the warning as long as you make sure the result is the class you want it to be.

[joshuaulrich]

Closing, since this isn't something that can be fixed by changes in xts' code.