
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.