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.
Changes:
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 indexT_prob<:Real
: the type used for storing the initial probability vector and transition matrixI'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}
: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.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.