|
| 1 | +--- |
| 2 | +title: Turing.jl Newsletter 5 |
| 3 | +description: The fortnightly newsletter for the Turing.jl probabilistic programming language |
| 4 | +categories: |
| 5 | + - Newsletter |
| 6 | +author: |
| 7 | + - name: The TuringLang team |
| 8 | + url: /team/ |
| 9 | +date: 2025-04-25 |
| 10 | +--- |
| 11 | + |
| 12 | +**DynamicPPL 0.36** |
| 13 | + |
| 14 | +A new minor version of DynamicPPL brings with it a few changes especially to the behaviour of submodels. These have not yet percolated up to Turing.jl, but will soon be. Firstly, prefixing behaviour is changed: consider these models |
| 15 | + |
| 16 | +```julia |
| 17 | +@model function inner() |
| 18 | + x ~ Normal() |
| 19 | +end |
| 20 | +@model function outer() |
| 21 | + a = [0.0] |
| 22 | + a[1] ~ to_submodel(inner()) |
| 23 | +end |
| 24 | +``` |
| 25 | + |
| 26 | +If you ran this model, you would find that the single random variable was called `a[1].x` — but this isn't the `x` field of the `1`st element of `a`, it's actually a variable whose name is literally just `Symbol("a[1].x")`. DynamicPPL changes this behaviour such that the variable is correctly recognised as the `x` field of the `1`st element of `a`. This means that if you are trying to, for example, condition on the variable, you can do: |
| 27 | + |
| 28 | +```julia |
| 29 | +outer() | (@varname(a[1].x) => 1.0) |
| 30 | +``` |
| 31 | + |
| 32 | +On the topic of conditioning, you can now also correctly condition or fix variables in a model before using it as a submodel, as this example demonstrates: |
| 33 | + |
| 34 | +```julia |
| 35 | +@model function inner() |
| 36 | + x ~ Normal() |
| 37 | +end |
| 38 | +@model function outer() |
| 39 | + a ~ to_submodel(inner() | (@varname(x) => 1)) |
| 40 | +end |
| 41 | +``` |
| 42 | + |
| 43 | +Previously, if you wanted to do this, you would have to condition on `@varname(a.x)`, meaning that you'd need to know the prefix before conditioning it. The current system allows for more modular construction of nested models. |
| 44 | + |
| 45 | +For more complete details, please see [the release notes](https://github.com/TuringLang/DynamicPPL.jl/releases/tag/v0.36.0). |
| 46 | + |
| 47 | +**TuringBenchmarking.jl** |
| 48 | + |
| 49 | +DynamicPPL 0.36 also brings new functionality that can be used for testing and benchmarking automatic differentiation on Turing models. This is what powers the [ADTests table](https://turinglang.org/ADTests/), which we shared last time round. (Psst — there are more examples now than before!) |
| 50 | + |
| 51 | +For more information, see the docstring of `DynamicPPL.TestUtils.AD.run_ad` in [the DynamicPPL docs](https://turinglang.org/DynamicPPL.jl/stable/api/#DynamicPPL.TestUtils.AD.run_ad). |
| 52 | + |
| 53 | +As a corollary of this, the AD benchmarking functionalities in TuringBenchmarking.jl are not really needed anymore. If you are using this package, we recommend that you switch over to use the functionality that's directly built into DynamicPPL. |
| 54 | + |
| 55 | +**AdvancedHMC compatibility with ComponentArrays** |
| 56 | + |
| 57 | +AdvancedHMC had a fairly long-standing issue where it couldn't always be used with ComponentArrays as the position / momentum. This has now been fixed; you can take a look at [the test suite](https://github.com/TuringLang/AdvancedHMC.jl/blob/459ebb8a10cc1bc7dbbc27ed79afa796c607697a/test/hamiltonian.jl#L77-L100) to see examples of how they can be used together. |
0 commit comments