Matt Hurd wrote:
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).
<snip>
Perhaps having ptime offsets is part of the answer. It seems you have something very close to the solution lurking in there.
Yes, I think what is there already can be pressed into service to achieve the same effect. Conceptually, a TimeSeries (as defined by Boost.Time_series) is two sequences: the elements and the runs. The elements are the values of the time series, and the runs are a sequence of (offset, end offset) pairs [*]. And the offsets can be integral or floating point (or ptimes, I guess). So if I'm understanding correctly, all we need is a flexible way to view the elements of one time series given the runs of another. Does that make sense?
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.
That would be great.
I think your code looks very nice for its intended domain.
Thanks! [*] Obviously, a time series doesn't need to be stored in memory that way, so long as it's able to present that interface. A sparse series need not store end offsets, and a dense series need not store any offsets at all -- the runs sequence can be generated on the fly. -- Eric Niebler Boost Consulting www.boost-consulting.com