[
  {
    "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"
  },
  {
    "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/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-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: - 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.\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/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/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/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"
  }
]