On 8 Aug 2007, at 22:26, Eric Niebler wrote:
Matthias Troyer wrote:
On 7 Aug 2007, at 12:06, Eric Niebler wrote:
I'm sorry you ran into trouble with floating-point offsets. To be honest, they were added to the time_series library as a bit of an after-thought, and they are admittedly not a seamless addition. With integral offsets, runs are in fact half-open. Floating-point runs are not -- it's not clear what that would mean. (E.g., a delta series D has a 42 at [3.14,3.14) -- that's a zero-width half open range! What should D[3.14] return?) Some of the algorithms won't work with floating- point offsets. If you feel this part of the library needs more thought, that's a fair assessment. I'm certain that had you used integral offsets your experience would have been less frustrating.
I think with better docs and more strict type checking, integral and floating point offsets can both be supported without confusion.
Don't confuse the sparse/dense time series with piecewise constant functions. A delta series D has 42 at 3.14, not at any interval [3.14,3.14) - intervals should be used only for the piecewise constant functions.
Ah, but the library is built on top of lower-level abstractions that assume intervals. An interval (a run) is how algorithms on time series are expressed. This design was chosen because it makes it possible to write generic algorithms for lots of different types of series, and it works very well for integral offsets. The question is whether the abstractions upon which time series is built are compatible with a sparse series with floating point offsets and if so, what convention can be used so that the algorithms naturally give the correct results both with points and with runs. The way the library currently handles floating point offsets is /almost/ right, but not quite.
How do you express the delta series as a run then? length 1? Matthias