On Mon, 9 Nov 2009, Johann Hibschman wrote:
I'm using R 2.10.0, with zoo 1.5-8. The release notes for zoo 1.5-8 claim a bug with unique for yearmon objects has been fixed, but I'm still having problems.
1. Please report such problems (also) to the maintainers and not (only) to the list. 2. Please provide a reproducible example. 3. Both of the points above are pointed out in the posting guide.
Browse[1]> tmp2 [1] "Dec 1996" "Dec 1996" Browse[1]> unique(tmp2) [1] "Dec 1996" "Dec 1996" Browse[1]> unique(unique(tmp2)) [1] "Dec 1996" Browse[1]> as.numeric(tmp2) - (1996 + 11/12) [1] 0.000000e+00 -2.273737e-13
A "proper" yearmon object should take care of this and have a unique representation of Dec 1996. But to understand what went wrong, we need to understand how that malformed Dec 1996 object was created.
Z
Is there a work-around? I had been using an integer months-since-2000 as my month index, so I can go back to doing that, but it's much harder to interpret those numbers. Clearly, I'm being bitten by the floating-point representation, but the only "complex" thing I did was to manually lag a time series by assigning date <- date + 1/12, and I was hoping that the yearmon class would apply some magic to normalize the representation. Regards, Johann Hibschman ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
