Possible new project names?

[yebai]

It would be good to consider a slightly more general name for this project so we could incorporate particle filters currently in SSMproblems. Some sensible candidates:

• GeneralisedFilters: inspired by @charlesknipp and @THargreaves's terminology on a generalised interface for filtering algorithms
• GPUFilters, if we decide to focus on a solid GPU implementation of particle and Kalman filters to compensate for the KalmanFilters.jl and AdvancedPS packages, then GPUFilters is also a good name

Thoughts?

cc @willtebbutt @Lilyql

[yebai]

also @FredericWantiez

[willtebbutt]

Before choosing a name as specific as e.g. GPUFilters, perhaps we should agree on what's going to go in this package vs other packages?

I'm aware of at least the following range of kinds of models that people are keen on:

1. models with closed-form solutions (HMMs, LGSSMs)
2. partially closed-form things (models where Rao-Blackwellistion is possible)
3. some domain-specific tracking models
4. models where basically nothing is analytically tractable (Levy-driven processes etc)

For each of the above, we may either

1. wrap an existing implementation, or
2. roll our own implementation.

Additionally, we have to choose what kind of backend we use: CPU (statically-sized arrays) vs CPU (dynamically-sized arrays) vs GPU-based arrays (presumably with a focus on CUDA, but now that support for a variety of GPUs is appearing throughout the ecosystem, being generic seems like a good idea). Perhaps we want to support all of them via abstraction.

For all of the permutations above, we should think about:

1. whether we're interested in supporting them at all, and
2. where they should be implemented.

Am I missing anything from the above?

Once we've agreed on roughly what we want, we can choose a sensible name for his package.

[yebai]

3. some domain-specific tracking models
4. models where basically nothing is analytically tractable (Levy-driven processes etc)

To quickly clarify: I think these models are more case studies of SSMProblems and this package. They will more likely appear in an example folder than the src folder.

[willtebbutt]

That's fine. So is the plan that everything else that is an implementation lives in this package, and we just have interface components in SSMProblems.jl?

[charlesknipp]

I quite like GeneralizedFilters, but if we want to go down that route we should converge on the filtering syntax a little more.

Additionally, we have to choose what kind of backend we use: CPU (statically-sized arrays) vs CPU (dynamically-sized arrays) vs GPU-based arrays (presumably with a focus on CUDA, but now that support for a variety of GPUs is appearing throughout the ecosystem, being generic seems like a good idea). Perhaps we want to support all of them via abstraction.

I'm of the opinion that we support them via abstraction with a generalized filtering recipe (see #56), hence the name GeneralizedFilters. My idea is that we dispatch on the initialise, predict and update steps of the filter.

Lastly, if we create a general enough framework to support various algorithms for the GPU, then dynamically sized CPU arrays would be parsimonious. I think it's worth a shot.

[THargreaves]

I would lean towards GeneralisedFilters too. I think the Rao-Blackwellisation is a real selling point and that is a novel implementation on both CPU and GPU.

I'm of the opinion that we support them via abstraction with a generalized filtering recipe (see #56), hence the name GeneralizedFilters. My idea is that we dispatch on the initialise, predict and update steps of the filter.

Would this be, e.g. dispatching on whether the state is a vector of states or batch CuArray of states?

[THargreaves]

Am I missing anything from the above?

Once we've agreed on roughly what we want, we can choose a sensible name for his package.

I don't think these are important omissions but for completion, we are also implementing smoothing and PMCMC algorithms which I would assume would also sit in this package. I feel like they are close enough to "filtering" that it's not confusing though.