Skip to content

Releases: TuringLang/DynamicPPL.jl

v0.37.1

13 Aug 16:10
0cf3440
Compare
Choose a tag to compare

DynamicPPL v0.37.1

Diff since v0.37.0

Update DynamicPPLMooncakeExt to work with Mooncake 0.4.147.

Merged pull requests:

v0.37.0

11 Aug 13:30
6742812
Compare
Choose a tag to compare

DynamicPPL v0.37.0

Diff since v0.36.15

DynamicPPL 0.37 comes with a substantial reworking of its internals.
Fundamentally, there is no change to the actual modelling syntax: if you are a Turing.jl user, for example, this release will not affect you too much (apart from the changes to @addlogprob!).
Any such changes will be covered separately in the Turing.jl changelog when a release is made.
However, if you are a package developer or someone who uses DynamicPPL's functionality directly, you will notice a number of changes.

To avoid overwhelming the reader, we begin by listing the most important, user-facing changes, before explaining the changes to the internals in more detail.

Note that virtually all changes listed here are breaking.

Public-facing changes

Submodel macro

The @submodel macro is fully removed; please use to_submodel instead.

DynamicPPL.TestUtils.AD.run_ad

The three keyword arguments, test, reference_backend, and expected_value_and_grad have been merged into a single test keyword argument.
Please see the API documentation for more details.
(The old test=true and test=false values are still valid, and you only need to adjust the invocation if you were explicitly passing the reference_backend or expected_value_and_grad arguments.)

There is now also an rng keyword argument to help seed parameter generation.

Finally, instead of specifying value_atol and grad_atol, you can now specify atol and rtol which are used for both value and gradient.
Their semantics are the same as in Julia's isapprox; two values are equal if they satisfy either atol or rtol.

DynamicPPL.TestUtils.check_model

You now need to explicitly pass a VarInfo argument to check_model and check_model_and_trace.
Previously, these functions would generate a new VarInfo for you (using an optionally provided rng).

Evaluating model log-probabilities in more detail

Previously, during evaluation of a model, DynamicPPL only had the capability to store a single log probability (logp) field.
DefaultContext, PriorContext, and LikelihoodContext were used to control what this field represented: they would accumulate the log joint, log prior, or log likelihood, respectively.

In this version, we have overhauled this quite substantially.
The technical details of exactly how this is done is covered in the 'Accumulators' section below, but the upshot is that the log prior, log likelihood, and log Jacobian terms (for any linked variables) are separately tracked.

Specifically, you will want to use the following functions to access these log probabilities:

  • getlogprior(varinfo) to get the log prior. Note: This version introduces new, more consistent behaviour for this function, in that it always returns the log-prior of the values in the original, untransformed space, even if the varinfo has been linked.
  • getloglikelihood(varinfo) to get the log likelihood.
  • getlogjoint(varinfo) to get the log joint probability. Note: Similar to getlogprior, this function now always returns the log joint of the values in the original, untransformed space, even if the varinfo has been linked.

If you are using linked VarInfos (e.g. if you are writing a sampler), you may find that you need to obtain the log probability of the variables in the transformed space.
To this end, you can use:

  • getlogjac(varinfo) to get the log Jacobian of the link transforms for any linked variables.
  • getlogprior_internal(varinfo) to get the log prior of the variables in the transformed space.
  • getlogjoint_internal(varinfo) to get the log joint probability of the variables in the transformed space.

Since transformations only apply to random variables, the likelihood is unaffected by linking.

Removal of PriorContext and LikelihoodContext

Following on from the above, a number of DynamicPPL's contexts have been removed, most notably PriorContext and LikelihoodContext.
Although these are not the only exported contexts, we consider unlikely that anyone was using other contexts manually: if you have a question about contexts other than these, please continue reading the 'Internals' section below.

If you were evaluating a model with PriorContext, you can now just evaluate it with DefaultContext, and instead of calling getlogp(varinfo), you can call getlogprior(varinfo) (and similarly for the likelihood).

If you were constructing a LogDensityFunction with PriorContext, you can now stick to DefaultContext.
LogDensityFunction now has an extra field, called getlogdensity, which represents a function that takes a VarInfo and returns the log density you want.
Thus, if you pass getlogprior_internal as the value of this parameter, you will get the same behaviour as with PriorContext.
(You should consider whether your use case needs the log prior in the transformed space, or the original space, and use (respectively) getlogprior_internal or getlogprior as needed.)

The other case where one might use PriorContext was to use @addlogprob! to add to the log prior.
Previously, this was accomplished by manually checking __context__ isa DynamicPPL.PriorContext.
Now, you can write @addlogprob (; logprior=x, loglikelihood=y) to add x to the log-prior and y to the log-likelihood.

Removal of order and num_produce

The VarInfo type used to carry with it:

  • num_produce, an integer which recorded the number of observe tilde-statements that had been evaluated so far; and
  • order, an integer per VarName which recorded the value of num_produce at the time that the variable was seen.

These fields were used in particle samplers in Turing.jl.
In DynamicPPL 0.37, these fields and the associated functions have been removed:

  • get_num_produce
  • set_num_produce!!
  • reset_num_produce!!
  • increment_num_produce!!
  • set_retained_vns_del!
  • setorder!!

Because this is one of the more arcane features of DynamicPPL, some extra explanation is warranted.

num_produce and order, along with the del flag in VarInfo, were used to control whether new values for variables were sampled during model execution.
For example, the particle Gibbs method has a reference particle, for which variables are never resampled.
However, if the reference particle is forked (i.e., if the reference particle is selected by a resampling step multiple times and thereby copied), then the variables that have not yet been evaluated must be sampled anew to ensure that the new particle is independent of the reference particle.

Previousy, this was accomplished by setting the del flag in the VarInfo object for all variables with order greater or equal to than num_produce.
Note that setting the del flag does not itself trigger a new value to be sampled; rather, it indicates that a new value should be sampled if the variable is encountered again.
This Turing.jl PR changes the implementation to set the del flag for all variables in the VarInfo.
Since the del flag only makes a difference when encountering a variable, this approach is entirely equivalent as long as the same variable is not seen multiple times in the model.
The interested reader is referred to that PR for more details.

Internals

Accumulators

This release overhauls how VarInfo objects track variables such as the log joint probability. The new approach is to use what we call accumulators: Objects that the VarInfo carries on it that may change their state at each tilde_assume!! and tilde_observe!! call based on the value of the variable in question. They replace both variables that were previously hard-coded in the VarInfo object (logp and num_produce) and some contexts. This brings with it a number of breaking changes:

  • PriorContext and LikelihoodContext no longer exist. By default, a VarInfo tracks both the log prior and the log likelihood separately, and they can be accessed with getlogprior and getloglikelihood. If you want to execute a model while only accumulating one of the two (to save clock cycles), you can do so by creating a VarInfo that only has one accumulator in it, e.g. varinfo = setaccs!!(varinfo, (LogPriorAccumulator(),)).
  • MiniBatchContext does not exist anymore. It can be replaced by creating and using a custom accumulator that replaces the default LikelihoodContext. We may introduce such an accumulator in DynamicPPL in the future, but for now you'll need to do it yourself.
  • tilde_observe and observe have been removed. tilde_observe!! still exists, and any contexts should modify its behaviour. We may further rework the call stack under tilde_observe!! in the near future.
  • tilde_assume no longer returns the log density of the current assumption as its second return value. We may further rework the tilde_assume!! call stack as well.
  • For literal observation statements like 0.0 ~ Normal(blahblah) we used to call tilde_observe!! without the vn argument. This method no longer exists. Rather we call tilde_observe!! with vn set to nothing.
  • @addlogprob! now always adds to the log likelihood. Previously it added to the log probability that the execution context specified, e.g. the log prior when using PriorContext.
  • getlogp now returns a NamedTuple with keys logprior and loglikelihood. If you want the log joint probability, which is what getlogp used to return, use getlogjoint.
  • Correspondingly setlogp!! and acclogp!! should now be called with a NamedTuple with keys logprior and loglikelihood. The acclogp!! method with a single scalar value has been deprecated and falls b...
Read more

v0.36.15

09 Jul 15:01
b4ee208
Compare
Choose a tag to compare

DynamicPPL v0.36.15

Diff since v0.36.14

Bumped minimum Julia version to 1.10.8 to avoid potential crashes with Core.Compiler.widenconst (which Mooncake uses).

Merged pull requests:

Closed issues:

  • Data subsampling without reinstantiating the model (#208)
  • Possibly confusing .~ meaning (#435)
  • InferenceObjects integration (#464)
  • Convenience macros to use within @model (#714)
  • evaluate!! shenanigans (#720)
  • to_submodel type instabilities (#794)
  • Composing models with latent and to_distribution (#802)

v0.36.14

07 Jul 12:08
acac44d
Compare
Choose a tag to compare

DynamicPPL v0.36.14

Diff since v0.36.13

Added compatibility with [email protected].

Closed issues:

  • change defaults: @addlogprob! not included in PriorContext() (#580)
  • (Maybe) Find a way to avoid initialising with undef values (#784)
  • values_as(vi, NamedTuple) doesn't preserve structure (#814)
  • Is there a rationale for why a VarInfo should have some but not all variables linked? (#968)

v0.36.13

04 Jul 14:49
92f6eea
Compare
Choose a tag to compare

DynamicPPL v0.36.13

Diff since v0.36.12

Added documentation for the returned(::Model, ::MCMCChains.Chains) method.

Merged pull requests:

v0.36.12

19 Jun 16:51
968c879
Compare
Choose a tag to compare

DynamicPPL v0.36.12

Diff since v0.36.11

Removed several unexported functions. The only notable one is DynamicPPL.alg_str, which was used in old versions of AdvancedVI and the Turing test suite.

v0.36.11

19 Jun 10:16
e49853c
Compare
Choose a tag to compare

DynamicPPL v0.36.11

Diff since v0.36.10

Make ThreadSafeVarInfo hold a total of Threads.nthreads() * 2 logp values, instead of just Threads.nthreads().

This fix helps to paper over the cracks in using threadid() to index into the ThreadSafeVarInfo object.

v0.36.10

29 May 14:37
2a1b650
Compare
Choose a tag to compare

DynamicPPL v0.36.10

Diff since v0.36.9

Added compatibility with ForwardDiff 1.0.

v0.36.9

27 May 11:55
bb0c857
Compare
Choose a tag to compare

DynamicPPL v0.36.9

Diff since v0.36.8

Fixed a failure when sampling from ProductNamedTupleDistribution due to missing tovec methods for NamedTuple and Tuple.

v0.36.8

25 May 17:56
a8a7026
Compare
Choose a tag to compare

DynamicPPL v0.36.8

Diff since v0.36.7

Made LogDensityFunction a subtype of AbstractMCMC.AbstractModel.

Merged pull requests: