WIP: Gaussian Processes

[sglvladi]

This PR stems from work performed on attempting to fit Gaussian Processes into the existing framework.

More specifically, a SimpleGaussianProcess transition model has been added, along with an example use-case.

Some notable points for discussion:

• Currently, the model expects a Track instead of a State object as an input to the function() method, while the same is also necessary when evaluating the matrix() and covar() methods, even though the model is inherently a LinearGaussianTransitionModel.
  • The main reason for the above is that the last num_lags timestamps are necessary for computing the Kernel matrix.
  • Even though this is currently compatible with most hypothesisers, since the actual Track instance is forwarded to the underlying predictors (see here), predictors like the KalmanPredictor would not forward this to the transition model.
• The model expects a start_time argument on initialisation, which is used to compute the respective timestamps (in terms of number of seconds since start_time).
  • This is not ideal since different tracks may require different values for start_time.
  • Note that start_time is not (necessarily) the same as the timestamp of the first track state.

NOTE: This PR is Work In Progress The main purpose of the PR at its current stage is to motivate thoughts and discussions on how this can be taken forward.

[sdhiscocks]

Some notable points for discussion:

• Currently, the model expects a Track instead of a State object as an input to the function() method, while the same is also necessary when evaluating the matrix() and covar() methods, even though the model is inherently a LinearGaussianTransitionModel.

  • The main reason for the above is that the last num_lags timestamps are necessary for computing the Kernel matrix.
  • Even though this is currently compatible with most hypothesisers, since the actual Track instance is forwarded to the underlying predictors (see here), predictors like the KalmanPredictor would not forward this to the transition model.

This is also compounded by the cache which pulls the state from the track for Kalman based predictors: https://github.com/dstl/Stone-Soup/blob/fbb48342253056d88b477160439fdadfcbc48c2b/stonesoup/predictor/_utils.py#L23-L25 The reason for passing a Track to the Predictor, was for the case where a predictor may use history of the track as part of the process, but the Kalman predictors at least don't cover the case that the model may use the history.

• The model expects a start_time argument on initialisation, which is used to compute the respective timestamps (in terms of number of seconds since start_time).

  • This is not ideal since different tracks may require different values for start_time.
  • Note that start_time is not (necessarily) the same as the timestamp of the first track state.

I'm not sure on the best approach to solve this. One less than ideal way would be to create a predictor that wrapped existing predictors, which could operate on the track, extract out the timestamps and work out the required start_time for the track (not clear on how start_time is defined), then either replace or modify the model linked to the wrapped predictor.

Maybe another solution is to pass the track as a keyword argument? This could be done in predict_lru_cache?