Deprecate AdvancedPS

[charlesknipp]

To facilitate a more uniform ecosystem, this PR is a means of deprecating AdvancedPS in favor of a Turing specific sequential Monte Carlo interface.

For context, this is a little more than a reorganization.

Design Choices

• Libtask.produce no longer occurs in the accumulator to ensure that a varinfo reflects the produces log score
• it is no longer necessary to include resample and varinfo in the task global storage
• ParticleContainer no longer requires tracked RNG, which should be handled in the sampler
• resampling looks a lot different, but behaves as it did from AdvancedPS
• SMC sampler overloads AbstractMCMC.sample instead of stepping through and bundling with the API

Minor User Facing Changes

• resamplers are now structs (Multinomial, Systematic, and ESSResampler)
• sampling with SMC now supports the ensemble key word argument to parallelize the re-weight step

Criticisms

• I wonder if the model traces and Libtask utilities belong in an extension like DynamicPPLLibtaskExt.jl
• I am split on whether I should create a new struct for ParticleContainer or keep it as an alias for Vector{<:Particle}

Feel free to make changes. I am open to suggestions. Otherwise, unit tests pass locally so it should be ready to merge.

[codecov]

Codecov Report

❌ Patch coverage is 94.36620% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.05%. Comparing base (98e9773) to head (1c0be67).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/mcmc/particle_mcmc.jl	93.96%	16 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2848      +/-   ##
==========================================
- Coverage   85.09%   84.05%   -1.04%     
==========================================
  Files          23       24       +1     
  Lines        1516     1643     +127     
==========================================
+ Hits         1290     1381      +91     
- Misses        226      262      +36     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[charlesknipp]

the unit tests currently failing are only off by a slightly larger absolute tolerance. Not totally convinced its the fault of the sampler, but I'd appreciate some feedback/sanity checks

[yebai]

I did a partial review today. Here are a few comments:

It would be helpful to include a high-level overview of the design of the new algorithm. I realize this is an unusual request for a code review, but particle Gibbs is a subtle algorithm, and it's difficult to assess correctness without understanding the overall design and implementation.

I think it's worth making a strong effort to avoid task-local storage and keep the implementation as functional as possible (i.e., by tracking all state explicitly in the TapedTask or particle).

I understand this is a substantial piece of work, so I'm happy to iterate on this over a few review cycles.

[charlesknipp]

@yebai

I think it's worth making a strong effort to avoid task-local storage and keep the implementation as functional as possible (i.e., by tracking all state explicitly in the TapedTask or particle).

The latest commit updates the interface to use taped globals.

It would be helpful to include a high-level overview of the design of the new algorithm. I realize this is an unusual request for a code review, but particle Gibbs is a subtle algorithm, and it's difficult to assess correctness without understanding the overall design and implementation.

Under the hood, smcsample does the exact same thing as AdvancedPS.sweep!, the only differences are (1) when Libtask produces and (2) how traced RNG works.

1. Producing in the accumulator implies that the tasks varinfo does not yet apply the current log score. As a solution, I produce later in the stack after the likelihood accumulates; using the taped globals to store the log score until I need to produce.
2. When resampling, split! ensures that each child has a different seed per RNG trace and prunes dead branches when splitting from the reference. Otherwise, we call update_keys! to generate new seeds according to the samplers RNG (not counting the reference), as opposed to storing another trace in the particle container.

There are a handful of similarities between my implementation and AdvancedPS. I suggest comparing specifically this AdvancedPS code and the highlighted section of my rewrite; which should provide a bit more clarity in terms of correctness of implementation.

To ensure this implementation is indeed valid, I wrote a few unit tests I feel are worth highlighting:

• test/essential/container.jl illustrates how I use the new structures for particle sampling.
• ensuring reference consistency ensures that the reference trajectory is replayed according to the intended RNG trace, therefore confirming the validity of the Particle Gibbs sampler.

[yebai]

Many thanks, @charlesknipp -- can you help take a look at #2853? #2853 passes all existing and extra tests and also fixes a few other legacy issues that date back to the early days of Turing.jl.

We could try to find a way to consolidate this PR and #2853 in the end.