>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 http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-help-request at
stat.math.ethz.ch
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
