JuliaPOMDP / POMDPs.jl

MDPs and POMDPs in Julia - An interface for defining, solving, and simulating fully and partially observable Markov decision processes on discrete and continuous spaces.
http://juliapomdp.github.io/POMDPs.jl/latest/
Other
665 stars 100 forks source link

Merge GenerativeModels into POMDPs, register POMDPToolbox, POMDPModels, ParticleFilters #135

Closed zsunberg closed 7 years ago

zsunberg commented 7 years ago

Hey guys,

So I was thinking about registering ParticleFilters on METADATA because it might be useful to people outside of those using POMDPs.jl. One barrier to that is that it depends on GenerativeModels. GenerativeModels seems like too generic of a name to register. Thus, I guess our best way forward would be to roll it into POMDPs.jl.

While we're at it, it seems like we should register POMDPToolbox because it is where nearly all of the functionality is right now. And in order to test POMDPToolbox, we would need to register POMDPModels. Then the only things left unregistered would be solvers (which might not be good to register because a lot of them are acronyms) and other problems that people might implement.

What does everyone think?

This also might mitigate people concluding things like this (from an actual post):

They [JuliaPOMDP] have large web of interdependencies, most of which are not registered packages, and their own package manager to handle it. I'm weary of depending on that, and I'd prefer to make our own path.

etotheipluspi commented 7 years ago

I'm not against the idea, but what happens to tooling packages going forward? It probably makes sense to decide case by case wether a new package that contains more general tools should be registered or not. Maybe we can put those kinds of issues up to a vote, and also be strict about adding new packages to the JuliaPOMDP project.

Anyway, its a yes from me on registering the two packages, and merging GenerativeModels to POMDPs.jl.

mykelk commented 7 years ago

It feels like POMDPs.jl should be the base and not bring in GenerativeModels, but I'm willing to be persuaded. I agree that GenerativeModels.jl is too generic a name, but perhaps POMDPGenerativeModels.jl would be okay?

ebalaban commented 7 years ago

Having wanted generate_* functions in POMDPs.jl from the start, I am, of course, somewhat biased towards that idea :-) I don't think they would pollute the interface too much and it would be nice to have both the "explicit" and the generative model interfaces in one place.

I am ok with registering POMDPToolbox and POMDPModels, as these two are fairly essential, but agree with @etotheipluspi that going forward we need to be selective with what we register and what we add to JuliaPOMDP.

rejuvyesh commented 7 years ago

Why not just have a submodule for GenerativeModels inside POMDPs.jl? People can ignore the submodule if they don't need it.

zsunberg commented 7 years ago

Hmm... I remember that JLD used to be a submodule of HDF5, but they moved away from that. I wonder why. Their case is different from ours though because our package is just an interface. I don't really like that idea because it is not common, but I could probably be persuaded.

POMDPGenerativeModels.jl seems too long to me. Maybe POMDPGen.jl (and maybe implement JuliaPOMDP/GenerativeModels.jl#11).

There's no technical issue with having all of the functions in POMDPs, and I don't think adding the generate_ functions in would be bloating the package. The only issue is communication. How do we communicate that these functions are alternate to the explicit model interface?

mykelk commented 7 years ago

I'm okay with it being included directly.

rejuvyesh commented 7 years ago
using POMDPs
using POMDPs.Generative # Don't use this if not a generative model

I agree that adding a few more functions won't bloat the package. But creating a submodule seems the most appropriate way to handle this. Just because submodules are not yet that popular shouldn't mean they should be ignored.

etotheipluspi commented 7 years ago

Is there a consensus on wether GenerativeModels.jl should be merged into POMDPs or not?

zsunberg commented 7 years ago

I'm convinced it should be, and I don't think there's a need for a submodule. I don't think a submodule makes things any clearer than good documentation and examples. @mykelk told me he's on board with whatever we decide. I was planning on merging it in sometime this week if I have time.

zsunberg commented 7 years ago

Working on this right now

zsunberg commented 7 years ago

Ok, got generativemodels merged into POMDPs master - now going to tag POMDPs, then will tag other packages sometime next week (before OSS4DM)

zsunberg commented 7 years ago

Order of things that need to happen to finish this

zsunberg commented 7 years ago

This is done - woo!