Re: [boost] [ANN] Boost.Time_series: feedback requested

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,
> 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