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 at 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.
>
>