Develop concept

[donhausk]

Hi there, I have changed large parts of my code since my last PR in the AdvancedPS package. The package is now ready for a serious PR. The package might seem a bit confusing and I think it’s best if I explain it here.

The package follows two main goals. The first one is to remove the Particle Filter form Turing in a way that it is easy to make Turing dependent on Advanced PS. This is exactly what the files in the folder Core are doing. The sample! function in Core/samples.jl takes a particle container, an instance of an algorithm struct and a struct of utility functions as arguments and performs one whole sampling step. In order to make Turing dependent on AdvancedPS and therefore remove the container.jl file, it is only necessary to specify the utility functions and fill a particle container. However, making Turing dependent on AdvancedPS is not the primary goal at the moment.

The second aim of the package is to create a stand-alone Particle Filter package, which allows the user to implement a large variety of Particle Filters. This is achieved in the following way:

1. The user has to specify an executable task – there are two Examples of how to do this in the Examples folder. The task is already highly dependent on the algorithm and features like proposal distributions must be specified inside the tasks. The structure I have chosen in the Examples uses the self defined functions:
   initialize : This is simply to get a instance of the trace.
   update_var :Here, the variables of interest are stored. This is similar to assume in Turing .
   report_transition – This is used to compute the weights.
   report_observation – This is used to compute the weights. This function calls produce(), which leads to a resample step.
   Note that this is just a proposed structure and is fairly general. However, using a macro, it would be relatively easy to generate a task, which has such a structure. Therefore, the task has to be viewed as something similar to a model in Turing after invoking the sampler.

2. The user has to specify a variable container such as VarInfo in Turing. One of the examples uses the VarInfo from Turing as base container. There are two main reasons why I did not want to restrict the package to VarInfo. First, VarInfo is still part of Turing and I do not want to make the package dependent on Turing, and second, for state space models, where every state is a vector of the same dimension, it is more efficient to use simpler containers. This is done in the second example.
   Note that the example based on VarInfo uses the compiler3.0 branch from Turing. Regarding performance; On my machine, the example with the custom container significantly outperformed the example based on VarInfo and the implementation using standard Turing Particle Filters. In addition, my example using VarInfo was slightly faster than Turing, which was expectable.

3. Once a container including the required utility functions is defined and the task is crated, sampling can be done by calling sample(model,algorithm, utility_function, continer, n_samples) . The sample function is following the structure from the package AbstractMCMC and the returns a chain struct.

4. The package allows the implementation of a broad range of algorithms and could be used for other packages as basis. The problem about Particle Filters is that they are often used for state space models, which have very restrictive structure. Using this package, it would be easy to write a model macro for state space models. On the other hand, this package allows Particle Filters to be used for Turing, meaning that arbitrary complex models can be infered. It would of course be great if someone has interest in writing model macros, which generate tasks.

In addition, a few remarks regarding the structure:

The TaskInfo struct is important because it is used to store the logpdf. TaskInfo structs are sampler specific in order to give some extra freedom. For example, when using PGAS, the ancestor sampling weights could also be computed inside the task and stored inside PGASTaskInfo.

The Sampler has no field state. This could be added, however, since the particle container/ the reference trajectory are somehow equivalent to a state, I decided to omit it.

I hope this short text gives an overview over the package. Regarding the PR, it would be great if the focus could be put on the functionality and the overall structure. Having a first version allows other people to contribute as well. In addition, I am open for discussions on the structure of the package. Note that at the moment, the package is not user friendly at all and mainly useful for research code. This might be changed, however, I do not have time for the moment to do this.

Additional Note: The Tests require the compiler3.0 branch from Turing!