-
Notifications
You must be signed in to change notification settings - Fork 6
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
Conversation
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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
We have not implemented depraction warning in POMDPs.jl for edit: Do you mean deprecation warnings in POMDPModelTools for |
@zsunberg How do we want to deal with the
|
Yeah, since it was part of the API, we should have added the deprecation. |
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 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 |
I was thinking like this: https://github.com/JuliaPOMDP/POMDPs.jl/blob/146e97f5bc8e59f3e50a40aa608d8470fd571e43/test/test_ddn_struct.jl#L22 POMDPModelTools will have a function called 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) |
the piping approach sounds better, do you expect this in this PR or later? |
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. |
is that just it: |
Ok, sure I'll do it. Does anyone have a preference on whether this node should be called |
I prefer |
Ok, in that case, should I update POMDPSimulators to use `:actioninfo`, and
`:updateinfo` instead of `ai` and `ui` in histories?
…On Tue, Sep 17, 2019 at 10:26 AM Maxime ***@***.***> wrote:
I prefer info, I think it is clearer and not too verbose.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26?email_source=notifications&email_token=ABALI24QITEWHP3FSDTCCLTQKEHNRA5CNFSM4IXIOB22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD65I33I#issuecomment-532319725>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABALI2477YIGNBV3QNRRBMLQKEHNRANCNFSM4IXIOB2Q>
.
|
Do you think it is too long to use |
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. |
Use |
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 |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
We still need to fix some stuff with |
@@ -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)) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
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 |
Ok, I think this is ready now. Tests pass with POMDPs 0.7.3 and 0.8. @MaximeBouton any other comments? |
The main tweak is for
ordered_vector
tests.The build is failing because
DiscreteValueIteration
needsn_states