Inconsistent names handling with arithmetic operators on xts objects

[tonytonov]

Not a bug per se, but an inconsistency in names handling which caught me by surprise. Here's all right:

data(sample_matrix)
sample.xts <- as.xts(sample_matrix)
names(sample.xts) <- c("-1", "_2", "3!", "#4")
names(sample.xts + sample.xts)
#[1] "-1" "_2" "3!" "#4"

If there's an mismatch in dates, the coredata is fine, but the names get reprocessed:

names(sample.xts + sample.xts[-1, ])
#[1] "X.1" "X_2" "X3." "X.4"

I suspect a new xts object is being created, and some along that way conversion wrecks names.

[joshuaulrich]

This is because merge.xts is called if the two indexes are not identical, and merge.xts does not currently support check.names = FALSE. Current xts behavior is also inconsistent with zoo in this case.

x <- .xts(1:3,1:3,dimnames=list(NULL, c("-1")))
x + x[-1,]
#                     X.1
# 1969-12-31 18:00:02   4
# 1969-12-31 18:00:03   6
z <- as.zoo(x)
z + z[-1,]
#                     -1
# 1969-12-31 18:00:02  4
# 1969-12-31 18:00:03  6

In order to fix this, support for check.names = FALSE must be added to merge.xts. Then it's as simple as setting check.names = FALSE in the calls to merge.xts inside of Ops.xts.

[tonytonov]

I think I can fix that if you would like me to.

[joshuaulrich]

You're more than welcome to try, but I have to warn you: I'm going to be extremely critical of any patch(s) that attempt to change merge.xts (either in the R code or the C code) because that function is crucial to every aspect of xts.

I don't say that to discourage you from attempting, but so that you don't get discouraged when I push back. So, to reiterate, please do try, but be ready for lots of questions and critiques.

[tonytonov]

Thanks for the heads up, fair point. I'll see what I can do. If this is more difficult than I think, well, at least I opened an issue :)

[fcasarramona]

I just have found this same inconsistency in another form:

library(xts)
A <- xts()
B <- xts(1, Sys.Date())
names(B) <- c("A;B-C")
merge(B,A)
           A.B.C
2015-11-17     1

It's also a somewhat weird the opposite merge get a different index in the result:

merge(A,B)
                    A.B.C
2015-11-17 01:00:00     1    

[joshuaulrich]

@fcasarramona That's not really another form. It's what I said in my initial comment: merge.xts does not current support check.names=FALSE.

The different index value in your second example is expected. A and B have different tzone attributes, localtime and UTC, respectively. The result of merge.xts can only have one tzone attribute, so merge.xts chooses the value from the first object passed to it.

[joshuaulrich]

Related to #293