From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2007-07-26 22:04:00


> 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