You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment to use a model with ParticleDA a series of methods must be defined which we document, dispatching on the type of the model object, which we don't require to be subtyped from any top-level abstract type, as well as an init function with a standard interface which returns an instance of the model given a dictionary of parameters (and number of parallel tasks to use run across threads). For models which have extra structure we define extra optional methods that can be implemented - this is used for models with a conditionally Gaussian structure at the moment to support using the locally optimal proposal.
To better signal what the expected interface is for different model types and also allow using packages such as RequiredInterfaces.jl and Interfaces.jl to allow testing an implementation respects the required interface as suggested by @giordano, it would be useful to define an abstract type hierarchy that models need to subtype from, for example something like
abstract type StateSpaceModel endabstract type ConditionallyGaussianSSM <:StateSpaceModelend
We could also then have specific types for for example spatial models to support methods required for localised filters.
As an alternative as the models have a common substructure of
an initial state distribution (initial state model)
a state transition distribution (state transition model)
a conditional observation distribution given current state (observation model)
we could instead define a type hierarchy for these underlying components and define models as structs which compose together these different components. I think this would allow a more Julia-esque interface with shorter generic method names which are disambiguated by types of arguments rather than the current very verbose but explicit method names, for example something like
abstract type InitialStateModel endabstract type StateTransitionModel endabstract type StateModel{I<:InitialStateModel, T<:StateTransitionModel} endabstract type ObservationModel endabstract type StateSpaceModel{S<:StateModel, O<:ObservationModel}
# get_state_dimensiondimension(state_model::StateModel)
# get_observation_dimensiondimension(observation_model::ObservationModel)
# get_state_eltypeeltype(state_model::StateModel)
# get_observation_eltypeeltype(observation_model::ObservationModel)
# sample_initial_state!sample!(state_model::StateModel, rng::AbstractRNG)
# update_state_deterministic! + update_state_stochastic!sample!(state::AbstractVector, state_model::StateModel, rng::AbstractRNG)
# sample_observation_given_state!sample!(observation::AbstractVector, state::AbstractVector, observation_model::ObservationModel, rng::AbstractRNG)
# get_log_density_observation_given_statelog_density(observation::AbstractVector, state::AbstractVector, observation_model::ObservationModel)
# write_model_metadatawrite(file::HDF5.File, model::StateSpaceModel)
Specific structure in the components could also then be indicated by the type hierarchy for example for models with Gaussian state noise / linear-Gaussian observation models
abstract type GaussianStateTransitionModel <:StateTransitionModelendabstract type LinearGaussianObservationModel <:ObservationModelendabstract type ConditionallyGaussianSSM{S<:GaussianStateTransitionModel, O<:LinearGaussianObservationModel} <:StateSpaceModelend
The text was updated successfully, but these errors were encountered:
At the moment to use a model with
ParticleDA
a series of methods must be defined which we document, dispatching on the type of the model object, which we don't require to be subtyped from any top-level abstract type, as well as aninit
function with a standard interface which returns an instance of the model given a dictionary of parameters (and number of parallel tasks to use run across threads). For models which have extra structure we define extra optional methods that can be implemented - this is used for models with a conditionally Gaussian structure at the moment to support using the locally optimal proposal.To better signal what the expected interface is for different model types and also allow using packages such as
RequiredInterfaces.jl
andInterfaces.jl
to allow testing an implementation respects the required interface as suggested by @giordano, it would be useful to define an abstract type hierarchy that models need to subtype from, for example something likeWe could also then have specific types for for example spatial models to support methods required for localised filters.
As an alternative as the models have a common substructure of
we could instead define a type hierarchy for these underlying components and define models as structs which compose together these different components. I think this would allow a more Julia-esque interface with shorter generic method names which are disambiguated by types of arguments rather than the current very verbose but explicit method names, for example something like
Specific structure in the components could also then be indicated by the type hierarchy for example for models with Gaussian state noise / linear-Gaussian observation models
The text was updated successfully, but these errors were encountered: