Compatibility with DynamicPPL 0.38 + InitContext #2676

penelopeysm · 2025-09-24T18:05:52Z

It should be noted that due to the changes in DynamicPPL's src/sampler.jl, the results of running MCMC sampling on this branch will pretty much always differ from that on the main branch. Thus there is no (easy) way to test full reproducibility of MCMC results (we have to rely instead on statistics for converged chains).

TODO:

pMCMC (it at least runs and gives sensible results on simple models, proper tests will have to wait for CI to run)
Gibbs (same as above)
fix initial_params argument for most samplers to require AbstractInitStrategy
fix tests
changelog

Separate PRs:

use InitStrategy for optimisation as well

Note that the three pre-existing InitStrategies can be used directly with optimisation. However, to handle constraints properly, it seems necessary to introduce a new subtype of AbstractInitStrategy. I think this should be a separate PR because it's a fair bit of work.
fix docs for that argument, wherever it is (there's probably some in AbstractMCMC but it should probably be documented on the main site) EDIT: https://turinglang.org/docs/usage/sampling-options/#specifying-initial-parameters

penelopeysm · 2025-09-24T22:32:28Z

src/mcmc/gibbs.jl

-    # Get the initial values for this component sampler.
-    initial_params_local = if initial_params === nothing
-        nothing
-    else
-        DynamicPPL.subset(vi, varnames)[:]
-    end


I was quite pleased with this discovery. Previously the initial params had to be subsetted to be the correct length for the conditioned model. That's not only a faff, but also I get a bit scared whenever there's direct VarInfo manipulation like this.

Now, if you use InitFromParams with a NamedTuple/Dict that has extra params, the extra params are just ignored. So no need to subset it at all, just pass it through directly!

penelopeysm · 2025-09-24T22:33:47Z

src/mcmc/mh.jl

-# TODO(DPPL0.38/penelopeysm): This function should no longer be needed
-# once InitContext is merged.


unfortunately set_namedtuple! is used elsewhere in this file (though it won't appear in this diff) so we can't delete it (yet)

penelopeysm · 2025-09-24T22:34:53Z

src/mcmc/mh.jl

+function DynamicPPL.tilde_assume!!(
+    context::MHContext, right::Distribution, vn::VarName, vi::AbstractVarInfo
 )
-    # Just defer to `SampleFromPrior`.
-    retval = DynamicPPL.assume(rng, SampleFromPrior(), dist, vn, vi)
-    return retval
+    # Allow MH to sample new variables from the prior if it's not already present in the
+    # VarInfo.
+    dispatch_ctx = if haskey(vi, vn)
+        DynamicPPL.DefaultContext()
+    else
+        DynamicPPL.InitContext(context.rng, DynamicPPL.InitFromPrior())
+    end
+    return DynamicPPL.tilde_assume!!(dispatch_ctx, right, vn, vi)


The behaviour of SampleFromPrior used to be: if the key is present, don't actually sample, and if it was absent, sample. This if/else replicates the old behaviour.

penelopeysm · 2025-09-24T22:39:46Z

src/mcmc/particle_mcmc.jl

-    sampler::S
    varinfo::V
    evaluator::E
+    resample::Bool


For pMCMC, this Boolean field essentially replaces the del flag. Instead of set_all_del and unset_all_del we construct new TracedModel with this set to true and false respectively.

test/mcmc/ess.jl

github-actions · 2025-09-24T23:03:38Z

Turing.jl documentation for PR #2676 is available at:
https://TuringLang.github.io/Turing.jl/previews/PR2676/

codecov · 2025-09-24T23:48:24Z

Codecov Report

❌ Patch coverage is 79.20792% with 21 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (breaking@385f161). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
src/mcmc/repeat_sampler.jl	0.00%	6 Missing ⚠️
src/mcmc/particle_mcmc.jl	81.48%	5 Missing ⚠️
src/mcmc/emcee.jl	85.71%	2 Missing ⚠️
src/mcmc/sghmc.jl	0.00%	2 Missing ⚠️
src/optimisation/Optimisation.jl	60.00%	2 Missing ⚠️
ext/TuringDynamicHMCExt.jl	0.00%	1 Missing ⚠️
ext/TuringOptimExt.jl	0.00%	1 Missing ⚠️
src/mcmc/hmc.jl	75.00%	1 Missing ⚠️
src/mcmc/mh.jl	91.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##             breaking    #2676   +/-   ##
===========================================
  Coverage            ?   57.89%           
===========================================
  Files               ?       22           
  Lines               ?     1387           
  Branches            ?        0           
===========================================
  Hits                ?      803           
  Misses              ?      584           
  Partials            ?        0

☔ View full report in Codecov by Sentry.
📢 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.

penelopeysm · 2025-09-25T00:59:49Z

test/stdlib/distributions.jl

+                            seed = if dist isa GeneralizedExtremeValue
+                                # GEV is prone to giving really wacky results that are quite
+                                # seed-dependent.
+                                StableRNG(469)
+                            else
+                                StableRNG(468)
+                            end
+                            chn = sample(seed, m(), HMC(0.05, 20), n_samples)


Case in point:

julia> using Turing, StableRNGs julia> dist = GeneralizedExtremeValue(0, 1, 0.5); @model m() = x ~ dist m (generic function with 2 methods) julia> mean(dist) 1.5449077018110322 julia> mean(sample(StableRNG(468), m(), HMC(0.05, 20), 10000; progress=false)) Mean parameters mean Symbol Float64 x 3.9024 julia> mean(sample(StableRNG(469), m(), HMC(0.05, 20), 10000; progress=false)) Mean parameters mean Symbol Float64 x 1.5868

penelopeysm · 2025-09-26T20:51:53Z

For the record, 11 failing CI jobs is the expected number:

8x failing jobs because [sources] is not understood on 1.10
3x failing jobs because Libtask 1.12

There is also the failing job caused by base Julia segfault (#2655), but that's on 1.10 so overlaps with the first category.

penelopeysm · 2025-10-14T06:38:26Z

@mhauru, I haven't run CI against the latest revisions like removal of the del flag, but I think this might be meaty enough as it stands and also any adjustments arising from that PR (like renaming islinked) should be quite trivial.

mhauru

Good stuff, some minor comments.

I'm wondering about how to merge this. Should be review the code here, but then hold off merging to breaking before all the 0.38 compat fixes are in and a release of 0.38 is out, so all the temporary source stuff etc. can go and we can see tests pass?

src/mcmc/abstractmcmc.jl

mhauru · 2025-10-14T14:27:10Z

src/mcmc/mh.jl

+end
+DynamicPPL.NodeTrait(::MHContext) = DynamicPPL.IsLeaf()
+
+function DynamicPPL.tilde_assume!!(


Why is this needed? Doesn't MH just use init to get initial values like any other sampler, and then evaluate logpdfs on proposed steps?

Also, this looks like dynamical dispatch, since the context type depends on haskey(vi, vn), which could be a performance issue.

The rationale is in the comment right below this:

# Allow MH to sample new variables from the prior if it's not already present in the # VarInfo.

This preserves the old behaviour of MH (see

Turing.jl/src/mcmc/mh.jl

Lines 416 to 422 in cabe73f

function DynamicPPL.assume(

rng::Random.AbstractRNG, spl::Sampler{<:MH}, dist::Distribution, vn::VarName, vi

)

# Just defer to `SampleFromPrior`.

retval = DynamicPPL.assume(rng, SampleFromPrior(), dist, vn, vi)

return retval

end

) where it would sample new variables in models where the set of variables is not fixed (thus, e.g., initialisation might result in a different set of variables).

It directly mimics the old code for SampleFromPrior: https://github.com/TuringLang/DynamicPPL.jl/blob/c1d9b61933a6251fbeac249e8ebf03631f1f25bf/src/context_implementations.jl#L131-L171 which includes the haskey(vi, vn) check.

dynamic dispatch

I don't really understand what is so bad with this. (For what it's worth, I searched online and I can't find any actual explanation, so feel free to enlighten me.) I am just calling a different method, depending on the value of a Boolean which — sure — you can't know it for sure until runtime.

But if the 'not known until runtime' is the main problem, then it seems like literally any code that uses if haskey(vi, vn) is already problematic — would it be any better or worse if I were to inline the definitions here?

if haskey(vi, vn) # inline the definition of tilde_assume on DefaultContext here else # inline the definition of tilde_assume on Init here end

Surely that's okay, right, because otherwise it seems incredibly limiting for programming if you can't even use conditionals. So I assume I'm missing something. Like, what's the difference between 'dynamic dispatch' and 'code that uses conditionals because values aren't known until runtime'.

I'm not sure exactly how bad dynamic dispatch is either, and I wondered about the same question you are asking. Clearly some of it has to be okay. One difference to inlining is that without inlining the right method will have to be looked up from some method table at runtime. I'm not sure what exactly that causes, but maybe there are substantial costs there? Maybe those method tables are quite heavy data structures, compared to what the code itself is dealing with?

One the first point, I don't understand why MH needs to do this differently from every other sampler. I feel like whether to fall back to InitContext when evaluating logp for sampling purposes and hitting a tilde_assume!! for an unknown variable should be a decision made on a higher level than a sampler's implementation. I get that this is not new behaviour in this PR, though it's clunkyness is exposed in a different way because we now need to create a whole new context for MH.

dynamic dispatch

I searched a bit more and came across this: https://discourse.julialang.org/t/curious-about-the-internals-of-dynamic-dispatch/102888/8. In this example, there is some object a::A but A is an abstract type, so the compiler can't figure out which method f(a) refers to ahead of time and this is only resolved at runtime.

But here the compiler can perfectly figure out which methods are being used, because both InitContext and DefaultContext are concrete types. My impression is that what's going on here is not dynamic dispatch — the dispatch itself is static: when I write tilde_assume(...) the compiler has enough information to know which method is being referred to. Once haskey(vi, vn) is evaluated, there is no more looking things up in method tables. I think the dynamic dispatch thing only happens if the types of the arguments to tilde_assume!! are themselves not concrete.

The only downside from the compiler's point of view is that it can't aggressively cut out one branch ahead of time, because it can't figure out which branch it will go down.

Also, there would be issues with type stability if both tilde_assume!!s return different types. But that's not a dispatch problem, that's just plain old type stability and that wouldn't be affected if the function definitions were inlined.

I don't understand why MH needs to do this differently from every other sampler

I don't know either. I am in principle not opposed to cutting this out and just using DefaultContext, but I would probably prefer to not make this decision in this PR.

performance

If it's of any reassurance, I ran the following code on main plus this PR; main comes in at around 0.89 seconds, this PR at 0.83 seconds. (of course, I have no clue why or what made it better! 😄)

using Turing J = 8 y = [28, 8, -3, 7, -1, 1, 18, 12] sigma = [15, 10, 16, 11, 9, 11, 10, 18] @model function eight_schools_centered(J, y, sigma) mu ~ Normal(0, 5) tau ~ truncated(Cauchy(0, 5); lower=0) theta = Vector{Float64}(undef, J) for i in 1:J theta[i] ~ Normal(mu, tau) y[i] ~ Normal(theta[i], sigma[i]) end end model_esc = eight_schools_centered(J, y, sigma) @time sample(model_esc, MH(), 10000; progress=false);

mhauru · 2025-10-14T14:37:46Z

src/mcmc/particle_mcmc.jl

+    trng = get_trace_local_rng_maybe(ctx.rng)
+    resample = get_trace_local_resampled_maybe(true)
+
+    dispatch_ctx = if ~haskey(vi, vn) || resample


Like with MH, I wonder about dynamic dispatch here. Might be unavoidable and/or inconsequential in this case though.

mhauru · 2025-10-14T14:52:19Z

src/mcmc/repeat_sampler.jl

+    return DynamicPPL.init_strategy(spl.sampler)
+end
+
+function AbstractMCMC.sample(


I don't see why these became necessary now. Is it something about the type hierarchy around Sampler?

Yeah, RepeatSampler is weird, because it doesn't subtype InferenceAlgorithm. So some of the code like default sample methods has to be copied over for it. In the past, the methods used to be written for Union{Sampler{<:InferenceAlgorithm},RepeatSampler}. I think that's worse because it was less flexible, you couldn't change one without affecting the behaviour of the other.

test/mcmc/ess.jl

test/mcmc/is.jl

mhauru · 2025-10-14T15:11:34Z

test/Project.toml

 julia = "1.10"
+
+[sources]
+DynamicPPL = {url = "https://github.com/TuringLang/DynamicPPL.jl", rev = "breaking"}


Leaving this comment just as a reminder that this needs to be removed before merging.

mhauru · 2025-10-14T15:12:01Z

Project.toml

 Optim = "429524aa-4258-5aef-a3af-852621145aeb"
+
+[sources]
+DynamicPPL = {url = "https://github.com/TuringLang/DynamicPPL.jl", rev = "breaking"}


Likewise this.

mhauru · 2025-10-14T15:12:37Z

HISTORY.md

+You still need to use the `initial_params` keyword argument to `sample`, but the allowed values are different.
+For almost all samplers in Turing.jl (except `Emcee`) this should now be a `DynamicPPL.AbstractInitStrategy`.
+
+TODO LINK TO DPPL DOCS WHEN THIS IS LIVE


Likewise a reminder comment.

HISTORY.md

penelopeysm · 2025-10-16T14:31:08Z

I'm wondering about how to merge this.

Personally, I'm not too fussed. I think we discussed this last time round and IIRC you said you'd prefer to keep breaking 'clean' and mergeable into main at any given time (apologies if I am misremembering). If that's the case, then we should keep this as the base branch for DPPL 0.38 fixes, until 0.38 is released.

penelopeysm · 2025-10-17T16:17:47Z

Okay, I'm quite happy with where CI on this PR has gotten to. There are a handful of residual failures, which are mostly to do with Sampler methods that I removed a bit too early. #2689 properly handles the removal of Sampler so I don't feel inclined to chase them down here.

mhauru

I think we discussed this last time round and IIRC you said you'd prefer to keep breaking 'clean' and mergeable into main at any given time (apologies if I am misremembering). If that's the case, then we should keep this as the base branch for DPPL 0.38 fixes, until 0.38 is released.

You remember correctly, this would be my preference.

mhauru · 2025-10-17T16:45:33Z

src/mcmc/emcee.jl

 end
+# TODO(penelopeysm / DPPL 0.38) This is type piracy (!!!) The function
+# `_convert_initial_params` will be moved to Turing soon, and this piracy SHOULD be removed
+# in https://github.com/TuringLang/Turing.jl/pull/2689, PLEASE make sure it is!


Leaving a comment to track that this gets done before merging.

HISTORY.md

mhauru · 2025-10-17T17:26:27Z

src/mcmc/mh.jl

+end
+DynamicPPL.NodeTrait(::MHContext) = DynamicPPL.IsLeaf()
+
+function DynamicPPL.tilde_assume!!(


I'm not sure exactly how bad dynamic dispatch is either, and I wondered about the same question you are asking. Clearly some of it has to be okay. One difference to inlining is that without inlining the right method will have to be looked up from some method table at runtime. I'm not sure what exactly that causes, but maybe there are substantial costs there? Maybe those method tables are quite heavy data structures, compared to what the code itself is dealing with?

One the first point, I don't understand why MH needs to do this differently from every other sampler. I feel like whether to fall back to InitContext when evaluating logp for sampling purposes and hitting a tilde_assume!! for an unknown variable should be a decision made on a higher level than a sampler's implementation. I get that this is not new behaviour in this PR, though it's clunkyness is exposed in a different way because we now need to create a whole new context for MH.

Co-authored-by: Markus Hauru <[email protected]>

penelopeysm marked this pull request as draft September 24, 2025 18:06

penelopeysm force-pushed the py/dppl-0.38 branch from 9658a3e to ed43a02 Compare September 24, 2025 18:12

Import varname_leaves etc from AbstractPPL instead

10f960e

penelopeysm force-pushed the py/dppl-0.38 branch from ed43a02 to bf18516 Compare September 24, 2025 18:12

[no ci] initial updates for InitContext

3a04643

penelopeysm force-pushed the py/dppl-0.38 branch from bf18516 to 3a04643 Compare September 24, 2025 18:16

penelopeysm added 6 commits September 24, 2025 20:58

[no ci] More fixes

7e522a6

[no ci] Fix pMCMC

9bc58c8

[no ci] Fix Gibbs

02d1d0e

[no ci] More fixes, reexport InitFrom

27b0096

Fix a bunch of tests; I'll let CI tell me what's still broken...

7f12c3e

Remove comment

ed197f9

penelopeysm commented Sep 24, 2025

View reviewed changes

Fix more tests

c09c2a5

penelopeysm added 3 commits September 25, 2025 00:57

More test fixes

20f9e97

Fix more tests

ba4da83

fix GeneralizedExtremeValue numerical test

4b143ad

penelopeysm commented Sep 25, 2025

View reviewed changes

penelopeysm added 6 commits September 25, 2025 02:05

fix sample method

b5d82c9

fix ESS reproducibility

c315993

Fix externalsampler test correctly

3afd807

Fix everything (I _think_)

25c6513

Add changelog

d4aaa18

Fix remaining tests (for real this time)

aa3cfcf

penelopeysm mentioned this pull request Sep 25, 2025

Fixes for Turing 0.41 TuringLang/DynamicPPL.jl#1057

Merged

3 tasks

penelopeysm marked this pull request as ready for review September 25, 2025 13:24

Specify default chain type in Turing

c0ea6e0

fix DPPL revision

b0badc2

penelopeysm force-pushed the py/dppl-0.38 branch from 0d42641 to b0badc2 Compare October 3, 2025 09:43

penelopeysm requested a review from mhauru October 14, 2025 06:36

mhauru requested changes Oct 14, 2025

View reviewed changes

penelopeysm mentioned this pull request Oct 16, 2025

Remove Sampler and its interface TuringLang/DynamicPPL.jl#1037

Open

penelopeysm added 9 commits October 16, 2025 15:45

Fix changelog to mention unwrapped NT / Dict for initial_params

049e950

Remove references to islinked, set_flag, unset_flag

14d3c14

Merge branch 'breaking' into py/dppl-0.38

ae7e1e2

use setleafcontext(::Model, ::AbstractContext)

3a13c63

Fix for upstream removal of default_chain_type

5ed1230

Add clarifying comment for IS test

2a585fc

Revert ESS test (and add some numerical accuracy checks)

16198fa

istrans -> is_transformed

89a61af

Remove loadstate and resume_from

6af6330

penelopeysm force-pushed the py/dppl-0.38 branch from 6aed11b to 6af6330 Compare October 16, 2025 20:46

penelopeysm added 4 commits October 16, 2025 22:58

Remove a Sampler test

85a25b4

Paper over one crack

55e465b

fix resume_from

9c34014

remove a Sampler test

deff3fd

penelopeysm requested a review from mhauru October 17, 2025 16:17

mhauru reviewed Oct 17, 2025

View reviewed changes

Update HISTORY.md

bbbde35

Co-authored-by: Markus Hauru <[email protected]>

penelopeysm mentioned this pull request Oct 18, 2025

Gibbs soapbox #2540

Open

		# TODO(DPPL0.38/penelopeysm): This function should no longer be needed
		# once InitContext is merged.

	function DynamicPPL.assume(
	rng::Random.AbstractRNG, spl::Sampler{<:MH}, dist::Distribution, vn::VarName, vi
	)
	# Just defer to `SampleFromPrior`.
	retval = DynamicPPL.assume(rng, SampleFromPrior(), dist, vn, vi)
	return retval
	end

Compatibility with DynamicPPL 0.38 + InitContext #2676

Are you sure you want to change the base?

Compatibility with DynamicPPL 0.38 + InitContext #2676

Conversation

penelopeysm commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

penelopeysm Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions bot commented Sep 24, 2025

Uh oh!

codecov bot commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

penelopeysm Sep 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

penelopeysm commented Sep 26, 2025

Uh oh!

penelopeysm commented Oct 14, 2025

Uh oh!

mhauru left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

penelopeysm Oct 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

penelopeysm Oct 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

penelopeysm commented Oct 16, 2025

Uh oh!

penelopeysm commented Oct 17, 2025

Uh oh!

mhauru left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

penelopeysm commented Sep 24, 2025 •

edited

Loading

penelopeysm Sep 24, 2025 •

edited

Loading

codecov bot commented Sep 24, 2025 •

edited

Loading

penelopeysm Sep 25, 2025 •

edited

Loading

penelopeysm Oct 16, 2025 •

edited

Loading

penelopeysm Oct 18, 2025 •

edited

Loading