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.
>> series.push_back(poll_some_value(), last_time, current_time);
> 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?
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
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
-- Eric Niebler Boost Consulting www.boost-consulting.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