|
Boost : |
From: Matt Hurd (matthurd_at_[hidden])
Date: 2006-12-13 05:31:31
Hi Eric,
> So in this case, a "clock" is a discretization *and* a set of "holiday"
> offsets for which there is no data?
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,
Data).
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
things.
The neat thing about using the clock mechanism is that you can freely
mix sub second data, annual data and everything in between without
much fuss and if the data does derive from the same clock you simply
use direct offsets. Last time I did an implementation the clocks were
reference counted attributes of the series.
Perhaps having ptime offsets is part of the answer. It seems you have
something very close to the solution lurking in there.
> I'm having a hard time trying to image what an interface that uses
> clocks instead of discretizations would look like. Could you mock up an
> example (pseudo-code is fine)? English is a poor substitute for code.
Especially my English ;-)
I'll look to dig up some old code.
I think your code looks very nice for its intended domain.
Regards,
Matt.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk