Generalized Local Information Measures

[gvalentini85]

Premise: what follows makes sense whereby metrics are computed from a multiple initial conditions dataset (i.e., a set of time series). Disregard otherwise.

It would be nice to have a way to tell the library to compute probabilities (or distributions) as a function of time (in contrast to using the entire time series) in local variants of metrics like AI or TE.
Where for "probabilities as a function of time" I mean that, if I'm computing AI at time step i with an history k, then probabilities are computed only over entries (i-k, .. i-1, i, i+1) of each time series in the dataset.

[dglmoore]

Discussion

As per @gvalentini85's initial synopsis, we are interested in broadening the definition of the local measures. Specifically, all of the local measures use distributions constructed from the entire time-series. One way of interpreting this approach is that there is a well-defined a priori distribution, and the entire time-series is used to estimate that distribution. An alternative approach is to accumulate the distribution as time progresses and only use previously observed events in the approximations. This accumulative approach can be accomplished in two ways: all previous time-steps can be used (cumulative), or only τ time steps in the past (moving-window).

To this end we propose the following API change. The various information measures will take two additional arguments, left and right, each of type int. These will specify the left- and right-boundaries of a moving-window used to construct the distributions. Special values of left and right can then be used to signify the a priori or cumulative approaches. In effect, the moving-window approach becomes the default as it is the most general.

Example API

EXPORT double *inform_local_active_info(int const *series, size_t n, size_t m, int b, size_t k,
    int left, int right, size, double *ai, inform_error *err);

[dglmoore]

This issue is somewhat problematic. While we can certainly implement the local variant as described, I'm not sure that we should. As such, we're pushing the ultimate decision on this issue to release v1.1.0.