
Boost : 
From: Eric Niebler (eric_at_[hidden])
Date: 20070812 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 3tuple 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);
>>
>
> <nitpick>
> With the current convention of halfopen intervals, wouldn't that be
> [last_time, current_time), and therefore series[current_time] not be
> affected by the above insertion?
> </nitpick>
Picky, picky. ;) Yes, you're right.
> On a less nitpicky 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 seriesish 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 nonintegral 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.boostconsulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk