From: Stjepan Rajko (stipe_at_[hidden])
Date: 2007-08-11 13:32:18
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?
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?
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk