Discrete SSMs and the Forward Algorithm

[THargreaves]

Changes:

• Implemented a discrete latent dynamics type
• Implemented a forward algorithm compatible with the RBPF interface
• Add a unit test for the forward algorithm

Issues/questions

This implementation has opened some interesting questions on how we parameterise the types of the dynamics/observations.

The discrete latent dynamics in some sense have two type parameters which we'll call:

• T_state<:Integer: the type used in forward simulation to represent the current state index
• T_prob<:Real: the type used for storing the initial probability vector and transition matrix

I've ignored these in the current implementation, hardcoding T_prob -> Float64

The former is used for the state and so this is the type that would be passed on to the parent LatentDynamics{T}:

abstract type DiscreteLatentDynamics{T_state, T_prob} <: LatentDynamics{T_state} end

T_prob is used for preallocating a vector to store the filtered states and could also be used as a type constraint in the filtering methods, e.g.

function predict(
    model::DiscreteStateSpaceModel{T_state, T_prob},
    ::ForwardAlgorithm,
    step::Integer,
    state::Vector{T_prob},  # <--
    extra,
)
    ...
end

I'm generally a bit ignorant as to what the benefits of/conventions for type parameterisation are especially when it comes to AD support, so I'm not sure whether this is a good design choice or just overcomplicating things.

Any thoughts/feedback would be welcome.

[yebai]

Generally, parametric types are more autodiff-friendly. So what you do above is sensible.