[R-SIG-Finance] timeseries - xst vs. dataframe?

[icosa atropa]

It looks like help('$') and help('is.atomic') raise some interesting
ts and zoo implementation questions. I understand that zoo is modeled
on ts; I didn't really appreciate until now that ts was atomic. Is an
atomic ts and zoo "correct"? Would a recursive zoo break things? Items
of note:

* Is zoo conceptually atomic if it contains a non-integer index vector
and an integer data vector?

*zoo and ts behave more recursively than atomically under certain conditions:
One example is dynlm. It accepts a number of recursive objects for
"data=", including environments and dataframes. Here zoo and ts as
atomic seem to be temporarily granted recursive, environment-like
status so that the model can be specified using the traditional
environment-element syntax:

# one of these is not like the others
test.matrix = cbind(a=1:5, b=2*1:5)
test.ts = ts(cbind(a=1:5, b=2*1:5))
test.zoo = zoo(data.frame(a=1:5, b=2*1:5), order.by=letters[1:5])
test.df = data.frame(a=1:5, b=2*1:5, group=c('A', 'A', 'A', 'B', 'B'),
  order.by=letters[1:5])

dynlm(a ~ b, data=test.matrix)
dynlm(a ~ b, data=test.ts)
dynlm(a ~ b, data=test.zoo)
dynlm(a ~ b, data=test.df)
# the first one doesn't work, but all the others are identical. same for lm()

*One quirk, in my experience, of zoo being atomic is that different
modes of data for the same observation time must be kept in different
objects due to type coercion. I.e.

# with a dataframe, everything can pack together in one object
subset(test.df, group=='A')
# with zoo, separate objects with the same index are necessary
groups.zoo = zoo(group=c('A', 'A', 'A', 'B', 'B'), order.by=letters[1:5])
subset(test.zoo, groups.zoo=='A')
# this doesn't work, since packing together coerces everything to character
oops.zoo = zoo(data.frame(a=1:5, b=2*1:5, group=c('A', 'A', 'A', 'B', 'B')),
order.by=letters[1:5])

* help('ts') and help('vector') reference Becker et al. (1988), while
help('data.frame') and help('lm') reference Chambers (1992). Is ts
being atomic perhaps an accident of timing and history? Re-reading the
docs for lm, data.frame, and is.atomic gives me a sense that custom
classes tend to model recursive rather than atomic:

help('is.atomic'):
  'is.atomic' is true for the atomic vector types ('"logical"',
  '"integer"', '"numeric"', '"complex"', '"character"' and '"raw"')
  and 'NULL'.

  Most types of language objects are regarded as recursive: those
  which are not are the atomic vector types, 'NULL' and symbols (as
  given by 'as.name').

best,
christian

On Feb 13, 2008 7:48 AM, Jeff Ryan <jeff.a.ryan at gmail.com> wrote:
> Hi everyone,
>
> I agree that the '$' operator seems like a nice addition. The only
> problem that I see is:
>
> from help('$')
> ...
> The default methods work somewhat differently for atomic vectors,
> matrices/arrays and for recursive (list-like, see 'is.recursive')
> objects. '$' returns 'NULL' (with a warning) except for recursive
> objects, and is only discussed in the section below on recursive
> objects. Its use on non-recursive objects was deprecated in R
> 2.5.0.
> ...
>
> Since zoo (and thus xts) is really a matrix/array with attributes - it
> seems like it has the chance of breaking something - though where I
> can't reasonably imagine.
>
> The flip side to the argument against is that returning a NULL object
> seems to be of little value to anything.
>
> Is anyone aware of the reason for it being deprecated for non-recursive objects?
>
> Jeff
>
>
> On Feb 13, 2008 8:43 AM, Achim Zeileis <Achim.Zeileis at wu-wien.ac.at> wrote:
> > On Wed, 13 Feb 2008, Gabor Grothendieck wrote:
> >
> > > zoo is modelled on the "ts" class, not on the "data.frame" class.
> > > In R, the way it works is that $ is used on list-based objects
> > > and not on array-based objects.
> >
> > True, and this is the explanation why we don't have it at the moment. But
> > the $ operator might be a convenient addition. And we currently have a few
> > examples where we are consistent with "ts" but provide further features
> > for convenience. At the moment, I don't think something dangerous would
> > happen if we add it - or do I overlook something?
> >
> > Given that you have already written the code, I would vote for including
> > it in the package.
> > Z
> >
> >
> > > Of course, your are free to define
> > > and redefine operators as you please and since zoo is an S3 class
> > > its possible to add your own S3 methods. $ indexing is less
> > > than a dozen lines of code to add to your program:
> > >
> > > "$.zoo" <- function(object, x) object[, x]
> > >
> > > "$<-.zoo" <- function(object, x, value) {
> > > stopifnot(length(dim(object)) == 2)
> > > if (x %in% colnames(object)) object[,x] <- value
> > > else {
> > > object <- cbind(object, value)
> > > colnames(object)[ncol(object)] <- x
> > > }
> > > object
> > > }
> > >
> > > # test
> > > library(zoo)
> > > z <- zoo(cbind(a = 1:3, b = 4:6))
> > > z$c <- z$b + 1
> > > z$a <- z$b - 1
> > > z
> > >
> > > > dataframes. Is "list" syntax planned for inclusion in xst? At
> > > > present, column numbering (test.zoo[,1]) seems the best alternative.
> > > >
> > > > Since as.data.frame(test.zoo)$a appears to recover the core data, it
> > > > sounds sensible for "test.zoo$a" to extract an object containing the
> > > > index and the named column. Does this break anything?
> > > > e.g. :
> > > >
> > > > test.df = data.frame(a=1:5, b=2*(1:5))
> > > > test.df$a
> > > > #[1] 1 2 3 4 5
> > > >
> > > > index = Sys.time() + 60*1:5
> > > > test.zoo = zoo(test.df, order.by=index)
> > > > test.zoo$a
> > > > #NULL
> > > >
> > > > test.zoo[1:2,1]
> > > > # 2008-02-13 05:54:40 2008-02-13 05:55:40
> > > > # 1 2
> > > >
> > > > coredata(test.zoo)$a
> > > > #NULL
> > > >
> > > > as.data.frame(test.zoo)$a
> > > > # [1] 1 2 3 4 5
> > > >
> > > > thanks and best,
> > > > christian
> > > >
> > > > > At this point 'xts' objects behave much like any standard data.frame, matrix or, most closely, zoo object. They have some unique user 'xts' methods but all standard 'zoo' methods will work (it just extends 'zoo')
> > > >
> > >
> > > _______________________________________________
> > > R-SIG-Finance at stat.math.ethz.ch mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> > > -- Subscriber-posting only.
> > > -- If you want to post, subscribe first.
> > >
> > >
> >
> > _______________________________________________
> > R-SIG-Finance at stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-sig-finance
> > -- Subscriber-posting only.
> > -- If you want to post, subscribe first.
> >
>
>
>
> --
> There's a way to do it better - find it.
> Thomas A. Edison
>
--
Far better an approximate answer to the right question, which is often
vague, than the exact answer to the wrong question, which can always
be made precise -- j.w. tukey