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

POMDPs v0.8 Compatibility #26

Merged
merged 10 commits into from
Sep 20, 2019
Merged

POMDPs v0.8 Compatibility #26

merged 10 commits into from
Sep 20, 2019

Conversation

MaximeBouton
Copy link
Contributor

The main tweak is for ordered_vector tests.

The build is failing because DiscreteValueIteration needs n_states

@rejuvyesh
Copy link
Member

rejuvyesh commented Sep 17, 2019

Shouldn't it work with deprecation though? We can remove them in the next update? We can remove it from requirements for VI?

POMDPs.states(p::SparseTabularProblem) = 1:n_states(p)
POMDPs.actions(p::SparseTabularProblem) = 1:n_actions(p)
POMDPs.actions(p::SparseTabularProblem, s::Int64) = [a for a in actions(p) if sum(transition_matrix(p, a)) ≈ n_states(p)]
POMDPs.states(p::SparseTabularProblem) = 1:size(p.T[1], 1)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we call collect on these?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As is, states is an iterator, one can call collect(states(mdp)). I don't think we want to collect by default, what would be the use case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should collect by default

@MaximeBouton
Copy link
Contributor Author

MaximeBouton commented Sep 17, 2019

We have not implemented depraction warning in POMDPs.jl for n_actions, n_states yet. I don't know if the plan is to have them in v0.8 or to just remove those functions.

edit: Do you mean deprecation warnings in POMDPModelTools for n_states(::UnderlyingMDP) etc ?

@MaximeBouton
Copy link
Contributor Author

@zsunberg How do we want to deal with the info generation fucntion?

  • Should the usage be gen(DBNOut(:sp, :r, :info), mdp, s, a, rng)
  • Does it mean POMDPModelTools needs to add a node in the DDN?

@rejuvyesh
Copy link
Member

We have not implemented depraction warning in POMDPs.jl for n_actions, n_states yet. I don't know if the plan is to have them in v0.8 or to just remove those functions.

Yeah, since it was part of the API, we should have added the deprecation.

@zsunberg
Copy link
Member

Shouldn't it work with deprecation though? We can remove them in the next update? We can remove it from requirements for VI?

We have not implemented depraction warning in POMDPs.jl for n_actions, n_states yet. I don't know if the plan is to have them in v0.8 or to just remove those functions.

The deprecation warnings are implemented in src/deprecated.jl in v0.8. They are not deprecated in 0.7.3, which means we should just keep n_states(::UnderlyingMDP) for now. We can remove it later.

We're just trying to get all the packages to work with 0.8 at this stage, not cleaning them up yet. If we have both n_states and length, then it will work with both 0.7.3 and 0.8, which is what we want at the moment.

@zsunberg
Copy link
Member

@zsunberg How do we want to deal with the info generation fucntion?

I was thinking like this: https://github.com/JuliaPOMDP/POMDPs.jl/blob/146e97f5bc8e59f3e50a40aa608d8470fd571e43/test/test_ddn_struct.jl#L22
in lines 22-31

POMDPModelTools will have a function called add_infonode or something, and if people want an info output for their problem, they will have to add it with

POMDPs.DDNStructure(::Type{MyPOMDP}) = pomdp_ddn() |> add_infonode

Does that seem reasonable? The other option would be to overwrite

POMDPs.DDNStructure(::Type{M}) where M<:POMDP

or

pomdp_ddn()

but that seems like a very bad idea (and might even produce a warning)

@MaximeBouton
Copy link
Contributor Author

the piping approach sounds better, do you expect this in this PR or later?

@zsunberg
Copy link
Member

Yeah, I think it should be in this one. I think it should be easy to implement, right? I can do it if you would have me implement it.

@MaximeBouton
Copy link
Contributor Author

is that just it:
add_infonode(ddn) = add_node(ddn, :info, ConstantDDNNode(nothing), (:s, :a))
?
You can do it @zsunberg if you can I still have some misunderstandings:
What happens to generate_sri and generate_sori ?

@zsunberg
Copy link
Member

Ok, sure I'll do it. Does anyone have a preference on whether this node should be called :info or i? I guess I am leaning towards just i.

@MaximeBouton
Copy link
Contributor Author

I prefer info, I think it is clearer and not too verbose.

@zsunberg
Copy link
Member

zsunberg commented Sep 17, 2019 via email

@MaximeBouton
Copy link
Contributor Author

Do you think it is too long to use :actioninfo ? If not then let's do it for consistency.

@zsunberg
Copy link
Member

for (s, a, r, sp, i, ai) in stepthrough(m, policy, "s, a, r, sp, info, actioninfo")

vs

for (s, a, r, sp, i, ai) in stepthrough(m, policy, "s, a, r, sp, i, ai")

Yeah, it doesn't seem too long to me. I think we should lengthen both of them.

@zsunberg
Copy link
Member

What happens to generate_sri and generate_sori

Use gen(DDNOut(:sp, :r, :info), ...) and gen(DDNOut(:sp, :o, :r, :info), ...).

@zsunberg
Copy link
Member

Hey @MaximeBouton , I added the info stuff, but I did not update the docs yet. I will have that completed shortly. Tests pass for POMDPs v0.7.3, but not v0.8.0 - there is still some stuff to fix

Copy link
Contributor Author

@MaximeBouton MaximeBouton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @zsunberg, I just have two comments (see above) and then we can merge

###############################################################


if DDNStructure(MDP) isa POMDPs.DDNStructureV7
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't we check on the POMDPs.jl version instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what I initially though, but it didn't seem like there was a good way to do that, so this seems like a reliable enough proxy

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if Pkg.installed()["POMDPs"] < v"0.8.0"
something like that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how to reply to your comment on this below.

The problem with Pkg.installed() is that it can take a really long time (or at least it could in the past)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and it adds Pkg as a dependency (which is probably fine)

src/info.jl Outdated
"""
add_infonode(ddn::DDNStructure)

Create a new DDNStructure object with a new node labeled :info with parents :s and :a
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be valuable to have the example from the conversation in here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 it is in the docstring now

@zsunberg
Copy link
Member

Thanks @zsunberg, I just have two comments (see above) and then we can merge

We still need to fix some stuff with generate_ and sampletype so the tests pass with POMDPs v0.8. I am working on that now

@@ -11,7 +11,7 @@ let

solver = ValueIterationSolver(max_iterations = 100)
mdp_policy = solve(solver, mdp)
pomdp_policy = solve(solver, pomdp)
pomdp_policy = solve(solver, UnderlyingMDP(pomdp))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test does not make sense anymore

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, but it doesn't hurt anything. At least it exercises a lot of the functions. I think it is fine

###############################################################


if DDNStructure(MDP) isa POMDPs.DDNStructureV7
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if Pkg.installed()["POMDPs"] < v"0.8.0"
something like that?

@zsunberg
Copy link
Member

I cleaned up things so that tests pass with POMDPs v0.8, but then noticed some problems with FullyObservablePOMDP, so I'm in the process of fixing it, but I won't have a chance to finish until tomorrow

@zsunberg
Copy link
Member

Ok, I think this is ready now. Tests pass with POMDPs 0.7.3 and 0.8. @MaximeBouton any other comments?

@zsunberg zsunberg merged commit 1e4096e into master Sep 20, 2019
@zsunberg zsunberg deleted the pomdps-08-compat branch August 5, 2020 19:51
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

Successfully merging this pull request may close these issues.

None yet

3 participants