Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Coordination #1

Open
mschauer opened this issue Aug 14, 2019 · 6 comments
Open

Coordination #1

mschauer opened this issue Aug 14, 2019 · 6 comments

Comments

@mschauer
Copy link

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.

@simsurace
Copy link
Owner

simsurace commented Aug 15, 2019

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?

@mschauer
Copy link
Author

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 SVectors to Vectors, 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.

@mmider
Copy link

mmider commented Aug 19, 2019

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.

@simsurace
Copy link
Owner

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.

@mschauer
Copy link
Author

I am also not fully back among the living until that date. ;-)

@simsurace
Copy link
Owner

simsurace commented Dec 17, 2020

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants