Re: [Rd] Subsetting time series

From: Martin Maechler <>
Date: Tue 10 Aug 2004 - 18:05:00 EST

>>>>> "BDR" == Prof Brian Ripley <> >>>>> on Tue, 10 Aug 2004 05:47:28 +0100 (BST) writes:

    BDR> On Tue, 10 Aug 2004, Ross Ihaka wrote:
>> Rob Hyndman wrote:
>> > When part of a time series is extracted, the time series component is
>> > lost. e.g.,
>> > x <- ts(1:10)
>> > x[1:4]
>> >
>> > It would be nice if there was a subsetting function [.ts to avoid this
>> > problem. However, it is beyond my R-coding ability to produce such a
>> > thing. Is someone willing to do it?

    BDR> There is a [.ts, in src/library/stats/R/ts.R, and it is documented     BDR> (?"[.ts").

>> Have you had a look at "window"? The problem with "["
>> its that it can produce non-contiguous sets of values.

    BDR> Yes.

indeed. window() is what we have been advocation for a long time now ... (but see below).

    BDR>   If you look in the sources for [.ts you will see,
    BDR> commented, the code that was once there to handle cases
    BDR> where the index was evenly spaced.  But it was removed
    BDR> long ago in favour of window().  I tried to consult the
    BDR> logs, but it seems that in the shift from CVS to SVN
    BDR> recently I can't get at them.  I think the rationale
    BDR> was that x[ind] should always produce an object of the
    BDR> same class.

well, that can't have been the only rationale since now x[ind] is *not* of the same class - when the "ts" property is lost in any case.

I don't much like the current behavior of "[.ts" either. It should either work by returning the "ts" object in the equidistant case and give a warning (at least) in the non-equidistant case.
OTOH, intuitively, when 'ind' has length 1, x[ind] should just give a number... [grumble..]
But maybe it's only a very small performance hit when that continues to carry the "ts" class attribute along.

If we think of the data.frame analogue, we might consider defining "[[.ts" for extracting numbers and "[.ts" to always return a time series or an error.
But that is probably too much incompatible to current behavior.

Martin mailing list Received on Tue Aug 10 18:07:40 2004

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 08:59:17 EST