Turing.jl newsletter

[penelopeysm]

Hello Turing.jl users!

We (the Turing.jl team) are starting a fortnightly series of updates on what we've been up to and what's in the works. We hope that this will provide you (our users) with some insight into the direction of the Turing ecosystem, and we'd also love for you to chip in with your thoughts if you have any.

You can keep up with this newsletter through any of the following methods:

1. Subscribing to this GitHub issue
2. Joining us at #turing on the Julia Slack workspace
3. Our website: https://turinglang.org/news/

We might post on other places like Discourse, too, this is still in the works.

[penelopeysm]

Turing.jl Newsletter 1 — 28 February 2025

Welcome to the inaugural issue of the Turing.jl newsletter!

New Turing behaviour, especially .~

Recently we have been focused on reworking a number of internal data structures in DynamicPPL.jl (this is the package that allows you to define models). We haven't released this yet but you might be interested to see the changelog on GitHub.
The main user-facing changes here are the simplification of broadcasted tilde .~ , which we previously posted about on Slack here. We also fixed a bug where the prefixes of nested submodels were applied in the wrong order.

DifferentiationInterface migration

From a developer perspective, we have now fully switched over to DifferentiationInterface.jl for automatic differentiation of models occurs. This work of course couldn't have been possible without @gdalle's work on DI itself and also his help with integrating it into DynamicPPL. This also paves the way for a long-standing goal of Turing, which is to expose a series of AD testing utilities that will allow AD package developers to test against a fixed set of models — this will allow us to formalise the idea of Turing being 'compatible' with a given AD package.

The plan for submodels

We have been discussing for a while now about how best to fully implement submodels (i.e. be able to treat submodels like distributions in the sense that we can sample from them, and also condition models on values obtained from submodels). There is currently a proposal which we've written up on GitHub, and goes into more depth about what we'd like to see and the underlying syntax. If this is a Turing feature that you use, do feel free to let us know what you think.

Turing.jl is now published (again!)

We recently published a new paper with a high-level overview of Turing.jl's features and implementation. Check it out!
Fjelde, T. E., Xu, K., Widmann, D., Tarek, M., Pfiffer, C., Trapp, M., Axen, S. D., Sun, X., Hauru, M., Yong, P., Tebbutt, W., Ghahramani, Z., & Ge, H. (2024). Turing.jl: A General-Purpose Probabilistic Programming Language. ACM Transactions on Probabilistic Machine Learning, 1(1). https://dl.acm.org/doi/10.1145/3711897

We have also published in the conference proceedings of the workshop on Languages for Inference (LAFI), which was held as part of POPL 2025:
Tim Hargreaves, Qing Li, Charles Knipp, Frederic Wantiez, Simon J. Godsill, Hong Ge. State Space Model Programming in Turing.jl. The Languages for Inference (LAFI) workshop, 2025. (link)

Looking for Google Summer of Code students

We are keen to take students for GSoC in 2025! If you are interested in working on a Python/R interface to JuliaBUGS, or making some improvements to TuringPosteriorDB, do get in touch.

[penelopeysm]

Turing.jl Newsletter 2 — 14 March 2025

DynamicPPL benchmarking

DynamicPPL.jl now has a set of benchmarks that are run on GitHub Actions! We measure how long it takes to evaluate a small selection of models and also to run AD on them. If you think that there are specific models / features that we should add to the benchmarks, please feel free to create an issue and let us know.

Separately, we are planning to merge the benchmarking utilities in TuringBenchmarking.jl into DynamicPPL itself. There might be a little bit of API shake-up as part of this, but it's for the better as it'll allow the benchmarking code to more easily stay in sync with DynamicPPL — allowing us to catch performance regressions in PRs.

SSMProblems

The SSMProblems.jl and GeneralisedFilters.jl packages have now been merged into a single repository: https://github.com/TuringLang/SSMProblems.jl. This won't affect you if you are using the packages from the Julia General registry, but if you're looking to develop off the main branch you may have to use a different URL, or specify a subdirectory in Pkg.add.

Smaller bits

Other code changes that have been merged:

• Some old code in AdvancedHMC.jl has been cleaned up quite a bit. See the 0.7.0 release for more information.
• Turing's Gibbs sampler now supports warmup steps properly. We're still thinking about how to properly encode the scenario where different sub-samplers have different numbers of warmup steps, if you have any ideas, do get in touch on that PR.
• We are going to formally remove support for Zygote as an AD backend. We don't test it thoroughly in Turing's test suite. You can of course still use Zygote yourself, simply load ADTypes.AutoZygote() — although we can't guarantee that we will fix any bugs that arise.

[penelopeysm]

Turing.jl Newsletter 3 — 28 March 2025

Turing v0.37

We've now released v0.37 of Turing. This includes a lot of new functionality from DynamicPPL 0.35, including the new (simplified) .~ . It also cleans up the list of exported identifiers, and most notably, if you were using things from DynamicPPL, you will now also need to import DynamicPPL (or using).

More generally, it's likely that from now on our releases will involve larger changes because we are aggregating more changes into a single minor version. We are, however, also committed to providing thorough release notes that will help users and library authors upgrade more easily! Release notes will be available on GitHub, and you can see the notes for Turing 0.37 and DynamicPPL 0.35 here. If you have any trouble upgrading, just drop us a note.

AD backend testing

Right now we test a series of DynamicPPL models with several AD backends. It's rather ad-hoc and we are currently drafting a more formal interface for testing AD backends with Turing models. It's still early days but if you are an AD package developer and want to know what this means for integration with Turing, get in touch (easiest way: ping me on Slack) 🙂

Unified interface for optimisation algorithms

There's an ongoing discussion about unifying the interface for MAP/MLE point estimates and variational inference (and potentially even MCMC). If you use more than one of these methods and have thoughts on what you'd like from an interface, we'd be very happy to hear from you!

[penelopeysm]

Turing.jl Newsletter 4 — 11 April 2025

Have you used Turing.jl?

Given that you're reading this, we hope so! We're currently putting together a list of papers and other outputs (e.g. tutorials, presentations, ...) which make use of Turing.jl. We'd love to have more examples, if you have any, please do get in touch (feel free to message me and I can forward it). Thank you!

State of the AD

Over the last few weeks we've been putting together a little project that tabulates the performance of different AD backends on a variety of Turing.jl models, and we're now quite excited to share it: https://turinglang.org/ADTests/ This will hopefully help to answer the perennial question of whether you should stick with good old ForwardDiff, or whether you should try something else. Do note that (as of the time of writing) this table is still in alpha stage and there are a lot of details that have yet to be ironed out 🙂 However, suggestions are always welcome!

JuliaBUGS.jl

The BUGS (Bayesian inference Using Gibbs Sampling) language provides a declarative way to specify complex Bayesian statistical models. For years, implementations like WinBUGS, OpenBUGS, and JAGS have been widely used tools for researchers applying these models. JuliaBUGS.jl is a modern implementation of the BUGS language, aiming for full backwards compatibility with standard BUGS models, while also offering improved interoperability with the Julia ecosystem. (For details and examples of BUGS syntax, check out the JuliaBUGS documentation.)

A recent experimental update introduces significant performance improvements in JuliaBUGS: instead of relying solely on the previous graph-based approach, JuliaBUGS can now directly generate Julia code to compute the model's log-density. This code generation technique can yield >10x speedups compared to the graph-based method. Currently, this provides the most benefit for models with linear or hierarchical structures; support for state space models is planned for a future update.

To use it, run this after compiling your model:

JuliaBUGS.set_evaluation_mode(your_model, JuliaBUGS.UseGeneratedLogDensityFunction())

We would love for you to test out this new functionality! If you have any feedback, please do feel free to open a GitHub issue or discussion.

Even more advanced HMC

Lastly, we have a paper of our own to share on Hamiltonian Monte Carlo methods!

• Xu, K., & Ge, H. (2024). Practical Hamiltonian Monte Carlo on Riemannian Manifolds via Relativity Theory. Forty-First International Conference on Machine Learning. https://openreview.net/pdf?id=Et8Pk97u4u and https://icml.cc/virtual/2024/poster/34558

We will be looking to integrate these methods into Turing.jl in the future.