Skip to content
Prev 3307 / 15274 Next

xts assignment via yearmon or string-based indexing

Hi Brian,

The issue is an incompatibility between what zoo keeps in the index
attribute, and what your development version does.

The new xts stores its index as as.numeric(as.POSIXct(yourtimeindex)).
 This is for a multitude of efficiency reasons.

In some places within zoo the code accesses the index via attr(x,
'index') (or in this case index.zoo(), which does the same).  So you
are effectively trying to use a numeric value of 1858.33 and comparing
it to a very small negative integer:

What is actually stored in xts-dev index:
[1] -3534364800 -3531686400 -3529267200 -3526588800 -3523996800 -3521318400

What you are comparing it to:
[1] 1858.000 1858.083 1858.167 1858.250 1858.333 1858.417

This is a unique issue because xts subclasses zoo, specifically the
public interface to zoo compenents (notably relying on index()
dispatch to 'do the right thing', which in this case [index.xts] is to
automatically convert the raw POSIXct to yearmon --- what you are
_expecting_).

In a few spots, zoo directly accesses the index attribute and causes a
breakage between the two.  It has been quite rare, but you have
stumbled across one such place.

Either use the subsetting directly in xts, or convert to zoo and then
reconvert to xts.  For reference, the replacement method for [<-.xts
has been added to the development branch.
[,1]
Jun 1858 FALSE
[,1]
Jun 1858 TRUE

I will add a window method here, but also discuss with Gabor and Achim
about changing the code in zoo that is causing issues to use the
index() dispatch.  This would allow for others to extend zoo without
getting stuck.

Thanks,
Jeff
On Mon, Dec 1, 2008 at 9:09 PM, Brian Lee Yung Rowe <brian at muxspace.com> wrote: