search

JuliaPOMDP / POMDPToolbox.jl

Support tools for solving POMDPs
Other
10 stars 9 forks source link

solver test function, problem test function #7

Open zsunberg opened 8 years ago

zsunberg commented 8 years ago

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:

test_solver(solver::Solver, problem=CryingBaby())

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

zsunberg commented 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

zsunberg commented 8 years ago

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

zsunberg commented 8 years ago

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.

ebalaban commented 8 years ago

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.

zsunberg commented 8 years ago

@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

mykelk commented 8 years ago

Solvers and problems should be separate. That is one of the main purposes of this API.