Fix SMC2 sampler. about turing.jl HOT 2 CLOSED

Here's a design sketch for SMC2 implementation.

We make the following assumptions on the model to which SMC2 is applied:

1. All calls to param are made at the beginning of the program, that is before any calls to assume or observe.
2. All parameters are continuous.
3. The dimension of the parameters vector is the same in all possible execution paths. We can later modify this assumption to allow infinite collections of parameters.
4. The support of all parameters is the same in all possible execution paths.
5. The number of observes is the same in all possible execution paths.
   Violating any of those conditions results in undefined behaviour, where we would produce an exception whenever possible.

We can implement SMC2 by introducing a new data structure called ThetaParticle and using ParticleContainer{ThetaParticle}. Each ThetaParticle would start by creating a single execution thread that would go through the params, replaying supplied values if required. When the first probabilistic statement other than param is reached, it would initialise a ParticleContainer{TaskC} by copying its task n times. From that point on it would execute normal SMC, yielding control where required. I do not believe there are any problems with copying ParticleContainer{TaskC} without replaying anything, so I don't think there would be any problems with copying ThetaParticle. Therefore I hope we could implement SMC2 as a variant of SMC operating on ParticleContainer{ThetaParticle} with custom rejuvenation step.

Let me know your thoughts. If it all seems sensible, I will write a more detailed implementation outline.

from turing.jl.

Making assumptions about param explicit is a good idea. I did not find anything missing in this list : )

I thought about the implementation sometime ago, below are some notes:

Requirements:

• R1: Able to share theta's across x-particles belonging to the same theta-particle.
• R2: In the resampling step for theta particles, we need to duplicate theta-particles.
• R3: In the mutation/rejuvenations steps, we need to re-create theta's using external values (proposals).
• R4 (*): Able to support theta with varying dimensions.

(*): not urgent.

Two possible mechanisms:

• M1: Theta-particle replaying: the same as our existing SMC2 implementation, but with x-particle copying.
• M2: Theta-particle copying:

Pros of M2:

• Avoiding re-running executions generating thetas, thus computationally more efficient.

Cons of M2:

• There are some potential (future) risks when we want to support R4: in such cases, theta are indeed modified after creation, e.g. lazy arrays.
• R3 needs replaying external MH proposals to re-create theta's anyway.

NOTE: It first appears that we would need to use TArray (or equivalents) everywhere since theta's are shared by multiple x-particles. But since theta values are not modified after they are created, the need for TArray is no longer necessary.

from turing.jl.