-
-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ops inexplicably renames column #351
Comments
Thanks for the report! I wouldn't say this is inexplicable. The column names are changed because a1 <- zoo(matrix(c(1,2,3), dimnames = list(NULL, "1.3")), order.by = as.yearmon(c(2020, 2021, 2022)))
a2 <- zoo(matrix(c(4,5,6), dimnames = list(NULL, "1.3")), order.by = as.yearmon(c(2021, 2022, 2023)))
a1*a2
## 1.3
## Jan 2021 8
## Jan 2022 15 I'll have to think about it and do reverse dependency checks though because changing it could very well break existing code. PS: Please make sure you're using the latest development version of xts before submitting an issue. It's possible the issue has already been fixed. That isn't true in this case, but could be in the future. I don't want you to spend time hunting for something that's already been fixed. |
You're right on two counts - when you mention about For my end, I'm going to add an extra layer using This actually did come about in my code when I had an S4 class that had |
It would be great if you could list the inconsistencies you find. I can't guarantee anything will change, but at least we'll know where the inconsistencies are and can document them in the package for other users. |
I can start assembling that list - where would you like it to go? Maybe a new vignette? Last thing I'll add is part of the issue is inconsistency within Perhaps at least this behavior could be made internally consistent? |
Add it as a comment to this issue, to start. We can decide what to do with it from there, once we know what you find.
Agreed. That's what I meant by saying, "it's inconsistent with zoo so it should probably be changed in xts." But I have to see how much it would break existing code before determining how/if to make the change. |
Got it, will do; will comment here with what I find. |
I am closing because this is a duplicate of #114 (which is now fixed). So your examples now provide the output you expected. |
Description
When multiplying two xts objects together, whose column names were both "0", and the indices were not equal, the result had a different column name, "X0"
Expected behavior
I would expect the column name to stay "0", even though the indexes are different. This would make it consistent with non-numeric-able (ie strings that don't represent numbers) column names.
Minimal, reproducible example
Best as I can tell, the same is true for any column that can be made into a number (including decimals)
Session Info
The text was updated successfully, but these errors were encountered: