Decide the fate of VarInfo.num_produce

[mhauru]

This is a feature of VarInfo that's only used by particle samplers. Having it stored in VarInfo doesn't feel like the right place, and we would like to get rid of it when we refactor VarInfo/SimpleVarInfo. However, having the sampler keep track of it is apparently not easy either, and might require changes to how some contexts work around samplers. We could also drop it, but that would mean losing existing particle sampler functionality.

Discussed with @torfjelde, @sunxd3, and @willtebbutt.

[torfjelde]

@yebai should also probably have a look at this 👍

[yebai]

We could move this to AdvancedPS, e.g. adding a num_produce field to AdvancedPS.LibtaskModel:

https://github.com/TuringLang/AdvancedPS.jl/blob/6c2cee380ce53ab25483e57aaaf381fbb8f31fd3/src/model.jl#L49-L53

Each LibtaskModel realisation corresponds to a particle / VarInfo.

cc @FredericWantiez @willtebbutt

[yebai]

@mhauru, do you want to try this? I'm happy to help you through the process if you have any questions.

[yebai]

For reference, the only place that we use the num_produce field is below:

DynamicPPL.jl/src/varinfo.jl

Lines 1716 to 1719 in 24a7380

	for i in 1:length(vi.orders)
	if i in gidcs && vi.orders[i] > get_num_produce(vi)
	vi.metadata.flags["del"][i] = true
	end

which is called by a function in Turing,

https://github.com/TuringLang/Turing.jl/blob/78d110afc17daaedbc492695d258c5eb8541463e/src/essential/container.jl#L41-L44

Particle MCMC samplers use this to remove obsolete random variables in VarInfo after a particle is copied/forked (as part of the resampling step in particle filtering algorithms).

[mhauru]

Can do. Will take me a moment though, I'll have to start by reading some wikipedia to get a basic idea of what particle MCMC does.

[yebai]

I thought I'd write more about num_produce if it is helpful.

The num_produce variable is used by particle Gibbs (PG), specifically during the "particle copying" step after each resample step. In PG, each resample step is triggered by a new observation (in state-space models, we filter upon new observations). For "particle copying", we need to replay the randomness stored in VarInfo. But we should terminate this replaying process at specific points of model execution (if you know the PG sampler, this is due to PG's reference particle). As such, the num_produce variable is used to determine these specific points to stop replaying.

In the DynamicPPL code, we delete random variable i with orders[i] greater than num_produce (see the above-referenced code block). Later, the tilde pipeline will resample random variables if they cannot be found in VarInfo, thus equivalent to stopping relaying.