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