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

From: Eric Niebler (eric_at_[hidden])
Date: 2006-12-14 13:46:10

Darryl Green wrote:
> I (tried to) send this yesterday but some prob with my mailer.
> I see the idea of nulls has been discussed a bit by Matt Hurd and James 
> Jones.
> 
> Eric Niebler wrote:
> 
>  >
>  > I think the current framework can handle this situation quite 
> naturally. The offsets need not be integral multiples of the 
> discretization. The offsets can be floating point, which can be used to 
> represent exact times. Or as Jeff Garland suggested, the offset could in 
> theory be a posix ptime (not tested). That way you wouldn't have to pass 
> around a separate vector representing the times, or make your data tuple 
> with times.
>  >
> 
> It was only when I read this that I took another look at the docs and 
> realized that your library is using a non-uniform sampling model. This 
> is interesting - but could make some algorithms hard to write and/or 
> much less efficient? 

<snip>

I think you misunderstood, or I was unclear. The library accommodates 
both uniform and non-uniform sampling. In another reply, I wrote:

> 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?
> 
> [*] 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.

Take the case of a dense_series. It has uniform sampling. Its "runs" 
sequence has the property of being "dense", meaning that each run is of 
unit length, and the run offsets are monotonically increasing. 
Obviously, finding a sample with a particular offset in a dense series 
is O(1), but not in a sparse series. Algorithms can test for density 
using a trait and select an optimal implementation. The default 
implementation would handles series with non-uniform sampling.

It's all done using compile time traits, so there is zero runtime overhead.

HTH,

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com