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

Interface with POMDPs belief updaters #38

Open
mossr opened this issue Sep 2, 2021 · 4 comments
Open

Interface with POMDPs belief updaters #38

mossr opened this issue Sep 2, 2021 · 4 comments

Comments

@mossr
Copy link
Member

mossr commented Sep 2, 2021

The ParticleFilters.jl package is excellent because it can also interface with the POMDPs belief updaters—I'm wondering if this is something you've intended for this package too.

@lassepe
Copy link
Collaborator

lassepe commented Sep 5, 2021

I think this is en excellent idea and I believe it has been discussed before but nobody has found time to do it so far. If you have some spare cycles I'd be glad to review a PR on this.

@lassepe
Copy link
Collaborator

lassepe commented Sep 5, 2021

@lassepe
Copy link
Collaborator

lassepe commented Sep 5, 2021

I just did some superficial browsing of the source code and it seems that would have to make a semi-breaking change to move from GaussianFilters.update to POMDPs.update. This would only be semi breaking because the signature is exactly the same.

I'm wondering whether we should use the opportunity (before POMDPs 1.0) to factor out the belief updater abstraction into its own package. This at least would make it easier to also convince other belief updater packages to implement that interface without having to pull in a dependency on the full POMDPs.jl package; e.g. LowLevelParticleFilters.jl (cc @zsunberg)

@zsunberg
Copy link
Member

zsunberg commented Sep 8, 2021

Hmmm... why would switching to POMDPs.update be breaking? If the signatures are really the same, then you can just make GaussianFilters.update the same as POMDPs.update. If they are not the same, it totally makes sense to have both - POMDPs.update can just be an "under the hood" connection to POMDPs.jl that allows Kalman Filters to work with POMDPs, but it does not need to be exposed as a primary part of GaussianFilters.jl for those who want to use it separately from POMDPs.jl.

I don't think POMDPs.jl is too heavy of a dependency. Its dependencies are pretty light https://github.com/JuliaPOMDP/POMDPs.jl/blob/master/Project.toml, and if someone wants to make a belief updater that works for a POMDP, they will need to import transition and observation anyways, so I don't think it is that helpful to break it up.

I think it is better to keep POMDPs.update as it is. It is certainly still possible for packages like LowLevelParticleFilters to have compatibility with POMDPs.jl in addition to their own interface that makes sense for them. If we did make another package like FiltersBase.jl, then we could put glue somewhere to make any FiltersBase updater work with POMDPs.jl

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