Open zsunberg opened 8 years ago
Ok, I added the function. Is it true that every solver should be able to be used with this function? If not, we should discuss why it won't work
One annoying problem is that I can't set a default for the problem
argument. Since POMDPModels imports POMDPToolbox, I can't import POMDPModels. Maybe there should be a POMDPTest package that depends on both, or maybe POMDPModels should be part of POMDPToolbox
Hmmm.... I guess this isn't actually that simple because some problems have special requirements like upper and lower bounds that we haven't made an interface for yet.
This is not a bad idea, but yes, some solvers will require more configuration than others. DESPOT, for example, is parametrized by state, action, observation, lower-bound, upper-bound, transition distribution, and obs. distribution types - all to have things run as fast as possible.
@ebalaban, would it be possible to have the solver to specialize itself
with respect to the problem inside the solve()
function? For example, if
you need to allocate data structures filled with a specific state, action,
and observation type, could you have a DESPOTCore{S,A,O}
or
DESPOTTree{S,A,O}
object that is a member of the despot policy or solver
object and is created in the solve()
function?
The upper bound and lower bound objects would still need to be part of the
constructor, but it seems like init_upper_bound()
could be called within
solve()
, so the solver would not need to be introduced to the problem
until solve()
I guess we need to decide if this separation of solvers and problems should be an expectation - I have filed an issue in POMDPs ( JuliaPOMDP/POMDPs.jl#80 ) to discuss this.
On Sat, Apr 30, 2016 at 7:27 PM ebalaban notifications@github.com wrote:
This is not a bad idea, but yes, some solvers will require more configuration than others. DESPOT, for example, is parametrized by state, action, observation, lower-bound, upper-bound, transition distribution, and obs. distribution types - all to have things run as fast as possible.
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/JuliaPOMDP/POMDPToolbox.jl/issues/7#issuecomment-216008825
Solvers and problems should be separate. That is one of the main purposes of this API.
Hi all,
I am updating the POMDPs.jl documentation to reflect recent changes, and I think it would be helpful if we have a simple minimal test script for a solver that any solver should be able to run with. This should allow us to communicate expectations about how solvers should function.
The function will look like this:
Solver writers can then easily use it in their test scripts without having to set up a problem or simulator.
I guess that the best place to put that is here in POMDPToolbox. I'll put it in tomorrow, and we'll see if we can all agree on exactly how it should look.
We may also want a
test_problem()
script, but this might be more complex. Maybe these scripts are a first step towards the lint-like tool we sometimes discuss