Closed BoZenKhaa closed 11 months ago
The tests for tiger give an error because of the ambiguity of the convert_o method:
convert_o
using POMDPModels using POMDPTools using POMDPs using Random using Test using Compose R = [-1. -100 10; -1 10 -100] T = zeros(2,3,2) T[:,:,1] = [1. 0.5 0.5; 0 0.5 0.5] T[:,:,2] = [0. 0.5 0.5; 1 0.5 0.5] O = zeros(2,3,2) O[:,:,1] = [0.85 0.5 0.5; 0.15 0.5 0.5] O[:,:,2] = [0.15 0.5 0.5; 0.85 0.5 0.5] pomdp1 = TigerPOMDP() pomdp2 = TabularPOMDP(T, R, O, 0.95) policy = RandomPolicy(pomdp1, rng=MersenneTwister(2)) sim = RolloutSimulator(rng=MersenneTwister(3), max_steps=100) simulate(sim, pomdp1, policy, updater(policy), initialstate(pomdp1)) o = last(observations(pomdp1)) @test o == 1 # test vec ov = convert_o(Array{Float64}, true, pomdp1) @test ov == [1.] o = POMDPs.convert_o(Bool, ov, pomdp1) @test o == true
returns
ERROR: MethodError: convert_o(::Type{Bool}, ::Vector{Float64}, ::TigerPOMDP) is ambiguous. Candidates: convert_o(::Type{N}, v::AbstractArray{F}, problem::Union{MDP, POMDP}) where {N<:Number, F<:Number} @ POMDPs C:\Users\mrkos\.julia\packages\POMDPs\XBTe5\src\pomdp.jl:184 convert_o(::Type{O}, o, problem::POMDP{<:Any, <:Any, O}) where O @ POMDPTools.CommonRLIntegration C:\Users\mrkos\.julia\packages\POMDPTools\XBP7W\src\CommonRLIntegration\to_env.jl:110 Possible fix, define convert_o(::Type{O}, ::AbstractArray{F}, ::POMDP{<:Any, <:Any, O}) where {O<:Number, F<:Number} Stacktrace: [1] top-level scope @ c:\Users\mrkos\scth\projects\julia\psenisar_ukazka\dev\POMDPModels\test\tiger.jl:30
Maybe the suggested fix should be implemented in either POMDPs or POMDPTools?
POMDPs
POMDPTools
I thought that qualifying the call as POMDPs.convert_o in the test could fix this, but that does not work.
POMDPs.convert_o
Yeah, I'll try to fix it in POMDPs now.
Should be fixed now!
The tests for tiger give an error because of the ambiguity of the
convert_o
method:returns
Maybe the suggested fix should be implemented in either
POMDPs
orPOMDPTools
?I thought that qualifying the call as
POMDPs.convert_o
in the test could fix this, but that does not work.