Date: 2006-12-13 10:56:41
From: "Matt Hurd" <matthurd_at_[hidden]>
> Not really. A clock is a sequence of times, a ptime for example.
> Each value point in the series has a corresponding time point.
> Sometimes referred to as the "valid start time" as this the time the
> data becomes the truth from. Logically it is simply a sequence (Vs,
> If series have the same underlying clock you can just use index
> operations freely which are fast. If they don't have the same
> underlying clock you have to match based on time points.
> Your discretization say for daily data for stock data from 20
> different countries would invite trouble as the different clocks, due
> to different holiday schedules, could not be mixed by index offsets
> even though they were all daily. Similarly, for stocks at one
> exchange, data points are missing due to suspensions and other
> reasons, meaning clocks are often a little different.
> Without going to clocks you could simply call them a different
> discretization in your scheme by assigning a different integer and
> thus ensuring they don't mix. However you often wish to mix such
There's an important difference between *missing data* and *different sampling rates*. In the face of missing data (say, because of holidays or suspensions), but the same sampling rate (say, daily), you should be able to use the same indexes for all the data - some data will just be null-valued. Different application may handle nulls differently. For some, interpolation might be appropriate. But I had an application a while back in which nulls needed to be handled by *accumulating* values on the series that wasn't null until both series had values again. (This is particularly useful in portfolio performance measurement.) So interpolation certainly isn't *always* appropriate.
Using discretization w/ interpolation makes sense when analyzing series with different sampling rates, but I'm not convinced that it does just because of nulls in one series.
James Jones Administrative Data Mgmt.
Webmaster 375 Raritan Center Pkwy, Suite A
Data Architect Edison, NJ 08837
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk