Open mschauer opened 5 years ago
Hi Moritz, thanks for getting in touch about my package. I agree that some coordination would be useful. So is your main interest in inferring the stochastic process itself (i.e. the drift and diffusion terms of some SDE) from partial and noisy data? If yes, I think FPFs could be useful and we could discuss how to integrate inference. So far, one feature of my package in anticipation of eventually being able to learn the generative model is that the filter construction allows for the filtering problem to be distinct from the internal model on which the filter is based. E.g. a feedback particle filter carries its own copy of the model, which can in principle be adapted based on data (from simulations for example). However, there is currently no API for actually doing this.
Another possibility would be to allow FeedbackParticleFilters.jl to be integrated into one of your existing packages (I suppose you have some filtering algorithms implemented, but likely not FPFs since they are not so widely known yet, is that correct?).
Have you thought about the relation of your and my package to DiffEqFlux.jl and related ones?
Thank you for your detailed response. What do you think about the following?
So the type hierarchy I introduced in Bridge is quite old, so I have the plan of redoing it a bit. When I introduced it, I was not thinking about filtering yet, so nowadays I would combine a state model with an observation model as you do it as well. There I think we could share the same abstract infrastructure, as a third package we both import, say import AbstractStateSpaceModels: AbstractModel, ...
. Marcin and I could make a proposal how that could look like, taking inspiration from your code as well. Is there something you would like to change from your code as well? One crucial thing I would like to do differently is to not make the type of elements of the state space a type parameter of the abstract model type (we both have that currently, you as AbstractModel{S}
), so it becomes easier to switch representations under the hood , e.g. go from SVector
s to Vector
s, or from Float64
to Float32
.
With respect to the DifferentialEquations
ecosystem there are some steps at interoperability, but basically we are not so focused on implementing solvers and we focus more on the interplay between the different processes. Therefor we keep track of relationships which do not belong over there (e.g. which models have independent increments). Last time I checked the overhead of DifferentialEquations
it was a bit too high to call the solvers many thousand times as it happens in MCMC often, but that is something to reevaluate.
Hi Simone, just to add some motivation to what Moritz wrote, the reason why I think it would be useful to try to adapt some elements of a common infrastructure at these early stages (in cases when it makes sense) is that we could make our packages more appealing to the user (it's always great to have a broad range of methods to choose from), make it easier for ourselves to use each other's work and, going forward, think about a well-interacting universe of packages for dealing with stochastic processes.
I'm sorry for the long delay. I have been absorbed with grant writing the past months. I hope to come back to this thread around mid-November.
I am also not fully back among the living until that date. ;-)
Hi @mmider and @mschauer, sorry to have taken so long to get back to this. I'm cleaning up some stuff and thinking about expanding the functionality of my package quite a bit, so it would be nice to get back to thinking about potentially coordinating some efforts. Are there any updates from your side?
Hi Simone, welcome! @mmider and I saw this nice package and it appears we have some overlap in interest. Our background is a bit different (statistical inference for stochastic processes), it would be nice to discuss a bit what potential for coordination is there. We are also regularly on the julialang.slack.com under the same user names.