Boost logo

Boost :

From: Eric Niebler (eric_at_[hidden])
Date: 2007-08-09 00:26:02

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.

Eric Niebler
Boost Consulting
The Astoria Seminar ==>

Boost list run by bdawes at, gregod at, cpdaniel at, john at