[R-SIG-Finance] Solicitation of opinions on which Timeseries object(s) to utilize.

[Jeff Ryan]

Hi Joe,

I agree with Dirk's reply. The one thing I'd like to offer is with
respect to xts.

We wrote xts because zoo did essentially everything we needed, yet we
had been wrestling with a way to handle additional attributes cleanly
(we didn't want to 'see' them necessarily), as well as allowing for
specific time-based subsetting via "[".

It is still very early in its development, but it is progressing
rapidly.  The lastest source and builds are available from
http://r-forge.r-project.org/projects/xts and a slightly older version
is on CRAN.

Basically xts is zoo with 2 major(minor) differences.

1. The index must be of a known time-based class. At present this
means either Date of POSIXct, which are native to R - and universal.
There is automatic conversion in as.xts, which handles coercion from
all the classes you mentioned as well as some you haven't.

2. Additional name=value attribute pairs can be passed to the xts
constructors (xts() or as.xts()) which will allow you to attach any
additional attributes you'd like/need. For financial contracts that
could be exhange/data import time/expiration/etc...

xts, because it extends zoo, allows for all 'zoo' methods that usually
just work, to still just work.  An xts object can be used anywhere a
zoo object can. - i.e. inherits(xts.object, "zoo") is TRUE.

The package also offers time based functions (originally/currently)
from the quantmod package - namely the ability to aggregate by common
time ranges - everything from 3 minutes all the way up to yearly, via
'to.period'. The examples page at
http://www.quantmod.com/examples/data gives a rundown of the functions
in some detail.

The new subsetting by the '[' method is sort of cool (IMO):

QQQQ # an object of (you choose: ts, zoo, xts, timeSeries, its, irts,
data.frame, matrix...)

# view all of 2007
as.xts(QQQQ)['2007']

# view all of June of 2007 to the end of the data set:
as.xts(QQQQ)['2007-06::']

# the beginning to 12 June 2007
as.xts(QQQQ)['::2007-06-12']

# the beginning to 12 June 2007 - converted to a _weekly_ series
to.weekly(as.xts(QQQQ)['::2007-06-12'])

The primary motivation behind as.xts was really to make the user's
class choice irrelevant to the function it
it passed to. For example the chartSeries function in quantmod at
present only works well with zoo-like objects.  If you
use timeSeries you were out of luck.  chartSeries(as.xts(QQQQ)) now
just works.  Plus the function 'reclass' allows developers/users the
option of using the time-based subsetting on non-xts objects:

say QQQQ is a timeSeries object, but you'd like to quickly convert to
weekly like the above example, but you want to end
up with your original timeSeries class.

reclass(to.weekly(as.xts(QQQQ)['::2007-06-12']))

yields a timeSeries object converted with xts functionality.  This
works for all convertible objects.

The one correction to Dirk's post is that of micro-seconds/tick-data.
It really doesn't do anything to handle that yet, though
it is planned.  The conversion to POSIXct internally may make it work
on occasion, but it hasn't really been worked out.  SO user beware.

Jeff

As a note: I have been moving the time-based functions from quantmod
to xts, as it seems they have value outside of the more limited
trading scope of the quantmod project.  At the moment it is all in
transition, so things may be not perfectly aligned with respect to
where these funtions reside.

On Jan 20, 2008 10:37 AM, Joe W. Byers <ecjbosu at aol.com> wrote:
> NO
>
>
> Dirk Eddelbuettel wrote:
> > On 20 January 2008 at 09:55, Joe W. Byers wrote:
> > | I am soliciting your opinions on the different time series objects as to
> > | which you prefer, or which you do not prefer.  I have been using
> > | dataframes and date columns to handle my timeseries processes for awhile
> > | now, and recently began experimenting with different timeseries
> > | packages, mainly: zoo, ts, tseries, Rmetric's timeSequences, and
> > | rseries.  There are two reasons for my change here
> > | 1.  Utilize the object oriented components of these packages,
> > | 2.  Standardization for handling the nuances of my time series data.
> >
> > For 'financial data' in the large sense I have been using zoo for years,
> > after having used its. I have also used ts for some ultra-low-frequency
> > macro-economic series, but ts becomes useless once you leave montly or
> > quarterly frequencies and their fixed delta-t. I have basically no experience
> > with the others.
> >
> > zoo is good as it does all the merging, subsetting, plotting, indexing,
> > converting to and from (ie I often 'drop' to data.frame(coredata(zooobject))
> > for analysis) I need.  Working with high-frequency data, I occassionally hit
> > the constraint of 'has to have unique indices' in which case I just pad a
> > micro-second each to the occassional identical timestamp. That's a small
> > price to pay.
> >
> > You did not mention xts, which is the newest member of the clan. It extends
> > zoo and allows 'annotations', ie you can set attributes about the when /
> > where / how / ... of your data. Xts also overcomes the uniqueness constraint
> > for the index (and I am not sure how they do it) and offers richer 'logical'
> > subsetting.  It looks like a winner, and this may just what you need. Have a
> > look at xts.  Usual caveat: Haven't used it myself yet...
> >
> Did not know about it.  I will take a look myself as well.  As always,
> your input is great.
>
> Take care
> Joe
>
> > Hope this helps, Dirk
>
> >
> >
>
> _______________________________________________
> 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