
My comment about "destructive" read shouldn't be taken to imply that it actually obliterates the data after its read. E.g., if you are using a memory mapped file as a back end, you can run a different algorithm on the same data by "resetting" the series by remapping the file.
But doesn't it imply (possible) multiple physical reads of the data?
If you want to push the data, and calculate many things in one pass, the library you want to use is the Accumulators library.
Already using it! and very well it works too. I suppose I was thinking this was more for descriptive statistics. Care to define the difference in scope? When I saw "time series" I thought "signal processing" - is that wrong? My use for this is essentially this: Read data from multiple data sources, each with possibly different sampling periods. Resample the data to a common discretisation. Feed the latest value of multiple series as inputs into a model. Derive a series as the difference between model outputs and other input series. Derive filtered versions of some of the signals. Write everything out to disk. I am doing this either after the fact, or in "real time" as the data is being logged. I suppose I could summarise my requirements as "labview or simulink for c++" :-) Maybe this is not what you are aiming for.
It seems from your comments at the start of "Defining New TimeSeries algorithms" and the display_run example, that most of the algorithms are implemented that way anyway.
I don't follow you. What do you mean?
Consider your example, struct display_run { template< class Value, class Offset > void operator()( Value const & value, Offset start, Offset stop ) const; }; or your adjacent_difference_functor which has the same method, then data is pushed to these functors (if I have understood correctly). So your top level algorithms, print_series or adjacent_difference pull data from the series and push it to the functors. I was therefore concluding that the "push interfaces" already existed, but were being viewed as undocumented implementation details rather constructs for library users. Hugo