Boost logo

Boost :

From: Matthias Troyer (troyer_at_[hidden])
Date: 2007-08-08 23:45:50


On 7 Aug 2007, at 12:19, Eric Niebler wrote:

>
> Stjepan Rajko wrote:
>
>> IMO, this library deals with two different problem domains -
>> time_series and picewise constant functions. I also think that these
>> two domains are too different to be stuck in the same bucket. I
>> think
>> that a general time_series does not need to address the "run" concept
>> - perhaps, there can be a notion of a "weight" assigned to each
>> sample, which can represent time duration or other things. That
>> would
>> make it behave eqivalent to the run for the "integral" (which should
>> really just be a sum for time_series, IMO). Also, I think that for
>> the piecewise constant functions, runs should at least have the
>> option
>> of being open/half open intervals. With all this in mind, to some
>> extent, I believe that sparse_series and dense_series (which I see as
>> time series) should be treated differently than the rest of the
>> contaners (which I see as piecewise constant functions).
>
>
> You've hit on something important -- I agree time_series currently
> has a
> split personality, but I don't agree that its the sparse/dense vs.
> piecewise constant thing. It's the integral vs. floating-point offset
> thing. And I think those problems are fixable.

The sparse/dense versus piecewise constant is fine. The piecewise
constants are the running sums (integrals) of the sparse/dense
timeseries and thus well defined.

Floating point offsets:

for sparse/dense series there is no problem since data points just
exist at certain time points, and whether they are integer or
floating point does not matter.

for piecewise constant one just needs to define a convention: is the
interval left-closed right-open? or right-closed left-open? or should
this be flexible and defined by an (optional) tempate parameter?

Matthias


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk