Particle data types

[ebalaban]

I'd like to propose adding particle-related data types to POMDPToolbox. I think that a number of solvers use particle-based belief representations and it would be good to have a more or less standard way of supporting that. We could start with the following two types, for example:

type Particle{T} state::T id::Int64 wt::Float64 end

type ParticleBelief{T} <: POMDPs.Belief particles::Vector{Particle{T}} end

Later we could add particle-based belief update algorithms, etc. Other suggestions are welcome, of course.

[mykelk]

Why have an id? How about we write out weight?

[ebalaban]

Eh, I had a vague thought that an id might be useful for keeping track of some original ordering in case particle ordering is randomized, but that might not ever be needed. I am happy to remove it. I am also happy to use 'weight' instead of 'wt' - I like 'weight' better, actually.

[mykelk]

If ordering is important then it can probably be done by the container of the particles. I think it is good to avoid abbreviations unless the names are too long.

[ebalaban]

Agreed. I'll wait for a bit longer to see if anyone has other suggestions or objections, then will go ahead and implement this.

On 9/15/2015 11:22 PM, Mykel Kochenderfer wrote:

If ordering is important then it can probably be done by the container of the particles. I think it is good to avoid abbreviations unless the names are too long.

— Reply to this email directly or view it on GitHub https://github.com/sisl/POMDPToolbox.jl/issues/2#issuecomment-140641832.

[ebalaban]

Implemented with 0f461ede9f.

[ebalaban]

Alas, I am going to have to go back to particle IDs to track particles. I did not foresee all of the implications, unfortunately, at the time when I agreed with removing the ID field. In DESPOT one needs to associate particles with specific random streams to ensure that scenarios execute properly and doing so through particle containers proved to be too messy (and resulted in me wasting a lot of time on tracking down obscure bugs).

I understand that mine is a somewhat uncommon need, so I'll suggest some options on how we could go about this:

1. Add id::int64 field to the Particle type

   Pros: Nice to have a single particle data type Cons: Some performance, memory use, and clarity impact. I don't foresee performance or memory use impact to be that significant (even if one uses a 1000 particles to represent belief, the extra memory use will be ~4KB), but it'll be there. We could also use a smaller data type for id (such as Uint16), but then there may be the extra overhead of converting to/from that smaller type.

2. Add a separate composite type, say IndexedParticle, to POMDPTools.jl

   Pros: Everyone else can continue happily using the original Particle Cons: Introduces type fragmentation and increases the probability of user confusion; may not be able to use general-purpose particle belief updaters with DESPOT.

3. Have a custom DESPOTParticle type defined in DESPOT code (either as a wrapper around Particle or a new "flat" type).

   Pros: The least impact on everyone else Cons: Problem writers will need to know about and use this type if they want to supply DESPOT-specific initial beliefs; may not be able to use general-purpose belief updaters with DESPOT.

Let me know please if anyone has a strong opinion on these options (or, perhaps, some better ideas). Option 1 would obviously be the most convenient for me, but if there are any objections to it, I'll just go with Option 3.

[mykelk]

I'm leaning towards 3.

[ebalaban]

Ok, since no one else seems to have an opinion on this issue of vital importance, I guess I'll just go with Option 3, i.e. define my own particle type.

[zsunberg]

Yeah, I think a good way to develop new ideas is to start out with something that is very specific to a particular use case (i.e. a particle type specific to DESPOT), and then later, if we find that the concept is useful in many applications we can generalize it.

On Wed, Nov 4, 2015 at 8:58 PM ebalaban notifications@github.com wrote:

Ok, since no one else seems to have an opinion on this issue of vital importance, I guess I'll just go with Option 3, i.e. define my own particle type.

— Reply to this email directly or view it on GitHub https://github.com/sisl/POMDPToolbox.jl/issues/2#issuecomment-153958197.

[ebalaban]

Ok, sounds good, let's use solver-specific particle types where needed, for the time being. If they prove to be useful beyond a single solver, we'll migrate them in here.