zoo: bug with unique for yearmon

[Johann Hibschman-3]

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.

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

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

______________________________________________
[hidden email] 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.

[Achim Zeileis]

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
>
> ______________________________________________
> [hidden email] 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.
>
>

______________________________________________
[hidden email] 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.

[Achim Zeileis]

On Mon, 9 Nov 2009, Achim Zeileis wrote:

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

Just as a follow-up to the list: The original poster provided a small
reproducible example off-list, the package authors could identify and fix
the problem (in the - method), an improved version is already on R-Forge
and will be committed in the next days to CRAN. Sometimes life with
open-source software can be so easy ;-)
Z

>> 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
>>
>> ______________________________________________
>> [hidden email] 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.
>>
>>
>

______________________________________________
[hidden email] 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.