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

[Gabor Grothendieck]

On Jan 20, 2008 11:22 AM, Dirk Eddelbuettel <edd at debian.org> 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.

The problem with allowing non-unique time series is that there are
multiple ways to merge them and you don't know what the user wants so
rather than make a choice that is unexpected or undesired its better to
avoid them.  zoo does support non-unique time series with warnings to the
extent that is needed to allow the user to resolve the non-uniqueness.
Furthermore its not just a matter of adding arguments to merge since nearly
every significant operation in zoo such as +, - etc. involves a merge
underneath.

read.zoo(), aggregate.zoo() and zoo() all allow this non-uniqueness
with a warning
so you can still manipluate the series within the zoo framework
sufficiently to get
your series into a proper form for more serious work.

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

xts is a zoo subclass so it seems unlikely it has different uniqueness
constraints or that it works differently with logical variables.  Perhaps you
are referring to its :: notation which seems different than described above.