Re: R-beta: time series structures

Andrea Rossetti (
Wed, 10 Dec 1997 23:11:38 +0100

Date: Wed, 10 Dec 1997 23:11:38 +0100
From: Andrea Rossetti <>
To: Paul Gilbert <>,
Subject: Re: R-beta: time series structures

I tryed to put the Paul Gilbert's tframe.s library in the "library" directory of
the latest ( with modified menu) Windows 95 version of R and I uncovered
that it can be recalled with "library(tframe.s)" command.

Not any (runtime) error compare!!! Now ramain to try the functionality of the
package, I say it to all Windows 95 R users.

Andrea Rossetti

Paul Gilbert wrote:

> >represented.  They are now R "objects" similar to S-PLUS "rts"
> >time series, but they are 3-dimensional arrays (iterations x variables
> >x chains).  This seems like the best choice of data structure to me
> >but if someone else has thought more deeply about this tell me now
> >before I rewrite all my code!
> Martyn
> A couple of years ago I wrote a kernel of routines for handling the time
> dimension of objects. In part this was prompted by StatSci's
> introduction of rts, etc., which caused a number of problems in my code,
> at least if I wanted to take advantage of these new time representation.
> The idea of this kernel is that it allows me to use different
> representrations without having to change much. I just have to add a few
> methods to deal with the new time representation.
> If time is an important aspect of your objects you might want to look at
> this code. It is somewhat experimental, but it has worked very well for
> me with my fairly large library of routines for time series analysis.
> Attached below is some more explaination. Let me know is you want the
> code.
> Paul Gilbert
> ________________
> <H2>Description</H2>
> <UL>
> Generic methods for handling time.
> </UL>
> <H2>Details</H2>
> <UL>
> <I>tframe</I> objects implement a scheme for using classes and methods
> to handle different time representations in S. This provides a method
> by which code can be developed without too much dependence on the
> representation of time. For example, many time series programs only use
> the fact that data is arranged sequentially. On the other hand, putting
> the time axis label on a plot will require a method which is specific
> to the time representation.<P>
> While the primary purpose of this class and its methods is to allow
> code to me more robust with respect to other (and future)
> improved/different representations of time, the methods also provide a
> simple way to fix some inconsistency which may occur with the current
> mix of possible time representations.<P>
> The classes and methods associated with the implementation of rts, cts
> and its in Splus accomplish some of these objectives. The attempt here
> is further separate the time representation from the data to allow a
> statement like
> <BR>
> tframe(x) <- tframe(y)
> <BR>
> to make the time frame of x the same as that of y, without the need to
> worry about what time representation is used in y (eg. tsp, rts, cts,
> its, ...). In this assignment x and y need not be too similar (eg - one
> might be a univariate series while the other is a matrix or an array or
> list of spatial or panel time series data), as long as they are similar
> in the time dimension.<P>
> This is accomplished by assigning an attribute of the data called
> "tframe" and giving that attribute a class so that methods can be
> applied to it. Doing this in a generic way allows for the possibility
> of future classes of time representation. This is different from the
> way that rts, cts and its are implemented, in the sense that it is the
> tframe attribute of the data which is assigned a class indicating the
> time representation, not the data object itself.<P>
> The most general (last) class of the "tframe" attribute should be
> "tframe".
> The method "is.tframe"  checks if an object is of class tframe, and
> the method "is.tframed" checks if an object has an attribute "tframe" of
> class tframe. In general, tframe methods act on the time frame (tframe)
> and
> tframed methods act on data which is tframed.<P>
> More specific methods can be defined for any special time
> representation (eg. below methods are defined for tframes of class
> c("tsp", "tframe") which are the old style tsp convention for time).
> Also, below, is an untested sketch of an implementaion for rts, cts,
> its and a class and methods style implementation of tsp called ts.<P>
> See the section "tframe  methods" below for some methods which should be
> supported. In particular, start(), end(), and periods() should be
> supported methods for any object of class tframe. (and until I make a
> lot
> of changes in my code, frequency is important.)<P>
> One implication of the desire to be able to use a statement like
> tframe(x) <- tframe(y)
> is that the tframe should not indicate which dim of the data is the
> time dimension. In general this will have to be another attribute of
> the data, but the current convention of using the first dimension for
> matrix data and the length for vector data, makes it unnecessary to
> specify.<P>
> Operations which should be possible on tframe'd data:
>   In the time dimension
>      - window, splice
>   In other dimensions
>      -bind  with shift to align the the tframe
>                  (and NA pad.start, pad.end, pad=T/F)
>      - []   without losing the tframe
> </UL>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> r-help mailing list -- Read
> Send "info", "help", or "[un]subscribe"
> (in the "body", not the subject !)  To:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

r-help mailing list -- Read
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: