Zachary Sunberg

I don't think you want to do ```julia @everywhere p = Progress(n, 1) ``` That will create a new progress meter on each proc. See #109 for a possible solution.

> If we directly return env.tile_map, there is a risk of unintended consequences. In my experience, you are right to worry about this. Returning a reference to the internal state...

> I don't know if BitArrays are supported in static arrays though. Unfortunately no :( https://github.com/JuliaArrays/StaticArrays.jl/issues/412 I did some benchmarks: ```julia World = falses(20, 20) display(@benchmark SMatrix{20,20}($World)) # mean: 103...

Oh yeah, that's probably a good idea - we should probably plot the timestep, the true location, and a background that shows light and dark regions

Not other than what I talked to you about. I think it will involve integrating with the DDN Structure support for POMDPs.jl. We need to think carefully about the DBN...

Yeah, SparseCat from ParticleCollection should be straightforward - we still have that probs_dict as _probs. > I don't see how you control the number of particles in Approach 2? In...

If you use `FORollout` it should use the state-based action space. If you use `PORollout`, by default it uses the `NothingUpdater` which doesn't pass any information in the belief to...

Got it. Is there a reason you can't use FORollout? It may be possible to use PORollout, but you will have to write some more code.

For online solvers like POMCP, unfortunately I don't think there is a better way to evaluate than through Monte Carlo simulations (the parallel simulator is the best for that: https://juliapomdp.github.io/POMDPSimulators.jl/latest/parallel/#Parallel-1)....

Also, I would strongly advocate for trying to solve the simplest and smallest possible version of your problem first before trying to move to a realistic size.