-
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
Added belief space binning #18
base: main
Are you sure you want to change the base?
Conversation
Wow @dylan-asmar , this looks really cool! Thanks for the contribution! @WhiffleFish when can you give it a review? |
src/tree.jl
Outdated
bin_levels_intervals::Vector{Dict{Symbol, Float64}} | ||
bin_levels_nodes::Vector{Dict{Int, Dict{Symbol, Union{Tuple{Int, Int}, Float64}}}} | ||
bin_levels::Vector{Dict{Symbol, Dict{Tuple{Int, Int}, Union{Float64, Int}}}} |
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.
These vectors of dictionaries (nested with further dictionaries) are really expensive in terms of performance. Also, the union typing results in some type instabilities.
Provided that a lot of the keys for these dictionaries are always the same (e.g. bin_value, bin_count, bin_error), can you find any way to flatten everything out into vectors, use fewer dictionaries, or just use structs/named tuples?
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. I wasn't a big fan of the dictionary implementation when I was doing it. Reworking as vectors wouldn't be too bad since the number of bins stays the same. I can mark this as WIP until I make these changes if desired.
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 changed the implementation with 3762018. In the process, I also found a bug with the dictionaries. With the binning, we are back down to the normal level of allocations vs the original implementation.
I updated the performance comparisons and added results for both delta=0.1
and delta=0.0001
.
Addresses/closes #3
Project.toml
to include SparseArrays IAW https://discourse.julialang.org/t/psa-compat-requirements-in-the-general-registry-are-changing/104958max_steps
insolver.jl
The only real improvement happens on the larger problems (Tag and RockSample(15, 10)) with longer solve times. Here are some benchmarks/performance data. I set the default to
use_binning=true
, but I don't have any strong feelings about that setting.Delta = 0.1
BabyPOMDP
Settings:
Benchmark
No Binning
With Binning
Policy Run
No Binning
With Binning
TigerPOMDP
Settings:
Benchmark
No Binning
With Binning
Policy Run
No Binning
With Binning
RockSamplePOMDP(5,5)
Settings:
Benchmark
No Binning
With Binning
Policy Run
No Binning
With Binning
TagPOMDP
Settings:
Benchmark
No Binning
With Binning
Policy Run
No Binning
With Binning
TagPOMDP
Settings:
Policy Run
No Binning
With Binning
RockSamplePOMDP(15,10)
Settings:
Policy Run
No Binning
With Binning
Delta = 0.0001
BabyPOMDP
Settings:
Benchmark
No Binning
With Binning
Policy Run
No Binning
With Binning
TigerPOMDP
Settings:
Benchmark
No Binning
With Binning
Policy Run
No Binning
With Binning
RockSamplePOMDP(5,5)
Settings:
Benchmark
No Binning
With Binning
Policy Run
No Binning
With Binning
TagPOMDP
Settings:
Benchmark
No Binning
With Binning
Policy Run
No Binning
With Binning
TagPOMDP
Settings:
Policy Run
No Binning
With Binning
RockSamplePOMDP(15,10)
Settings:
Policy Run
No Binning
With Binning