cho202 / dynamicppl.jl

Implementation of domain-specific language (DSL) for dynamic probabilistic programming

DynamicPPL.jl

A domain-specific language and backend for probabilistic programming, used by Turing.jl.

DynamicPPL is the part of Turing.jl that deals with defining, running, and manipulating models. DynamicPPL provides:

• General-purpose probabilistic programming with an intuitive syntax.
• The @model syntax and macro for easily specifying probabilistic generative models.
• A tracing data-structure for tracking random variables in dynamic probabilistic models.
• A rich contextual dispatch system allowing for tailored behaviour during model execution.
• A user-friendly syntax for probabilistic queries.

Information on how to use the DynamicPPL frontend to build Bayesian models can be found on the Turing website. Tutorials explaining how to use the backend can be found alongside the documentation. More information can be found in our paper DynamicPPL: Stan-like Speed for Dynamic Probabilistic Models.

Do you want to contribute?

If you feel you have some relevant skills and are interested in contributing, please get in touch! You can find us in the #turing channel on the Julia Slack or Discourse. If you're having any problems, please open a Github issue, even if the problem seems small (like help figuring out an error message). Every issue you open helps us improve the library!

Contributor's Guide

This project follows the , apart from the following slight variation:

• The master branch contains the most recent release at any point in time. All non-breaking changes (bug fixes etc.) are merged directly into master and a new patch version is released immediately.
• A separate dev branch contains all breaking changes, and is merged into master when a minor version release happens.

For instance, suppose we are currently on version 0.13.5.

• If someone produces a bug fix, it is merged directly into master and bumps the version to 0.13.6. This change is also merged into dev so that it remains up-to-date with master.
• If someone is working on a new feature that is not breaking (performance-related, fancy new syntax that is backwards-compatible etc.), the same happens.
• New breaking changes are merged into dev until a release is ready to go, at which point dev is merged into master and version 0.14 is released.

Bors

This project uses Bors for merging PRs. Bors is a Github bot that prevents merge skew / semantic merge conflicts by testing the exact integration of pull requests before merging them.

When a PR is good enough for merging and has been approved by at least one reviewer, instead of merging immediately, it is added to the merge queue by commenting with bors r+. The Bors bot merges the pull request into a staging area, and runs the CI tests. If tests pass, the commit in the staging area is copied to the target branch (i.e., usually master).

PRs can be tested by adding a comment with bors try. Additional commands can be found in the Bors documentation.