[
  {
    "objectID": "news/posts/2025-03-14-newsletter-2/index.html",
    "href": "news/posts/2025-03-14-newsletter-2/index.html",
    "title": "Turing.jl Newsletter 2",
    "section": "",
    "text": "DynamicPPL benchmarking\nDynamicPPL.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.\nSeparately, 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.\nSSMProblems\nThe 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.\nSmaller bits\nOther code changes that have been merged:\n\nSome old code in AdvancedHMC.jl has been cleaned up quite a bit. See the 0.7.0 release for more information.\nTuring’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.\nWe 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.\n\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-04-25-newsletter-5/index.html",
    "href": "news/posts/2025-04-25-newsletter-5/index.html",
    "title": "Turing.jl Newsletter 5",
    "section": "",
    "text": "DynamicPPL 0.36\nA 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\n@model function inner()\n    x ~ Normal()\nend\n@model function outer()\n    a = [0.0]\n    a[1] ~ to_submodel(inner())\nend\nIf 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 1st 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 1st element of a. This means that if you are trying to, for example, condition on the variable, you can do:\nouter() | (@varname(a[1].x) => 1.0)\nOn 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:\n@model function inner()\n    x ~ Normal()\nend\n@model function outer()\n    a ~ to_submodel(inner() | (@varname(x) => 1))\nend\nPreviously, 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.\nFor more complete details, please see the release notes.\nTuringBenchmarking.jl\nDynamicPPL 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, which we shared last time round. (Psst — there are more examples now than before!)\nFor more information, see the docstring of DynamicPPL.TestUtils.AD.run_ad in the DynamicPPL docs.\nAs 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.\nAdvancedHMC compatibility with ComponentArrays\nAdvancedHMC 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 to see examples of how they can be used together.\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2026-01-23-newsletter-17/index.html",
    "href": "news/posts/2026-01-23-newsletter-17/index.html",
    "title": "Turing.jl Newsletter 17",
    "section": "",
    "text": "VarNamedTuple\nWe have been working on a really complete overhaul of the internal VarInfo data structure (several thousand lines of code changes). Pretty much the entire thing has been rewritten from scratch. There are still a number of kinks to iron out, but CI is passing, so there is nothing really fundamental blocking it, just more test coverage and handling of edge cases, and checking that it doesn’t break anything in Turing.\nWhat you’ll get out of it:\n\nMore internally consistent indexing behaviour: if you have something like x ~ MvNormal(zeros(2), I) and you condition your model on Dict(@varname(x[1]) => 1.0, @varname(x[2]) => 2.0) it will now behave correctly (previously the conditioning would have no effect). Colons also benefit a lot from this. Essentially, if I’m not wrong, every item in the table in this issue will more or less become true.\nGeneric AbstractArray support: you should be able to use OffsetArrays, DimArrays, etc. and have them ‘just work’ the way you expect them to. For example you should be able to do dimarr[X(1), Y(2)] ~ dist and it should behave just as if you wrote arr[1, 2] ~ dist.\nMuch improved performance on many common operations (see this PR for some benchmarks).\nIf you develop against DynamicPPL, all our VarInfo subtypes are unified now, there’s no longer a distinction between ‘typed’, ‘untyped’, or ‘simple’ VarInfo.\n\nIf you’re interested in a behind-the-scenes look at why and how we did this, there are some docs here (still in progress, but a lot of the basics are covered)! The performance aspects will mostly affect non-HMC/NUTS samplers (since Turing@0.42 / DynamicPPL@0.39, HMC and NUTS almost completely don’t use VarInfo anymore), although the correctness aspects will apply to every Turing model.\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-03-28-newsletter-3/index.html",
    "href": "news/posts/2025-03-28-newsletter-3/index.html",
    "title": "Turing.jl Newsletter 3",
    "section": "",
    "text": "Turing v0.37\nWe’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).\nMore 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.\nAD backend testing\nRight 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 Penny on Slack) 🙂\nUnified interface for optimisation algorithms\nThere’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!\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-12-05-newsletter-16/index.html",
    "href": "news/posts/2025-12-05-newsletter-16/index.html",
    "title": "Turing.jl Newsletter 16",
    "section": "",
    "text": "It’s been a while since the last one; things have been brewing in the background… This newsletter will be the last for 2025; normal service will resume in January. We’d like to wish all of you a happy holiday season!\nTuring v0.42\nA new version of Turing was released yesterday — there is no way we can do justice to the changes in one paragraph so please check out the changelog for full details. Of note are:\n\nThreadsafe evaluation is now opt-in, if you have tilde-statements inside threaded blocks you must now write model = setthreadsafe(model, true). Confused? Don’t worry, there’s a new docs page that fully explains when and why you need this (and when you don’t)\nChanges in DynamicPPL should mean that lots of things are now faster, mostly HMC/NUTS, Prior, and returned / predict. (Personally we also really recommend trying FlexiChains if performance with chains is an issue and your model has lots of vector parameters; there are a growing number of issues on Turing/DynamicPPL where half of the solution is to use FlexiChains)\nMCMCChains now stores the log-joint as chn[:logjoint] rather than chn[:lp] — the latter was really a remnant carried over from the times when Turing didn’t track prior and likelihood separately\nThe VI interface has been changed a fair bit but in return you now have access to a whole host of new VI algorithms including natural gradient VI, batch-and-match, and Wasserstein\nImplementing external samplers for Turing should now be much easier, you should only need to depend on AbstractMCMC and not Turing (see the external sampler docstring and docs page for examples)\nGibbsConditional is back after a long hiatus: the interface is slightly different to before, please see the docstring for usage examples!\n\nDocs\nApart from the threadsafe evaluation page we also did a refresh of Bijectors.jl’s docs including a new page with some examples of how to define your own bijector. And on top of that, on the main TuringLang docs page there are also new shiny links that let you download each docs page as a notebook, or open it as a notebook in Google Colab. Look out for the links in the right sidebar of the page!\nDoodleBUGS\nNow has a refreshed and much slicker UI: check it out @ https://turinglang.org/JuliaBUGS.jl/DoodleBUGS/\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-10-24-newsletter-14/index.html",
    "href": "news/posts/2025-10-24-newsletter-14/index.html",
    "title": "Turing.jl Newsletter 14",
    "section": "",
    "text": "Turing v0.41, DynamicPPL 0.38\nThe big news item this week is that we’ve just released new (twinned) versions of Turing + DynamicPPL! Many of the changes are under the hood: you might see better performance on some functions like predict for example.\nThe main breaking change comes with the initial_params keyword argument: previously this was supplied as a vector (or vector of vectors for multiple chains). The problem with this is that the meaning of this vector depended on DynamicPPL internals, in a way that users shouldn’t be exposed to. Now, it should be an AbstractInitStrategy (or vector thereof). Essentially, instead of saying “what are the parameters are”, you now specify “how do I get parameters”. This will give you more ways to initialise parameters, and also clearer code.\nDocs for the new version are already live! In the meantime, you can read more details in our release notes.\nProductNamedTupleDistribution\n…can (mostly) be used in Turing now! You’ll need to upgrade to v0.41. I say mostly because there is a fairly niche edge case, where product_distribution of Array inside product_distribution of NamedTuple will fail. If you run into this, please feel free to open an issue!\nParticle samplers in Julia 1.12\nParticle samplers were broken by changes in Julia 1.12’s internals. Over the past few months several fixes have been introduced and you should be able to use these again now! You will need to make sure to upgrade Libtask.jl to 0.9.6, which was just released today.\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-07-11-newsletter-10/index.html",
    "href": "news/posts/2025-07-11-newsletter-10/index.html",
    "title": "Turing.jl Newsletter 10",
    "section": "",
    "text": "LKJCholesky\nSampling LKJCholesky with HMC/NUTS has, until now, failed because of numerical instabilities (you’d usually get a DomainError somewhere). Bijectors.jl has gotten a couple of fixes (here and here, just released v0.15.8 today that contains both of these) that should fix this, hopefully once and for all! (There are still some issues with LKJ itself, see this PR. But now with LKJCholesky working there is less need for LKJ :))\nMultiple-chain progress bars\nNot released yet, but you might like to see this PR (and the videos therein!) which, if merged, will provide more detailed progress bars when sampling with MCMCThreads() or MCMCDistributed(). Currently, the default is that for 10 chains or fewer you’ll get one progress bar per chain; above that there’ll just be one overall progress bar, but it’ll update more than once per chain. That’s customisable, and if you think the default should be different feel free to drop a line!\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2022-02-17-gsoc/index.html",
    "href": "news/posts/2022-02-17-gsoc/index.html",
    "title": "Google Summer of Code 2022",
    "section": "",
    "text": "It is another year of the Google Summer of Code time, and we have compiled an updated list of exciting Turing projects! Projects that the Turing team would be interested in working with students on over the summer are listed below. This information is also cross-posted at Julia’s Turing project page.\nIf you are interested in exploring any of these projects or have any questions, please reach out to the listed project mentors. You can find their contact information at turinglang.org/team."
  },
  {
    "objectID": "news/posts/2022-02-17-gsoc/index.html#more-real-world-bayesian-models-in-turing-julia",
    "href": "news/posts/2022-02-17-gsoc/index.html#more-real-world-bayesian-models-in-turing-julia",
    "title": "Google Summer of Code 2022",
    "section": "More real-world Bayesian models in Turing / Julia",
    "text": "More real-world Bayesian models in Turing / Julia\nMentors: Kai Xu, Tor E. Fjelde, Hong Ge\nProject difficulty: Medium\nProject length: 175 hrs or 350 hrs\nDescription: There are many real-world Bayesian models out there, and they deserve a Turing / Julia implementation.\nExamples include but not limited to - Forecasting (Prophet, datasets) - Recommender system (probabilistic matrix factorisation, dataset) - Ranking (TrueSkill, dataset) - Bayesian revenue estimation (example) - Political forecasting model (example) - Topic mining (latent Dirichlet allocation and new variants) - Multiple Annotators/Combining Unreliable Observations (Dawid and Skene, 1979)\nFor each model, we would consider the following tasks as part of a GSoC project: - Correctness test: correctness of the implementation can be tested by doing inference for prior samples, for which we know the ground truth latent variables. - Performance benchmark: this includes (i) time per MCMC step and (ii) time per effective sample; if the model is differentiable, a further break-down of (i) into (i.1) time per forward pass and (i.2) time per gradient pass are needed. - Real-world results: if available, the final step is to apply the model to a real-world dataset; if such an experiment has been done in the literature, consistency of inference results needs to be checked"
  },
  {
    "objectID": "news/posts/2022-02-17-gsoc/index.html#improving-the-integration-between-turing-and-turings-mcmc-inference-packages",
    "href": "news/posts/2022-02-17-gsoc/index.html#improving-the-integration-between-turing-and-turings-mcmc-inference-packages",
    "title": "Google Summer of Code 2022",
    "section": "Improving the integration between Turing and Turing’s MCMC inference packages",
    "text": "Improving the integration between Turing and Turing’s MCMC inference packages\nMentors: Cameron Pfiffer, Mohamed Tarek, David Widmann\nProject difficulty: Easy\nProject length: 175 hrs\nDescription: Turing.jl is based on a set of inference packages maintained by the TuringLang group. This project is about making use of improvements in DynamicPPL to create a generic integration between Turing.jl and the AbstractMCMC.jl sampling API. The ultimate goal is to remove or substantially reduce algorithm-specific glue code inside Turing.jl. The project would also involve improving data structures for storing model parameters in DynamicPPL."
  },
  {
    "objectID": "news/posts/2022-02-17-gsoc/index.html#directed-graphical-model-support-for-the-abstract-probabilistic-programming-library",
    "href": "news/posts/2022-02-17-gsoc/index.html#directed-graphical-model-support-for-the-abstract-probabilistic-programming-library",
    "title": "Google Summer of Code 2022",
    "section": "Directed-graphical model support for the abstract probabilistic programming library",
    "text": "Directed-graphical model support for the abstract probabilistic programming library\nMentors: Philipp Gabler, Hong Ge\nProject difficulty: Hard\nProject length: 350 hrs\nDescription: We want to have a very light-weight representation of probabilistic models of static graphs (similar to BUGS), which can serve as a representation target of other front-end DSLs or be dynamically built. The representation should consist of the model and node representations (stochastic and deterministic, perhaps hyperparameters) and conform to the AbstractPPL model interface, with basic functions (evaluation of density, sampling, conditioning; at later stages some static analysis like extraction of Markov blankets). The model should also contain the state of the variables and implement the AbstractPPL trace interface (dictionary functions, querying of variable names). The result should be able to work with existing sampling packages through the abstract interfaces."
  },
  {
    "objectID": "news/posts/2022-02-17-gsoc/index.html#a-modular-tape-caching-mechanism-for-reversediff",
    "href": "news/posts/2022-02-17-gsoc/index.html#a-modular-tape-caching-mechanism-for-reversediff",
    "title": "Google Summer of Code 2022",
    "section": "A modular tape caching mechanism for ReverseDiff",
    "text": "A modular tape caching mechanism for ReverseDiff\nMentors: Qingliang Zhuo, Mohamed Tarek\nProject difficulty: Medium\nProject length: 175 hrs\nDescription: Tape caching often leads to significant performance improvements for gradient-based sampling algorithms (e.g. HMC/NUTS). Tape caching is only possible at the complete computational level for ReverseDiff at the moment. This project is about implementing a more modular, i.e. function-as-a-caching-barrier, tape caching mechanism for ReverseDiff.jl."
  },
  {
    "objectID": "news/posts/2022-02-17-gsoc/index.html#benchmarking-improving-performance-of-the-juliagaussianprocesses-libraries",
    "href": "news/posts/2022-02-17-gsoc/index.html#benchmarking-improving-performance-of-the-juliagaussianprocesses-libraries",
    "title": "Google Summer of Code 2022",
    "section": "Benchmarking & improving performance of the JuliaGaussianProcesses libraries",
    "text": "Benchmarking & improving performance of the JuliaGaussianProcesses libraries\nMentors: Theo Galy-Fajou, Will Tebbutt, ST John\nProject difficulty: Medium\nProject length: 350 hrs\nDescription: Although KernelFunctions.jl has extensive correctness testing, our performance testing is lacking. This project aims to resolve this, and resolve performance issues wherever they are found. The student would first need to extend our existing benchmarking coverage, and debug any obvious performance problems. The next phase of the work would be to construct end-to-end examples of KernelFunctions being used in practice, profile them to determine where performance problems lie, and fix them."
  },
  {
    "objectID": "news/posts/2022-02-17-gsoc/index.html#iterative-methods-for-inference-in-gaussian-processes",
    "href": "news/posts/2022-02-17-gsoc/index.html#iterative-methods-for-inference-in-gaussian-processes",
    "title": "Google Summer of Code 2022",
    "section": "Iterative methods for inference in Gaussian Processes",
    "text": "Iterative methods for inference in Gaussian Processes\nMentors: Will Tebbutt, S. T. John, Ross Viljoen\nProject difficulty: Medium\nProject length: 175 hrs\nDescription: There has recently been quite a bit of work on inference methods for GPs that use iterative methods rather than the Cholesky factorisation. They look quite promising, but no one has implemented any of these within the Julia GP ecosystem yet, but they should fit nicely within the AbstractGPs framework. If you’re interested in improving the GP ecosystem in Julia, this project might be for you!"
  },
  {
    "objectID": "news/posts/2022-02-17-gsoc/index.html#approximate-inference-methods-for-non-gaussian-likelihoods-in-gaussian-processes",
    "href": "news/posts/2022-02-17-gsoc/index.html#approximate-inference-methods-for-non-gaussian-likelihoods-in-gaussian-processes",
    "title": "Google Summer of Code 2022",
    "section": "Approximate inference methods for non-Gaussian likelihoods in Gaussian Processes",
    "text": "Approximate inference methods for non-Gaussian likelihoods in Gaussian Processes\nMentors: S. T. John, Ross Viljoen, Theo Galy-Fajou\nProject difficulty: Hard\nProject length: 350 hrs\nDescription: Adding approximate inference methods for non-Gaussian likelihoods which are available in other GP packages but not yet within JuliaGPs. The project would start by determining which approximate inference method(s) to implement—there’s lots to do, and we’re happy to work with a student on whichever method they are most interested in, or to suggest one if they have no strong preference."
  },
  {
    "objectID": "news/posts/2022-02-17-gsoc/index.html#gpu-integration-in-the-juliagps-ecosystem",
    "href": "news/posts/2022-02-17-gsoc/index.html#gpu-integration-in-the-juliagps-ecosystem",
    "title": "Google Summer of Code 2022",
    "section": "GPU integration in the JuliaGPs ecosystem",
    "text": "GPU integration in the JuliaGPs ecosystem\nMentors: Ross Viljoen, Theo Galy-Fajou, Will Tebbutt\nProject difficulty: Medium\nProject length: 350 hrs\nDescription: This would involve first ensuring that common models are able to run fully on the GPU, then identifying and improving GPU-specific performance bottlenecks. This would begin by implementing a limited end-to-end example involving a GP with a standard kernel, and profiling it to debug any substantial performance bottlenecks. From there, support for a wider range of the functionality available in KernelFunctions.jl and AbstractGPs.jl can be added. Stretch goal: extension of GPU support to some functionality in ApproximateGPs.jl."
  },
  {
    "objectID": "news/posts/2025-06-06-newsletter-8/index.html",
    "href": "news/posts/2025-06-06-newsletter-8/index.html",
    "title": "Turing.jl Newsletter 8",
    "section": "",
    "text": "The major update this week is the release of Turing.jl v0.39. The biggest change is the update to AdvancedVI 0.4, and corresponding changes in Turing’s VI interface. We’re still working on bringing all the docs up to date, but here’s what you can expect from the new version:\n\nlocation-scale families with dense scale matrices,\nparameter-free stochastic optimization algorithms like DoG and DoWG,\nproximal operators for stable optimization,\nthe sticking-the-landing control variate for faster convergence, and\nthe score gradient estimator for non-differentiable targets.\n\nThere are some other small changes to do with imports and exports. The brief summary is: @addlogprob! is now formally exported. There are a bunch of other, unexported, things where you may need to change from Turing.foo to DynamicPPL.foo – although this probably only applies if you were using DynamicPPL internals. If you have any issues with these please feel free to get in touch.\nApart from this, we have also released AdvancedHMC.jl 0.8! Breaking changes include: - if you are relying the internal transition to make an MCMC transition from phase point z using trajectory τ (or HMCKernel κ) with Hamiltonian h, please note the signature has changed. The usage should now always be transition(h, τ, z) or transition(h, κ, z). - HMC sampling requires appropriate step size for the Leapfrog integration, as the chosen step size directly affects the numerical stability of the integration process. While AdvancedHMC.jl provides find_good_stepsize to find a suitable step size during HMC sampling, it didn’t support manual step size specification, which caused unnecessary searching. Now initial_step_size can be specified as a keyword in find_good_stepsize if you want more control of the step size selection process.\nAnd finally, we have a few new examples of normalising flows in the NormalizingFlows.jl library: https://github.com/TuringLang/NormalizingFlows.jl/tree/main/example\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2020-05-04-Imperial-Report13-analysis/index.html",
    "href": "news/posts/2020-05-04-Imperial-Report13-analysis/index.html",
    "title": "Replication study: Estimating number of infections and impact of NPIs on COVID-19 in European countries (Imperial Report 13)",
    "section": "",
    "text": "The Turing.jl team is currently exploring possibilities in an attempt to help with the ongoing SARS-CoV-2 crisis. As preparation for this and to get our feet wet, we decided to perform a replication study of the Imperial Report 13, which attempts to estimate the real number of infections and impact of non-pharmaceutical interventions on COVID-19. In the report, the inference was performed using the probabilistic programming language (PPL) Stan. We have explicated their model and inference in Turing.jl, a Julia-based PPL. We believe the results and analysis of our study are relevant for the public, and for other researchers who are actively working on epidemiological models. To that end, our implementation and results are available here.\nIn summary, we replicated the Imperial COVID-19 model using Turing.jl. Subsequently, we compared the inference results between Turing and Stan, and our comparison indicates that results are reproducible with two different implementations. In particular, we performed 4 sets of simulations using the Imperial COVID-19 model. The resulting estimates of the expected real number of cases, in contrast to the recorded number of cases, the reproduction number \\(R_t\\), and the expected number of deaths as a function of time and non-pharmaceutical interventions (NPIs) for each Simulation are shown below.\n\n\n\n\n\nSimulation (a): hypothetical Simulation from the model without data (prior predictive) or non-pharmaceutical interventions. Under the prior assumptions of the Imperial Covid-19 model, there is a very wide range of epidemic progressions with expected cases from almost 0 to 100% of the population over time. The black bar corresponds to the date of the last observation. Note that \\(R_t\\) has a different time-range than the other plots; following the original report, this shows the 100 days following the country-specific epidemic_start which is defined to be 31 days prior to the first date of 10 cumulative deaths, while the other plots show the last 60 days.\n\n\n\n\nSimulation (b): future Simulation with non-pharmaceutical interventions kept in place (posterior predictive). After incorporating the observed infection data, we can see a substantially more refined range of epidemic progression. The reproduction rate estimate lies in the range of 3.5-5.6 before any intervention is introduced. The dotted lines correspond to observations, and the black bar corresponds to the date of the last observation.\n\n\n\n\nSimulation (c): future Simulation with non-pharmaceutical interventions removed. Now we see the hypothetical scenarios after incorporating infection data, but with non-pharmaceutical interventions removed. This plot looks similar to Simulation (a), but with a more rapid progression of the pandemic since the estimated reproduction rate is bigger than the prior assumptions. The dotted lines correspond to observations, and the black bar corresponds to the date of the last observation.\n\n\n\n\nSimulation (d): future Simulation with when lockdown is lifted two weeks before the last observation (predictive posterior). As a result there is a clear, rapid rebound of the reproduction rate. Comparing with Simulation (b) we do not observe an immediate increase in the number of expected cases and deaths upon lifting lockdown, but there is a significant difference in the number of cases and deaths in the last few days in the plot: Simulation (d) results in both greater number of cases and deaths, as expected. This demonstrates how the effects of lifting an intervention might not become apparent in the measurable variables, e.g. deaths, until several weeks later. The dotted lines correspond to observations, the black bar corresponds to the date of the last observation, and the red bar indicates when lockdown was lifted.\nOverall, Simulation (a) shows the prior modelling assumptions, and how these prior assumptions determine the predicted number of cases, etc. before seeing any data. Simulation (b) predicts the trend of the number of cases, etc. using estimated parameters and by keeping all the non-pharmaceutical interventions in place. Simulation (c) shows the estimate in the case where none of the intervention measures are ever put in place. Simulation (d) shows the estimates in the case when the lockdown was lifted two weeks prior to the last observation while keeping all the other non-pharmaceutical interventions in place.\nWe want to emphasise that we do not provide additional analysis of the Imperial model yet, nor are we aiming to make any claims about the validity or the implications of the model. Instead we refer to Imperial Report 13 for more details and analysis. The purpose of this post is solely to add validation to the inference performed in the paper by obtaining the same results using a different probabilistic programming language (PPL) and by exploring whether or not Turing.jl can be useful for researchers working on these problems.\nFor our next steps, we’re looking at collaboration with other researchers and further developments of this and similar models. There are some immediate directions to explore:\n\nIncorporation of more sources of data, e.g. national mobility, seasonal changes and behavior changes in individuals.\nHow the assumptions incorporated into the priors and their parameters change resulting posterior.\nThe current model does not directly include recovery as a possibility and assumes that if a person has been infected once then he/she will be infectious until death. Number of recovered cases suffers from the same issues as the number of cases: it cannot be directly observed. But we can also deal with it in a similar manner as is done with number of cases and incorporate this into the model for a potential improvement. This will result in a plethora of different models from which we can select the most realistic one using different model comparison techniques, e.g. leave-one-out cross-validation (loo-cv).\n\nSuch model refinement can be potentially valuable given the high impact of this pandemic and the uncertainty and debates in the potential outcomes.\nAcknowledgement We would like to thank the Julia community for creating such an excellent platform for scientific computing, and for the continuous feedback that we have received. We also thank researchers from Computational and Biological Laboratory at Cambridge University for their feedback on an early version of the post. \n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-09-26-newsletter-12/index.html",
    "href": "news/posts/2025-09-26-newsletter-12/index.html",
    "title": "Turing.jl Newsletter 12",
    "section": "",
    "text": "After a bit of an absence (Penny has been busy / away) the newsletter is back…\nJuliaCon Local Paris 2025\nMarkus and Penny will be in Paris next week for JuliaCon! We have a poster on Friday morning about all the latest developments in Turing.jl, so please feel free to come and say hi and chat about anything :)\nGoogle Summer of Code projects\nWe have recently wrapped up our two GSoc projects and the reports are available to read. There is Mateus Maia’s work on RJuliaBUGS – as the name suggests this is an R interface to JuliaBUGS.jl; and also Shravan Goswami’s DoodleBUGS – a web frontend for creating and editing BUGS models (you can also try it out here!).\nCore updates\nOur refactoring of DynamicPPL internals continues: DynamicPPL v0.37 / Turing v0.40 was quite a major release (for us!) and in particular overhauls the way that log-probabilities are tracked when evaluating a model. For the regular Turing.jl user you will hopefully find quite little difference, but one bonus is that in MCMC sampling log-probabilities are now correctly tracked in the returned chain: you can access chn[:lp] for the log-joint, but also chn[:logprior] and chn[:loglikelihood]. All of these probabilities are also consistently returned in the “unlinked space”, i.e., they don’t include any Jacobian terms obtained from transforming constrained distributions (these terms are an implementation detail and shouldn’t be ‘leaked’ to the user). Previously only chn[:lp] was provided and the meaning of that varied from sampler to sampler.\nMooncake forward-mode\nMooncake.jl now has a new forwards-mode AD system which you can use with AutoMooncakeForward(). It should work with almost all Turing models and our ADTests website has benchmarks (reverse mode is still faster for most things!)\nDocs\nThere are some new additions to the Turing docs including a list of FAQs, as well as a more thorough page on submodels and how to use one of Turing’s most unique features. If you have particular requests for documentation please do let us know as we’ll be attempting to spend some consistent time working on the docs.\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2019-12-14-initial-post/index.html",
    "href": "news/posts/2019-12-14-initial-post/index.html",
    "title": "Turing’s Blog",
    "section": "",
    "text": "All good open source projects should have a blog, and Turing is one such project. Later on, members of the Turing team may be populating this feed with posts on topics like\n\nInteresting things you can do with Turing, or interesting things we have seen others do.\nDevelopment updates and major release announcements.\nResearch updates.\nExplorations of Turing’s internals.\nUpdates to Turing’s satellite projects AdvancedHMC.jl or Bijectors.jl.\n\nStay tuned!\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2021-02-04-gsoc/index.html",
    "href": "news/posts/2021-02-04-gsoc/index.html",
    "title": "Google Summer of Code 2021",
    "section": "",
    "text": "It’s about time for us to start thinking about projects we’d like to see at Turing.jl for the Google Summer of Code 2021! Below is a list of projects the Turing team would be interested in working with students on for the summer.\nIf you are interested in exploring any of these projects, please reach out to the listed project mentors. You can find their contact information at turinglang.org/team.\n\nMCMCChains improvements\nMentors: Cameron Pfiffer, Hong Ge\nProject difficulty: Easy\nDescription: MCMCChains is a key component of the Turing.jl ecosystem. It is the package that determines how to analyze and store MCMC samples provided by packages like Turing. It’s also used outside of Turing.\nFor this project, a student might improve the performance of the various statistical functions provided by MCMCChains, changing the back end to use a data storage format that maintains the shape of parameter samples, or improve the general plotting functionality of the package.\nThere’s lots of fun little things to do for MCMCChains. Check out this meta-issue for more details and discussions.\n\n\nParticle filtering methods\nMentors: Hong Ge, Cameron Pfiffer\nProject difficulty: Medium\nDescription: Turing’s support for particle sampling methods is slowing being improved with the addition of AdvancedPS.jl. If you’re interested in implementing or improving particle sampling methods, this is a great project for you!\n\n\nNested Sampling\nMentors: Miles Lucas, Cameron Pfiffer, Hong Ge\nProject difficulty: Hard\nDescription: NestedSamplers.jl is an excellent package which implements nested sampling methods. As of yet, it is not connected to Turing.jl. For this project, a student would connect the NestedSamplers.jl library to Turing.jl.\n\n\nGPU acceleration\nMentors: Mohamed Tarek, Hong Ge, Kai Xu, Tor Fjelde\nProject difficulty: Medium\nDescription: Turing’s native GPU support is limited in that the Metropolis-Hastings and HMC samplers do not implement GPU sampling methods. This can and should be done – GPU methods are awesome! If you are interested with working on parallelism and GPUs, this project is for you.\nStudents will work with the code at AdvancedMH or AdvancedHMC, depending on their interests.\n\n\nDocumentation and tutorial improvements\nMentors: Cameron Pfiffer, Martin Trapp\nProject difficulty: Easy\nDescription: Turing’s documentation and tutorials need a bit of an overhaul. Turing has changed significantly since the last time the documentation was written, and it’s beginning to show. Students would use their knowledge of probabilistic programming languages and Turing to shore-up or rewrite documentation and tutorials.\n\n\nIterative Methods for Inference in Gaussian Processes\nMentors: Will Tebbutt, S. T. John, Theo Galy-Fajou\nProject difficulty: Medium\nDescription: There has recently been quite a bit of work on inference methods for GPs that use iterative methods rather than the Cholesky factorisation. They look quite promising, but no one has implemented any of these within the Julia GP ecosystem yet, but they should fit nicely within the AbstractGPs framework. If you’re interested in improving the GP ecosystem in Julia, this project might be for you!\n\n\nImplement advanced variational Gaussian process models\nMentors: ST John, Will Tebbutt, Theo Galy-Fajou\nProject difficulty: Easy to Medium\nDescription: Sparse variational Gaussian process models provide the flexibility to scale to large datasets, handle arbitrary (non-conjugate) likelihoods, and to be used as building blocks for composite models such as deep GPs. This project is about making such models more readily available within the Julia GP ecosystem - depending on your interests you can focus on making it easier for end users and providing good tutorials, or on the implementations of these models to give us the same or better performance as with established Python packages such as GPflow, integrating with Flux.jl, etc.\n\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-05-09-newsletter-6/index.html",
    "href": "news/posts/2025-05-09-newsletter-6/index.html",
    "title": "Turing.jl Newsletter 6",
    "section": "",
    "text": "Turing v0.38 has just been released and incorporates the changes from DynamicPPL which were mentioned in the last newsletter. It also contains a fix for the Gibbs sampler, so that you can now specify arbitrary VarNames for each sampler (previously, you could only specify single-symbol VarNames). For example, you can now specify the a.x and b.x VarNames here:\n@model function inner()\n    x ~ Normal()\nend\n@model function outer()\n    a ~ to_submodel(inner())\n    b ~ to_submodel(inner())\nend\nsample(outer(), Gibbs(@varname(a.x) => MH(), @varname(b.x) => MH()), 100)\nIt is theoretically possible that this will be slow for VarNames that involve indexing (e.g. x[1]), although we don’t have an example of this yet. If you find anything you think should be faster, let us know.\nOne other minor point: on ADTests you can now hover over a model name to see its definition.\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "",
    "text": "BUGS (Bayesian Inference Using Gibbs Sampling) is a probabilistic programming language for Bayesian models, and JuliaBUGS is its modern implementation in Julia. DoodleBUGS is a browser-based graphical interface for JuliaBUGS, allowing users to draw probabilistic graphical models and generate BUGS code.\nImplemented: visual editor (nodes, edges, nested plates), legacy BUGS code generation that compiles with JuliaBUGS [1], [2], local execution via a Julia backend, unified standalone script generation (frontend), timeouts, multiple layouts, and extensive cleanup/typing.\nChanged from proposal: frontend implemented in Vue 3 (instead of React); backend simplified (frontend is the single source of truth for standalone scripts).\nStatus: Working application. Try it here (static UI): https://turinglang.org/JuliaBUGS.jl/DoodleBUGS/. For local inference, run the backend server."
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#tldr",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#tldr",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "",
    "text": "BUGS (Bayesian Inference Using Gibbs Sampling) is a probabilistic programming language for Bayesian models, and JuliaBUGS is its modern implementation in Julia. DoodleBUGS is a browser-based graphical interface for JuliaBUGS, allowing users to draw probabilistic graphical models and generate BUGS code.\nImplemented: visual editor (nodes, edges, nested plates), legacy BUGS code generation that compiles with JuliaBUGS [1], [2], local execution via a Julia backend, unified standalone script generation (frontend), timeouts, multiple layouts, and extensive cleanup/typing.\nChanged from proposal: frontend implemented in Vue 3 (instead of React); backend simplified (frontend is the single source of truth for standalone scripts).\nStatus: Working application. Try it here (static UI): https://turinglang.org/JuliaBUGS.jl/DoodleBUGS/. For local inference, run the backend server."
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#doodlebugs-ui",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#doodlebugs-ui",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "DoodleBUGS UI",
    "text": "DoodleBUGS UI\n\n\n\nDoodleBUGS UI"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#doodlebugs-project-structure",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#doodlebugs-project-structure",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "DoodleBUGS Project Structure",
    "text": "DoodleBUGS Project Structure\n\n\nDirectory Structure\n\nDoodleBUGS/                # Vite + Vue 3 app (UI editor)\n├── README.md              # project documentation\n├── public/                # static assets served by Vite\n│   └── examples/          # example projects\n├── experiments/           # prototypes and exploratory work\n├── runtime/               # Julia HTTP backend (API endpoints & dependencies)\n├── src/                   # application source\n│   ├── assets/            # styles and static assets\n│   ├── components/        # Vue components composing the UI\n│   │   ├── canvas/        # graph canvas and toolbars\n│   │   ├── common/        # shared UI primitives\n│   │   ├── layouts/       # app layout and modals\n│   │   │   └── MainLayout.vue   # main application layout\n│   │   ├── left-sidebar/  # palette, project manager, execution settings\n│   │   ├── panels/        # code preview and data input panels\n│   │   ├── right-sidebar/ # execution, JSON editor, node properties\n│   │   └── ui/            # base UI elements (buttons, inputs, selects)\n│   ├── composables/       # reusable logic (codegen, drag & drop, graph, validator, grid)\n│   ├── config/            # configuration and node definitions\n│   ├── stores/            # Pinia state stores (graph, data, execution, project, UI)\n│   └── types/             # TypeScript types and ambient declarations\n├── tmp/                   # local temporary outputs (ignored in builds)\n└── ztest/                 # scratch/test artifacts"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#motivation",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#motivation",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Motivation",
    "text": "Motivation\nJuliaBUGS is a modern Julia implementation of the BUGS language [2], [3], [4]. DoodleBUGS revives the original visual modelling concept with a modern browser-based stack so users can:\n\nConstruct probabilistic graphical models visually (nodes, edges, plates).\nExport readable legacy BUGS code that compiles with JuliaBUGS [1], [2], [3].\nRun inference and inspect results from the UI. Common BUGS applications include parallel MCMC [5], survival analysis [6], and Gibbs-style samplers [7], [8]."
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#what-was-built",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#what-was-built",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "What Was Built",
    "text": "What Was Built\n\nVisual editor\n\nNode types: stochastic, observed, deterministic\nPlates with arbitrary nesting; robust drag-in/out and creation inside plates\nGraph layouts: Dagre (default), fCoSE (Force-Directed), Cola (Physics Simulation), KLay (Layered); stable interactions\n\nLegacy BUGS code generation [2], [3]\n\nTopological ordering and plate-aware traversal\nParameter formatting and safe index expansion\nImplemented in DoodleBUGS/src/composables/useBugsCodeGenerator.ts\n\nExecution flow\n\nFrontend POSTs to /api/run with body: model_code (BUGS), data and inits (JSON), data_string and inits_string (Julia NamedTuple literals), and settings { n_samples, n_adapts, n_chains, seed, timeout_s }. If /api/run returns 404, it falls back to /api/run_model.\nBackend creates a temp dir, writes model.bugs and payload.json, generates an ephemeral run_script.jl, compiles with JuliaBUGS.@bugs, wraps with ADgradient(:ReverseDiff), and samples via AdvancedHMC.NUTS through AbstractMCMC (Threads or Serial). It writes summaries (incl. ESS, R-hat) and quantiles to JSON and returns { success, summary, quantiles, logs, files[] }, where files includes model.bugs, payload.json, run_script.jl, and results.json.\nFrontend also generates a standalone.jl script locally (mirrors backend execution) and shows it alongside the backend files; the backend does not attach a standalone script.\n\nTimeouts/resilience\n\nConfigurable timeout (frontend); enforced in backend worker\nSafe temp directory cleanup on Windows with retries\n\nCleanup/typing\n\nStrong, project-wide TypeScript typing across stores, components, and composables\nRemoval of unused backend code; consistent naming and logs"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#architecture-overview",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#architecture-overview",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Architecture Overview",
    "text": "Architecture Overview\n\nFrontend: Vue 3, Pinia, Cytoscape.js [9], CodeMirror\n\nCode generation: DoodleBUGS/src/composables/useBugsCodeGenerator.ts\nExecution panel: DoodleBUGS/src/components/right-sidebar/ExecutionPanel.vue\n\nBackend (Julia) HTTP server\n\nServer: DoodleBUGS/runtime/server.jl\nProject deps: DoodleBUGS/runtime/Project.toml (HTTP, JSON3, JuliaBUGS, AbstractMCMC, AdvancedHMC, ReverseDiff, MCMCChains, DataFrames, StatsBase, Statistics)\nEndpoints: GET /api/health; POST /api/run and /api/run_model\nExecution: creates temp dir, writes model.bugs and payload.json, generates run_script.jl, enforces optional timeout"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#design-principles-and-architecture",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#design-principles-and-architecture",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Design Principles and Architecture",
    "text": "Design Principles and Architecture\nDesign principles\n\nVisual-first modeling with deterministic export to legacy BUGS [2], [3].\nSeparation of concerns: editing (graph), generation (BUGS), execution (backend), and results (summary/quantiles) are modular.\nDeterministic ordering: topological sort + plate-aware traversal ensures readable, stable code output.\nRobustness: cancellable frontend fetch, backend-enforced timeout, and resilient temp cleanup on Windows (safe_rmdir()).\n\nFrontend architecture (Vue 3 + Cytoscape.js)\n\nCore graph state is managed in Vue; Cytoscape.js handles layout, hit-testing, and interaction semantics (including compound nodes for plates) [9].\nCode generation lives in DoodleBUGS/src/composables/useBugsCodeGenerator.ts and maps GraphNode/GraphEdge to BUGS:\n\nKahn topological sort for definition order\nPlate-aware recursion for for (...) { ... } blocks\nParameter canonicalization (indices, numeric/expr passthrough)\n\nStandalone Julia script generation uses generateStandaloneScript() in the same composable, mirroring backend execution.\n\nBackend architecture (Julia)\n\nrun_model_handler() in DoodleBUGS/runtime/server.jl materializes model.bugs, payload.json, and a transient run_script.jl that:\n\nBuilds NamedTuples from JSON or string-literal data/inits\nCompiles via JuliaBUGS.@bugs, wraps with ADgradient(:ReverseDiff) [10]\nSamples with AdvancedHMC.NUTS through AbstractMCMC (Threads or Serial) [11], [12], [13]\nEmits summaries (incl. ESS and R-hat) via MCMCChains/DataFrames and quantiles to JSON [14], [15]\nTimeout: worker process is killed if exceeding timeout_s.\nCleanup: safe_rmdir() retries with GC to avoid EBUSY on Windows."
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#why-vue-not-react",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#why-vue-not-react",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Why Vue (not React)?",
    "text": "Why Vue (not React)?\nThe proposal planned React; we chose Vue 3 after evaluating the graph layer and developer velocity for this app.\n\nTried Konva (canvas) for custom graph editing: powerful drawing primitives, but required bespoke graph semantics (hit testing, edge routing, compound nodes) that Cytoscape.js provides out of the box.\nTried D3 force/layouts: flexible, but compound nodes (plates), nesting, and drag constraints became a significant amount of custom code to maintain.\nCytoscape.js offered:\n\nNative graph model with compound nodes (great for plates)\nIntegrated layouts (Dagre, fCoSE, Cola, KLay) and rich interaction APIs [16], [17]\nMature ecosystem and performance characteristics for medium-sized graphs\n\nVue 3 (vs React) for this project:\n\nComposition API made integrating an imperative graph library (Cytoscape) straightforward via composables and lifecycle hooks\nSFC ergonomics and Pinia stores enabled quick iteration with strong TypeScript support\nTemplate reactivity + refs reduced reconciliation overhead when bridging to Cytoscape’s imperative API\nMinimal glue code for state management (Pinia) vs setting up reducers/selectors; enabled rapid iteration\nVite + Vue tooling yielded fast HMR for UI-heavy iterations\n\nDesign inspirations: draw.io for interaction affordances; Stan Playground for model/run UX [18], [19]."
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#comparison-to-legacy-doodlebugs",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#comparison-to-legacy-doodlebugs",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Comparison to Legacy DoodleBUGS",
    "text": "Comparison to Legacy DoodleBUGS\nThe legacy tool was a windows desktop application driving WinBUGS [20]; the new DoodleBUGS is a browser-based editor targeting JuliaBUGS [1].\n\n\n\nLegacy DoodleBUGS\n\n\n\n\n\nNew DoodleBUGS\n\n\nKey differences:\n\nPlatform and backend\n\nLegacy: Desktop UI, WinBUGS execution pipeline\nNew: Web UI, Julia backend via JuliaBUGS.@bugs, sampling with AdvancedHMC.NUTS through AbstractMCMC\n\nGraph engine and plates\n\nLegacy: Bespoke graph handling with limited nesting semantics\nNew: Cytoscape.js with compound nodes for robust nested plates; custom drag-and-drop for drag-in/out and creating inside plates\n\nLayouts and interactions\n\nLegacy: Limited auto-layout support\nNew: Multiple layout engines (Dagre, fCoSE, Cola, KLay) and stable interactions; positions updated after layoutstop [16], [17]\n\nCode generation\n\nLegacy: Export to BUGS without strong ordering guarantees\nNew: Deterministic topological + plate-aware traversal; parameter canonicalization and safe index expansion\n\nExecution and tooling\n\nLegacy: WinBUGS-managed runs\nNew: Lightweight Julia HTTP backend, configurable timeouts, resilient temp cleanup, JSON summaries via MCMCChains\n\nDevX and maintainability\n\nNew: Vue 3 + TypeScript + Pinia; unified standalone script generation on the frontend; leaner backend responses"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#progress-vs-proposal",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#progress-vs-proposal",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Progress vs Proposal",
    "text": "Progress vs Proposal\n\nImplemented\n\nVisual editor with nested plates and robust drag-and-drop\nBUGS code generator (topological + plate-aware)\nLocal execution + summaries/quantiles\nUnified standalone script generation (frontend)\nTimeouts/resilience\nMultiple layouts and interactions\nExtensive cleanup/typing\nExecution timeout (end-to-end)\nLayout options (Dagre (default, layered), fCoSE (force-directed), Cola (physics simulation), KLay (layered)) and interactions\nCleanup and stronger typing\n\nChanged\n\nVue 3 instead of React\nBackend responses smaller; no standalone script attachment\n\nDeferred/Partial\n\nVisualizations: integrate with MCMCChains.jl for plots (trace, density, PPC, diagnostics). ESS and R-hat already included in summary statistics.\nWebKit/Safari support\nUX polish for large graphs"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#how-to-run-locally",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#how-to-run-locally",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "How to Run Locally",
    "text": "How to Run Locally\nFrontend (Vite):\n# from repo root\ncd DoodleBUGS\nnpm install\nnpm run dev\nBackend (Julia):\n# from repo root\njulia --project=DoodleBUGS/runtime DoodleBUGS/runtime/server.jl\n# server listens on http://localhost:8081\nNotes:\n\nCORS is enabled in the backend so the dev UI can call http://localhost:8081.\nTry it here (static UI): https://turinglang.org/JuliaBUGS.jl/DoodleBUGS/"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#api-summary-for-backend-server",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#api-summary-for-backend-server",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "API Summary for Backend Server",
    "text": "API Summary for Backend Server\n\nGET /api/health → { \"status\": \"ok\" }\nPOST /api/run (alias: /api/run_model)\n\nBody: model_code, data (JSON), inits (JSON), data_string (Julia literal), inits_string (Julia literal), settings { n_samples, n_adapts, n_chains, seed, timeout_s }\nResponse: { success, summary, quantiles, logs, files[] } where files[] contains model.bugs, payload.json, run_script.jl, results.json\nNote: Frontend falls back to /api/run_model if /api/run is unavailable (404)\n\n\nSee DoodleBUGS/runtime/server.jl."
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#current-limitations",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#current-limitations",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Current Limitations",
    "text": "Current Limitations\n\nWebKit/Safari/iOS: unsupported at this time (see DoodleBUGS/README.md).\nLimited visualization beyond summary/quantiles.\nOverlapped plates (nodes with multiple parent plates) are currently not supported; see #362."
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#future-work",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#future-work",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Future Work",
    "text": "Future Work\n\nBackend: Add Pluto.jl as a backend for supporting compound documents and QuartoNotebookRunner.jl for running notebooks.\nDiagnostics/visualization: integrate with MCMCChains.jl for plots (trace, density, PPC, diagnostics). ESS and R-hat already available in summary stats.\nUX: richer node templates, validation, distribution hints\nSharing: shareable links/cloud sync (projects already persisted locally)\nBrowser compatibility: WebKit/Safari and iOS/iPadOS\nPerformance: virtualization for large graphs"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#acknowledgements",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#acknowledgements",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Acknowledgements",
    "text": "Acknowledgements\nMuch appreciation goes to my mentors Xianda Sun and Hong Ge. The work is impossible without your help and support.\n\nMentors: Xianda Sun (@sunxd3) and Hong Ge (@yebai)\nTuringLang/JuliaBUGS community and contributors"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#appendix-project-links",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#appendix-project-links",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "Appendix: Project Links",
    "text": "Appendix: Project Links\n\nRepo: https://github.com/TuringLang/JuliaBUGS.jl\nTry it here: https://turinglang.org/JuliaBUGS.jl/DoodleBUGS/"
  },
  {
    "objectID": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#prs-during-gsoc",
    "href": "news/posts/2025-09-01-GSoC-Report-DoodleBUGS/index.html#prs-during-gsoc",
    "title": "GSoC Report for DoodleBUGS: a Browser-Based Graphical Interface for Drawing Probabilistic Graphical Models",
    "section": "PRs during GSoC",
    "text": "PRs during GSoC\n\n#321 - Add ISSUE template for DoodleBUGS\n#339 - DoodleBUGS Project: Phase 1\n#340 - DoodleBUGS: update all workflows to run on relevent project only\n#341 - Exclude navigation bar from DoodleBUGS project\n#347 - DoodleBUGS: Basic Code Generation, Advanced Exports, and State Persistence\n#357 - DoodleBUGS: Allow Nested Plates, add new layouts and fix lot of linting issues\n#368 - New Folder Structure\n#388 - DoodleBUGS Project: Phase 2 (Backend)"
  },
  {
    "objectID": "news/posts/2025-07-25-newsletter-11/index.html",
    "href": "news/posts/2025-07-25-newsletter-11/index.html",
    "title": "Turing.jl Newsletter 11",
    "section": "",
    "text": "Libtask and Turing.jl\nThe new versions of Libtask and AdvancedPS have now been integrated into Turing.jl proper. You shouldn’t see any changes, except that particle MCMC methods will now run a lot faster!\n(Do note that these won’t work on Julia 1.12 just yet as it is somewhat tightly coupled to Julia internals; we’re working on a fix but if you really want to use Turing on 1.12 right now you will have to stick to Turing ≤ 0.39.6.)\nProgress bars\nAbstractMCMC 5.7 is released with the new progress bars! By default you get a single progress bar (but with more frequent updates). You need to opt-in to per-chain progress bars with sample(...; progress=:perchain)\nADTests categories\nThe list of models has been split up into different sections to make it a bit easier to read. I’m keen to add more examples of integrations with other packages — if you have a Turing model that uses functionality from a different package inside it, please do get in touch with an example! (I’ll be adding things like DifferentialEquations, HiddenMarkovModels, and AbstractGPs soon, since those are already in our docs)\nCommunity meetings\nThe Turing.jl developer team usually meet once every week; we’re thinking of opening some of these meetings to be public (perhaps once a month) and would like to gauge whether there’s any interest in this. Our current thinking is that these meetings would be something along the lines of:\n\n3 guests with 1 topic each, 10 minutes each: these would be user-submitted and could really be anything you wanted to talk about, e.g. how to write a model, what samplers to use, … And basic stuff is totally fine as that means more people get to learn how to do Bayesian modelling :)\n10 minutes from us on “where Turing is going”\n20 minutes free Q&A\n\nIf you would be interested in attending such a meeting or bringing along a topic, do let us know on Slack!\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2020-09-11-gsoc/index.html",
    "href": "news/posts/2020-09-11-gsoc/index.html",
    "title": "Google Summer of Code 2020",
    "section": "",
    "text": "As the 2020 Google Summer of Code comes to a close, the Turing team thought it would be a good opportunity to reflect on the work that was done by our superb students this summer.\nSaranjeet Kaur’s project focused primarily on expanding NestedSamplers.jl. NestedSamplers.jl now supports PolyChord-style nested sampling natively, which is an absolute delight. Saranjeet wrote about this here. She also provided a good tutorial on how to use NestedSamplers.jl here. The NestedSamplers.jl integration with Turing is still on-going – integrating new samplers with Turing is one of the more difficult tasks. If you are interested to see the progress on this, check out the relevant pull request.\nArthur Lui’s project was to provide a much-needed set of benchmarks of Bayesian nonparametric models between Turing and other PPLs. Arthur’s work spawned a GitHub repository with good practices for benchmarking, as well as three blog posts with some (very cool!) statistics on Turing’s performance:\n\nDirichlet Process Gaussian mixture model via the stick-breaking construction in various PPLs\nGaussian Process Regression Model in various PPLs\nGaussian Process Classification Model in various PPLs\n\nFinally, Sharan Yalburgi (a returning GSoC student) completed an epic amount of work Turing’s growing suite of Gaussian process tools. In particular, the GitHub organization JuliaGaussianProcesses was founded, and serves as an effort to build a robust Gaussian process framework for the Julia ecosystem. The framework consists of multiple GP related Julia packages:\n\nKernelFunctions.jl provides kernel functions for GPs as well as efficient AD for these kernels. KernelFunctions.jl also supports multi-output GPs by providing necessary data abstractions and multi-output kernels.\nAbstractGPs.jl defines GP abstractions and provides exact posteriors. It provides support for induced points based GP posteriors and for efficient sequential/online (sparse) GP updates.\nGPLikelihoods.jl defines alternate likelihoods for Non-Gaussian GPs.\nGPMLj.jl provides a Julia interface for GPFlow, a GP library written in Python using TensorFlow.\n\nSpecial thanks to our three GSoC students for this summer, who all did excellent work. Additional thanks to Google for supporting open source software development and the Julia language!\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-11-07-newsletter-15/index.html",
    "href": "news/posts/2025-11-07-newsletter-15/index.html",
    "title": "Turing.jl Newsletter 15",
    "section": "",
    "text": "Faster model evaluation\nThis PR makes Turing faster by about 2-10x depending on the size of the model. (Not kidding, see the PR for examples!) Smaller models benefit the most, larger models less so because for those a larger proportion of your time is spent just calculating logpdf.\nThe main impact is probably in inference. The PR contains an example where NUTS sampling on eight-schools is cut from ~ 8 seconds to ~ 1.5 seconds. The general strategy should lead to speedups for other operations as well such as returned and predict, although those will be less marked as reading from / constructing a chain will be the main bottlenecks.\nIt’s not released yet, but should hopefully be in the near future!\nMooncake @ 1.12\nJust a note to say that there is now a newly released version of Mooncake that works on 1.12, and Turing should be perfectly compatible with it!\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-10-10-newsletter-13/index.html",
    "href": "news/posts/2025-10-10-newsletter-13/index.html",
    "title": "Turing.jl Newsletter 13",
    "section": "",
    "text": "Julia 1.12\nWith the release of 1.12 comes some very nice things and some broken things. Particle samplers (SMC and PG) currently do not work on 1.12, and Enzyme and Mooncake will both not run. Fixes are being worked on, but it may well take until 1.12.1 before everything is in order. If you use any of the above three, you may want to stay with 1.11 for now.\nJuliaCon\nWe were at JuliaCon Paris last week (thanks to the organising team for a wonderful conference)! If you didn’t get the chance to say hi, feel free to take a look at the poster we did here on GitHub. It very briefly summarises what we’ve been up to in the last few months, what our current priorities are, and what’s likely to come in the future.\nMCMCChains plots + stats\nIn the past few months there have been a number of new plot types added to MCMCChains. You can see examples of energy plots, violin plots, and posterior predictive plots in the docs. Also, you can now use MCMCDiagnosticTools.bfmi(::Chains) to calculate the Bayesian fraction of missing information.\nDocs\nThere’s a new page explaining in more detail all the options you can use when sampling: https://turinglang.org/docs/usage/sampling-options/, suggestions for additions are always welcome!\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-06-20-newsletter-9/index.html",
    "href": "news/posts/2025-06-20-newsletter-9/index.html",
    "title": "Turing.jl Newsletter 9",
    "section": "",
    "text": "Google Summer of Code\nWe will have two GSoC students this year working with us: their projects are both focused on JuliaBUGS.jl, one on developing a graphical interface in a web browser, and another on an R interface. We (re?-)welcome Mateus and Shravan — if you see them around do say hi 🙂\nTuringGLM.jl\nWe’ve been thinking about putting in some work on TuringGLM.jl, which allows one to create Turing models using formula syntax (similar to that in brms, lme4 or bambi). There are (as always) plenty of things for us to work through, but if you’ve used this and would like to let us know about what you’d like to see in it, feel free to message or open an issue on the repository!\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-04-11-newsletter-4/index.html",
    "href": "news/posts/2025-04-11-newsletter-4/index.html",
    "title": "Turing.jl Newsletter 4",
    "section": "",
    "text": "Have you used Turing.jl?\nGiven 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!\nState of the AD\nOver 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 :slightly_smiling_face: However, suggestions are always welcome!\nJuliaBUGS.jl\nThe 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.)\nA 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.\nTo use it, run this after compiling your model:\nJuliaBUGS.set_evaluation_mode(your_model, JuliaBUGS.UseGeneratedLogDensityFunction())\nWe 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.\nEven more advanced HMC\nLastly, we have a paper of our own to share on Hamiltonian Monte Carlo methods!\n\nXu, 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\n\nWe will be looking to integrate these methods into Turing.jl in the future.\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2020-02-12-jsoc/index.html",
    "href": "news/posts/2020-02-12-jsoc/index.html",
    "title": "Google Summer of Code/Julia Summer of Code",
    "section": "",
    "text": "Last year, Turing participated in the Google Summer of Code (GSoC) through the Julia language organization. It was a fun time, and the project was better for it. Turing plans to participate in the upcoming GSoC, and we wanted to outline some potential projects and expectations we have for applicants.\nIf you are not aware, Google provides funds to students around the world to develop a project of their choice over the summer. Students receive funds from Google and spend three months on any open source project.\nThe Turing development team has prepared a list of possible projects that we have deemed valuable to the project and easy enough that it could feasibly be created in the three-month limit. This list is not exclusive – if you have a good idea, you can write it up in your proposal, though it is recommend that you reach out to any of the Turing team on Julia’s Slack (you can get an invite here) or Discourse. Messages on Discourse should be posted to the “Probabilistic programming” category – we’ll find you!\nPossible project ideas:\n\nBenchmarking. Turing’s performance has been sporadically benchmarked against various other probabilistic programming languages (e.g. Turing, Stan, PyMC3, TensorFlow Prob), but a systemic approach to studying where Turing excels and where it falls short would be useful. A GSoC student would implement identical models in many PPLs and build tools to benchmark all PPLs against one another.\nNested sampling integration. Turing focuses on modularity in inference methods, and the development team would like to see more inference methods, particularly the popular nested sampling method. A Julia package (NestedSamplers.jl) but it is not hooked up to Turing and does not currently have a stable API. A GSoC student would either integrate that package or construct their own nested sampling method and build it into Turing.\nAutomated function memoization by model annotation. Function memoization is a way to reduce costly function evaluation by caching the output when the same inputs are given. Turing’s Gibbs sampler often ends up rerunning expensive functions multiple times, and it would be a significant performance improvement to allow Turing’s model compiler to automatically memoize functions where appropriate. A student working on this project would become intimately familiar with Turing’s model compiler and build in various automated improvements.\nMaking Distributions GPU compatible. Julia’s GPU tooling is generally quite good, but currently Turing is not able to reliably use GPUs while sampling because Distributions.jl is not GPU compatible. A student on this project would work with the Turing developers and the Distributions developers to allow the use of GPU parallelism where possible in Turing.\nStatic distributions. Small, fixed-size vectors and matrices are fairly common in Turing models. This means that sampling in Turing can probably benefit from using statically sized vectors and matrices from StaticArrays.jl instead of the dynamic normal Julia arrays. Beside the often superior performance of small static vectors and matrices, static arrays are also automatically compatible with the GPU stack in Julia. Currently, the main obstacle to using StaticArrays.jl is that distributions in Distributions.jl are not compatible with StaticArrays. A GSoC student would adapt the multivariate and matrix-variate distributions as well as the univariate distribution with vector parameters in Distributions.jl to make a spin-off package called StaticDistributions.jl. The student would then benchmark StaticDistributions.jl against Distributions.jl and showcase an example of using StaticDistributions.jl together with CuArrays.jl and/or CUDAnative.jl for GPU-acceleration.\nGPnet extensions. One of Turing’s satellite packages, GPnet, is designed to provide a comprehensive suite of Gaussian process tools. See this issue for potential tasks – there’s a lot of interesting stuff going on with GPs, and this task in particular may have some creative freedom to it.\nBetter chains and model diagnostics. One package that Turing (and many others) rely on heavily is MCMCChains.jl, a package designed to format, store, and analyze parameter samples generated during MCMC inference. MCMCChains is currently showing its age a little and has many bad design choices that need to be fixed. Alternatively, a student could construct a far more lightweight chain system.\nModel comparison tools. Turing and its satellite packages do not currently provide a comprehensive suite of model comparison tools, a critical tool for the applied statistician. A student who worked on this project would implement various model comparison tools like LOO and WAIC, among others.\nMLE/MAP tools. Maximum likelihood estimates (MLE) and maximum a posteriori (MAP) estimates can currently only be done by users through a clunky set of workarounds. A streamlined function like mle(model) or map(model) would be very useful for many of Turing’s users who want to see what the MLE or MAP estimates look like, and it may be valuable to allow for functionality that allows MCMC sampling to begin from the MLE or MAP estimates. Students working on this project will work with optimization packages such as Optim.jl to make MLE and MAP estimation straightforward for Turing models.\nParticle sampler improvements. Turing’s development team has spent a lot of time and energy to make inference methods more modular, but Turing’s particle samplers have not yet been modernized and spun off into a separate package. Two packages that resulted from this were AdvancedHMC for Hamiltonian MCMC methods, and AdvancedMH for Metropolis-Hastings style inference methods. A student who worked on this project would become very familiar with Turing’s inference backend and with particle sampling methods. This is a good project for people who love making things efficient and easily extendable.\n\nOther projects are welcome, but we do strongly recommend discussing any potential projects with members of the Turing team, as they will end up mentoring GSoC students for the duration of the project.\nWe’re looking forward to what people are interested in!\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-05-23-newsletter-7/index.html",
    "href": "news/posts/2025-05-23-newsletter-7/index.html",
    "title": "Turing.jl Newsletter 7",
    "section": "",
    "text": "MCMCChains@7\nThere’s a new major version of MCMCChains.jl. From a user point of view, the main difference is that summary statistics and quantiles aren’t automatically calculated by default (so, printing a Chains object in a REPL will only show the parameter names and sizes). To get the summary statistics and quantiles you will have to run describe(chain). The main reason for this is because the summary stats would often take quite a while to compute — if you wish to preserve the old behaviour you can stick to MCMCChains@6.\nJuliaBUGS @model\nJuliaBUGS.jl recently implemented a @model macro which, in terms of its syntax, looks somewhat similar to Turing.jl’s own macro, but under the hood constructs a BUGS model. Perhaps of interest is the way that parameters are initialised using @parameters struct ... end; this currently helps to initialise all parameter values to placeholders, and offers an alternative to explicitly specifying this with NamedTuples or arrays. This hasn’t yet been released but for more information and a demonstration, there’s a documentation page that describes the design of this macro. The existing @bugs macro will still be retained.\nLibtask\nLibtask.jl, the library that Turing’s particle Gibbs sampler is built on, was recently rewritten for its core parts by Will Tebbutt (#179. Libtask implements copyable, resumable tasks (coroutines) in pure Julia, and the new version is much faster and better documented. The new implementation is based on source code transformations, using tools and techniques from Mooncake.jl. Work is ongoing to adapt AdvancedPS.jl to work with the new Libtask version, and once that is done we should expect a performance boost for Turing’s particle Gibbs sampler. We’ll let you know once that’s out.\n\n\n\n Back to top"
  },
  {
    "objectID": "news/posts/2025-02-28-newsletter-1/index.html",
    "href": "news/posts/2025-02-28-newsletter-1/index.html",
    "title": "Turing.jl Newsletter 1",
    "section": "",
    "text": "Welcome to the inaugural issue of the Turing.jl newsletter!\nWhat is this?!\nHi everyone! 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.\nYou can keep up with the newsletter either on this website, on the #turing channel in Julia Slack, or by subscribing to our issue on GitHub. We might post to other places too (like Discourse), this is still in the works!\nNew Turing behaviour, especially .~\nRecently 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.\nDifferentiationInterface migration\nFrom 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 Guillaume Dalle’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.\nThe plan for submodels\nWe 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.\nTuring.jl is now published (again!)\nWe recently published a new paper with a high-level overview of Turing.jl’s features and implementation. Check it out!\nFjelde, 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). (link)\nWe have also published in the conference proceedings of the workshop on Languages for Inference (LAFI), which was held as part of POPL 2025:\nTim 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)\nLooking for Google Summer of Code students\nWe 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.\n\n\n\n Back to top"
  }
]