Re: [boost] [time_series] Review

From: Eric Niebler (eric_at_[hidden])
Date: 2007-08-12 14:49:24

Stjepan Rajko wrote:
> On 8/8/07, Eric Niebler <eric_at_[hidden]> wrote:
>> Here, "from" and "to" can't really be iterators though, or, if they are,
>> they should yield a 3-tuple of (value, offset, end offset). An interface
>> like this is very unwieldy in signal processing, where you often collect
>> data by polling a value at an interval.
>>
>>    for(;;)
>>      series.push_back(poll_some_value(), last_time, current_time);
>>
> 
> <nit-pick>
> With the current convention of half-open intervals, wouldn't that be
> [last_time, current_time), and therefore series[current_time] not be
> affected by the above insertion?
> </nit-pick>

Picky, picky. ;-) Yes, you're right.

> On a less nit-picky note though, I still can't find a single outside
> reference in which something that assigns a value to a whole real set
> interval is called a time series.  Eric, you indicated that your
> choice for using range runs (as opposed to just points, I assume) was
> that this yielded superior generic algorithms.  But in the floating
> point case, this is causing that most of your structures to represent
> something that is not really a time series.  In rethinking the
> floating point case, are any of the strategies you are considering
> looking to put all of your structures in line with what the
> mathematical notion of what a time series is?

Would you agree that the time series types that use integral offsets are 
isomorphic to what a time series is, in the mathematical sense? Are 
there any time series (in the math sense) that are not representable 
using integral offsets?

> In one of your posts, you mentioned something along the lines of
> making Point concept a first class citizen of the library - IIUTC,
> that would be a good approach.  Furthermore, I think that the RangeRun
> should be rethought, so that a RangeRun is in effect equivalent to a
> countable set of Points even in the floating point case (where by "a
> countable set", I mean "a countable set significantly smaller than the
> one including every Point indexable by a floating point number between
> the start offset and end offset").  If not, then I see this as a
> Time_series+something else library, which is fine.  But with time
> series, I think a continuous interval is much less useful than a way
> to specify a number of discrete points in an interval.

I'm having a hard time seeing how this is any different that using a 
series with integral offsets and a floating point discretization. The 
time series library provides this functionality already. Can you clarify 
what you're suggesting?

I agree that the time series types that use floating point offsets are 
not very time series-ish in the math sense. But some have expressed the 
strong opinion during this review that the functionality they provide is 
useful.

I guess what I'm missing is a use case for non-integral offsets. Any 
reanalysis of what floating point offsets mean has to start there. Is it 
simply the desire to index into a sequence of points and interpolate 
between them in some way? If that's the case, then support for floating 
point offsets can be dropped in favor of a flexible interpolating 
facade. (IMO, something like that is needed anyway.) If someone really 
needs a way to say, "This signal really has the value of X in the time 
interval [Y,Z)" where Y and Z are floating point values, then continuous 
floating point runs are the way to go. That seems like a reasonable 
thing to want, even if it doesn't fit the mathematical definition of 
"time series".

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