From: Eric Niebler (eric_at_[hidden])
Date: 2006-12-13 19:56:10
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,
> 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.
[*] 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk