Re: [boost] Upcoming review of Time Series

From: Eric Niebler (eric_at_[hidden])
Date: 2007-07-26 18:47:20

Hugo Duncan wrote:
> Eric,
> 
>> It shouldn't be the
>> series' job to keep a circular buffer of data for the algorithm to use.
>> Rather, if the algorithms requires a buffer of previously seen data, it
>> should cache the data itself,
> 
> Might it be worth a comment to the above affect in the documentation?  It  
> seems to be a fundamental principal for the library, which, at least to  
> me, wasn't clear.

Not a bad suggestion.

>> as in the rolling average implementation I
>> sent around a few days ago.
> 
> I missed that until after I had posted.
> 
>> The Sequence concept on which all the time series' are built requires
>> readable and incrementable cursors. That means the time series
>> algorithms *should* all work with an "input" or single-pass series types
>> -- that is, one with a destructive read. That would be the way to go
>> IMO. I could see a time series type implemented in terms of std::istream
>> that reads runs from std::cin, for instance. Or more practially, one
>> that memory-maps parts of a huge file and traverses it with single pass
>> cursors. This would be a very interesting time series! The algorithms
>> haven't been tested with such a single pass series, but I don't see a
>> fundamental problem with it.
> 
> Excellent. Files normally contain multivariate data though, so presumabley  
> it would require multiple series backed by a common object to do the  
> memory mapping?

Probably.

>> I'm not 100% sure I understand your use case. But most of the series
>> types and algorithms allow non-discrete sequences. That is, the offsets
>> can be floating point. Could that help?
> 
> Yes I had seen that, but wasn't sure how it worked for sampled data.  In  
> my case I have a multiple time series with a (common) sample time that  
> varies stochastically between 40-60ms. It wasn't clear to me that the  
> offsets could be non-constant stride (whether integer or floating point).   
> Even the sparse series seems to require a constant discretisation.

So, you have a discrete series (i.e., values at offsets), but the 
offsets map to discretizations according to some piecewise function? Did 
I get that right? That's interesting.

Most of the time series algorithms don't actually use the discretization 
for anything besides type-checking. The only exception is integrate(), 
which multiplies runs by the discretization. How do you use the 
discretization? Perhaps your usage can be accommodated with an extra 
function that maps from cursor to discretization. I think this is a 
refinement to the TimeSeries concept, but one which most of the 
algorithms (besides integrate) won't care about.

>> Yup, no convolution yet. Sure would be nice. Patches welcome! :-)
> 
> :-)

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com