Stjepan Rajko wrote:
On 8/8/07, Eric Niebler <eric@boost-consulting.com> 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