chore: bump the all-julia-packages group across 3 directories with 1 update

[dependabot]

Updates the requirements on and DynamicPPL to permit the latest version.
Updates DynamicPPL to 0.40.1

Release notes

Sourced from DynamicPPL's releases.

v0.40.1

DynamicPPL v0.40.1

Diff since v0.40.0

Fix AD performance with ReverseDiff (v0.39.9 inadvertently introduced a bug that did not cause any correctness issues, but did cause severe slowdowns with ReverseDiff -- this patch reverts that).

Merged pull requests:

• Fix ReverseDiff perf (#1288) (@​penelopeysm)

Changelog

Sourced from DynamicPPL's changelog.

0.40.1

Fix AD performance with ReverseDiff (v0.39.9 inadvertently introduced a bug that did not cause any correctness issues, but did cause severe slowdowns with ReverseDiff -- this patch reverts that).

0.40

v0.40 of DynamicPPL brings with it a complete rewrite of DynamicPPL's core data structure, VarInfo.

The main breaking change for users here is the removal of non-array indexing in random variables of DynamicPPL models, and the stipulation that arrays of random variables do not change size during model execution. Other breaking changes relate to the function signatures of some core DynamicPPL functions, and will not affect you unless you are developing against DynamicPPL.

In return for these breaking changes, there are major improvements in both performance and robustness of DynamicPPL models.

There is a lot more documentation at https://turinglang.org/DynamicPPL.jl/v0.40/, covering model evaluation, tilde-statements, LogDensityFunction, and much more. If you are unsure about anything, the docs are a great place to start; otherwise, please open an issue and we are happy to help.

What's new

VarNamedTuple

DynamicPPL now exports a new type, called VarNamedTuple, which stores values keyed by VarNames. With it are exported a few new functions for using it: map_values!!, map_pairs!!, apply!!. The DynamicPPL documentation now has a series of pages about VarNamedTuple, covering its motivation, implementation, and how it is used in DynamicPPL.

VarNamedTuple is now used internally in many different parts: In VarInfo, in values_as_in_model, in LogDensityFunction, etc. Almost all of the changes in this version are a consequence resulting from the consistent use of VarNamedTuple for various features internally.

In particular, this version of DynamicPPL has much more robust handling of variables with indices, such as x[1] and x[2]. For example:

• You can condition on x[1] and x[2] separately, or even on x[:], even if they are part of the same array x ~ dist. This is subject to you specifying the correct template for x in the conditioning values (please see the main TuringLang docs for more details).

• You can use arbitrary arrays in a DynamicPPL model (e.g. OffsetArray, StaticArray, etc) and DynamicPPL will handle the indexing correctly.

• In the outputs of functions such as rand(model) you can index into them with VarNames such as x[1:2] or x[end], even if the model had x[1] and x[2] in separate tilde-statements.

The bottom line is that indexing into DynamicPPL's data structures now has the same semantics as the model itself. Previously, this was not always the case; there were many silent errors where variables were ignored when their indices did not line up exactly.

Performance

This release includes significant performance improvements for many common operations in DynamicPPL, with speedups of up to several orders of magnitude. See e.g. this PR for some benchmarks.

Conditioning and fixing

Conditioning and fixing now exclusively use VarNamedTuple internally. You can still condition or fix a model with the same API as before (with NamedTuple or Dict). However, for most precise control over exactly which variables are conditioned as well as the templates for any arrays present, you can also condition directly using a VarNamedTuple. For example:

... (truncated)

Commits

• See full diff in compare view

Updates DynamicPPL to 0.40.1

Release notes

Sourced from DynamicPPL's releases.

v0.40.1

DynamicPPL v0.40.1

Diff since v0.40.0

Fix AD performance with ReverseDiff (v0.39.9 inadvertently introduced a bug that did not cause any correctness issues, but did cause severe slowdowns with ReverseDiff -- this patch reverts that).

Merged pull requests:

• Fix ReverseDiff perf (#1288) (@​penelopeysm)

Changelog

Sourced from DynamicPPL's changelog.

0.40.1

Fix AD performance with ReverseDiff (v0.39.9 inadvertently introduced a bug that did not cause any correctness issues, but did cause severe slowdowns with ReverseDiff -- this patch reverts that).

0.40

v0.40 of DynamicPPL brings with it a complete rewrite of DynamicPPL's core data structure, VarInfo.

The main breaking change for users here is the removal of non-array indexing in random variables of DynamicPPL models, and the stipulation that arrays of random variables do not change size during model execution. Other breaking changes relate to the function signatures of some core DynamicPPL functions, and will not affect you unless you are developing against DynamicPPL.

In return for these breaking changes, there are major improvements in both performance and robustness of DynamicPPL models.

There is a lot more documentation at https://turinglang.org/DynamicPPL.jl/v0.40/, covering model evaluation, tilde-statements, LogDensityFunction, and much more. If you are unsure about anything, the docs are a great place to start; otherwise, please open an issue and we are happy to help.

What's new

VarNamedTuple

DynamicPPL now exports a new type, called VarNamedTuple, which stores values keyed by VarNames. With it are exported a few new functions for using it: map_values!!, map_pairs!!, apply!!. The DynamicPPL documentation now has a series of pages about VarNamedTuple, covering its motivation, implementation, and how it is used in DynamicPPL.

VarNamedTuple is now used internally in many different parts: In VarInfo, in values_as_in_model, in LogDensityFunction, etc. Almost all of the changes in this version are a consequence resulting from the consistent use of VarNamedTuple for various features internally.

In particular, this version of DynamicPPL has much more robust handling of variables with indices, such as x[1] and x[2]. For example:

• You can condition on x[1] and x[2] separately, or even on x[:], even if they are part of the same array x ~ dist. This is subject to you specifying the correct template for x in the conditioning values (please see the main TuringLang docs for more details).

• You can use arbitrary arrays in a DynamicPPL model (e.g. OffsetArray, StaticArray, etc) and DynamicPPL will handle the indexing correctly.

• In the outputs of functions such as rand(model) you can index into them with VarNames such as x[1:2] or x[end], even if the model had x[1] and x[2] in separate tilde-statements.

The bottom line is that indexing into DynamicPPL's data structures now has the same semantics as the model itself. Previously, this was not always the case; there were many silent errors where variables were ignored when their indices did not line up exactly.

Performance

This release includes significant performance improvements for many common operations in DynamicPPL, with speedups of up to several orders of magnitude. See e.g. this PR for some benchmarks.

Conditioning and fixing

Conditioning and fixing now exclusively use VarNamedTuple internally. You can still condition or fix a model with the same API as before (with NamedTuple or Dict). However, for most precise control over exactly which variables are conditioned as well as the templates for any arrays present, you can also condition directly using a VarNamedTuple. For example:

... (truncated)

Commits

• See full diff in compare view

Updates DynamicPPL to 0.40.1

Release notes

Sourced from DynamicPPL's releases.

v0.40.1

DynamicPPL v0.40.1

Diff since v0.40.0

Fix AD performance with ReverseDiff (v0.39.9 inadvertently introduced a bug that did not cause any correctness issues, but did cause severe slowdowns with ReverseDiff -- this patch reverts that).

Merged pull requests:

• Fix ReverseDiff perf (#1288) (@​penelopeysm)

Changelog

Sourced from DynamicPPL's changelog.

0.40.1

Fix AD performance with ReverseDiff (v0.39.9 inadvertently introduced a bug that did not cause any correctness issues, but did cause severe slowdowns with ReverseDiff -- this patch reverts that).

0.40

v0.40 of DynamicPPL brings with it a complete rewrite of DynamicPPL's core data structure, VarInfo.

The main breaking change for users here is the removal of non-array indexing in random variables of DynamicPPL models, and the stipulation that arrays of random variables do not change size during model execution. Other breaking changes relate to the function signatures of some core DynamicPPL functions, and will not affect you unless you are developing against DynamicPPL.

In return for these breaking changes, there are major improvements in both performance and robustness of DynamicPPL models.

There is a lot more documentation at https://turinglang.org/DynamicPPL.jl/v0.40/, covering model evaluation, tilde-statements, LogDensityFunction, and much more. If you are unsure about anything, the docs are a great place to start; otherwise, please open an issue and we are happy to help.

What's new

VarNamedTuple

DynamicPPL now exports a new type, called VarNamedTuple, which stores values keyed by VarNames. With it are exported a few new functions for using it: map_values!!, map_pairs!!, apply!!. The DynamicPPL documentation now has a series of pages about VarNamedTuple, covering its motivation, implementation, and how it is used in DynamicPPL.

VarNamedTuple is now used internally in many different parts: In VarInfo, in values_as_in_model, in LogDensityFunction, etc. Almost all of the changes in this version are a consequence resulting from the consistent use of VarNamedTuple for various features internally.

In particular, this version of DynamicPPL has much more robust handling of variables with indices, such as x[1] and x[2]. For example:

• You can condition on x[1] and x[2] separately, or even on x[:], even if they are part of the same array x ~ dist. This is subject to you specifying the correct template for x in the conditioning values (please see the main TuringLang docs for more details).

• You can use arbitrary arrays in a DynamicPPL model (e.g. OffsetArray, StaticArray, etc) and DynamicPPL will handle the indexing correctly.

• In the outputs of functions such as rand(model) you can index into them with VarNames such as x[1:2] or x[end], even if the model had x[1] and x[2] in separate tilde-statements.

The bottom line is that indexing into DynamicPPL's data structures now has the same semantics as the model itself. Previously, this was not always the case; there were many silent errors where variables were ignored when their indices did not line up exactly.

Performance

This release includes significant performance improvements for many common operations in DynamicPPL, with speedups of up to several orders of magnitude. See e.g. this PR for some benchmarks.

Conditioning and fixing

Conditioning and fixing now exclusively use VarNamedTuple internally. You can still condition or fix a model with the same API as before (with NamedTuple or Dict). However, for most precise control over exactly which variables are conditioned as well as the templates for any arrays present, you can also condition directly using a VarNamedTuple. For example:

... (truncated)

Commits

• See full diff in compare view

Most Recent Ignore Conditions Applied to This Pull Request

Dependency Name	Ignore Conditions
DynamicPPL	[>= 0.39.a, < 0.40]

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[dependabot]

Superseded by #312.