Releases: TuringLang/DynamicPPL.jl
v0.35.6
DynamicPPL v0.35.6
Fixed the implementation of .~, such that running a model with it no longer requires DynamicPPL itself to be loaded.
Merged pull requests:
- simplify benchmarking commit ref (#855) (@yebai)
- CompatHelper: bump compat for ForwardDiff to 1 for package docs, (keep existing compat) (#865) (@github-actions[bot])
- CompatHelper: bump compat for ForwardDiff to 1 for package test, (keep existing compat) (#866) (@github-actions[bot])
Closed issues:
v0.35.5
DynamicPPL v0.35.5
Several internal methods have been removed:
DynamicPPL.getall(vi::AbstractVarInfo)has been removed. You can directly replace this withgetindex_internal(vi, Colon()).DynamicPPL.setall!(vi::AbstractVarInfo, values)has been removed. Rewrite the calling function to not assume mutation and useunflatten(vi, values)instead.DynamicPPL.replace_values(md::Metadata, values)andDynamicPPL.replace_values(nt::NamedTuple, values)(where thentis a NamedTuple of Metadatas) have been removed. UseDynamicPPL.unflatten_metadataas a direct replacement.DynamicPPL.set_values!!(vi::AbstractVarInfo, values)has been renamed toDynamicPPL.set_initial_values(vi::AbstractVarInfo, values); it also no longer mutates the varinfo argument.
The exported method VarInfo(vi::VarInfo, values) has been deprecated, and will be removed in the next minor version. You can replace this directly with unflatten(vi, values) instead.
v0.35.4
DynamicPPL v0.35.4
Fixed a type instability in an implementation of with_logabsdet_jacobian, which resulted in the log-jacobian returned being an Int in some cases and a Float in others.
This resolves an Enzyme.jl error on a number of models.
More generally, this version also changes the type of various log probabilities to be more consistent with one another.
Although we aren't fully there yet, our eventual aim is that log probabilities will generally default to Float64 on 64-bit systems, and Float32 on 32-bit systems.
If you run into any issues with these types, please get in touch.
Merged pull requests:
- Fix zero-type of logjac for ReshapeTransform (#851) (@mhauru)
- Add a changelog entry for 0.35.4 (#852) (@penelopeysm)
v0.35.3
DynamicPPL v0.35.3
model | (@varname(x) => 1.0, @varname(y) => 2.0) now works. Previously, this would throw a MethodError if the tuple had more than one element.
v0.35.2
DynamicPPL v0.35.2
unflatten(::VarInfo, params) now works with params that have non-float types (such as Int or Bool).
v0.35.1
DynamicPPL v0.35.1
subset(::AbstractVarInfo, ::AbstractVector{<:VarName}) now preserves the ordering of the varnames in the original varinfo argument.
Previously, this would select the varnames according to their order in the second argument.
This fixes an upstream Turing.jl issue with Gibbs sampling when a component sampler was assigned multiple variables.
Merged pull requests:
- CompatHelper: bump compat for Zygote to 0.7 for package test, (keep existing compat) (#771) (@github-actions[bot])
- Update benchmark models (#826) (@mhauru)
- CompatHelper: bump compat for DocumenterMermaid to 0.2 for package docs, (keep existing compat) (#831) (@github-actions[bot])
- Make benchmarks not depend on TuringBenchmarking.jl, and run
]dev ..(#834) (@mhauru) - Removed Zygote tests (#837) (@shravanngoswamii)
Closed issues:
v0.35.0
DynamicPPL v0.35.0
Breaking changes
.~ right hand side must be a univariate distribution
Previously we allowed statements like
x .~ [Normal(), Gamma()]where the right hand side of a .~ was an array of distributions, and ones like
x .~ MvNormal(fill(0.0, 2), I)where the right hand side was a multivariate distribution.
These are no longer allowed. The only things allowed on the right hand side of a .~ statement are univariate distributions, such as
x = Array{Float64,3}(undef, 2, 3, 4)
x .~ Normal()The reasons for this are internal code simplification and the fact that broadcasting where both sides are multidimensional but of different dimensions is typically confusing to read.
If the right hand side and the left hand side have the same dimension, one can simply use ~. Arrays of distributions can be replaced with product_distribution. So instead of
x .~ [Normal(), Gamma()]
x .~ Normal.(y)
x .~ MvNormal(fill(0.0, 2), I)do
x ~ product_distribution([Normal(), Gamma()])
x ~ product_distribution(Normal.(y))
x ~ MvNormal(fill(0.0, 2), I)This is often more performant as well. Note that using ~ rather than .~ does change the internal storage format a bit: With .~ x[i] are stored as separate variables, with ~ as a single multivariate variable x. In most cases this does not change anything for the user, but if it does cause issues, e.g. if you are dealing with VarInfo objects directly and need to keep the old behavior, you can always expand into a loop, such as
dists = Normal.(y)
for i in 1:length(dists)
x[i] ~ dists[i]
endCases where the right hand side is of a different dimension than the left hand side, and neither is a scalar, must be replaced with a loop. For example,
x = Array{Float64,3}(undef, 2, 3, 4)
x .~ MvNormal(fill(0, 2), I)should be replaced with something like
x = Array{Float64,3}(2, 3, 4)
for i in 1:3, j in 1:4
x[:, i, j] ~ MvNormal(fill(0, 2), I)
endThis release also completely rewrites the internal implementation of .~, where from now on all .~ statements are turned into loops over ~ statements at macro time. However, the only breaking aspect of this change is the above change to what's allowed on the right hand side.
Remove indexing by samplers
This release removes the feature of VarInfo where it kept track of which variable was associated with which sampler. This means removing all user-facing methods where VarInfos where being indexed with samplers. In particular,
linkandinvlink, and their!!versions, no longer accept a sampler as an argument to specify which variables to (inv)link. Thelink(varinfo, model)methods remain in place, and as a new addition one can give aTupleofVarNames to (inv)link only select variables, as inlink(varinfo, varname_tuple, model).set_retained_vns_del_by_spl!has been replaced byset_retained_vns_del!which applies to all variables.getindex,setindex!, andsetindex!!no longer accept samplers as argumentsunflattenno longer accepts a sampler as an argumenteltype(::VarInfo)no longer accepts a sampler as an argumentkeys(::VarInfo)no longer accepts a sampler as an argumentVarInfo(::VarInfo, ::Sampler, ::AbstractVector)no longer accepts the sampler argument.push!!andpush!no longer accept samplers orSelectors as argumentsgetgid,setgid!,updategid!,getspace, andinspaceno longer exist
Reverse prefixing order
-
For submodels constructed using
to_submodel, the order in which nested prefixes are applied has been changed.
Previously, the order was that outer prefixes were applied first, then inner ones.
This version reverses that.
To illustrate:using DynamicPPL, Distributions @model function subsubmodel() return x ~ Normal() end @model function submodel() x ~ to_submodel(prefix(subsubmodel(), :c), false) return x end @model function parentmodel() x1 ~ to_submodel(prefix(submodel(), :a), false) return x2 ~ to_submodel(prefix(submodel(), :b), false) end keys(VarInfo(parentmodel()))
Previously, the final line would return the variable names
c.a.xandc.b.x.
With this version, it will returna.c.xandb.c.x, which is more intuitive.
(Note that this change bringsto_submodel's behaviour in line with the now-deprecated@submodelmacro.)This change also affects sampling in Turing.jl.
LogDensityFunction argument order
- The method
LogDensityFunction(varinfo, model, sampler)has been removed.
The only accepted order isLogDensityFunction(model, varinfo, context; adtype).
(For an explanation ofadtype, see below.)
The varinfo and context arguments are both still optional.
Other changes
New exports
LogDensityFunction and predict are now exported from DynamicPPL.
LogDensityProblems interface
LogDensityProblemsAD is now removed as a dependency.
Instead of constructing a LogDensityProblemAD.ADgradient object, we now directly use DifferentiationInterface to calculate the gradient of the log density with respect to model parameters.
Note that if you wish, you can still construct an ADgradient out of a LogDensityFunction object (there is nothing preventing this).
However, in this version, LogDensityFunction now takes an extra AD type argument.
If this argument is not provided, the behaviour is exactly the same as before, i.e. you can calculate logdensity but not its gradient.
However, if you do pass an AD type, that will allow you to calculate the gradient as well.
You may thus find that it is easier to instead do this:
@model f() = ...
ldf = LogDensityFunction(f(); adtype=AutoForwardDiff())This will return an object which satisfies the LogDensityProblems interface to first-order, i.e. you can now directly call both
LogDensityProblems.logdensity(ldf, params)
LogDensityProblems.logdensity_and_gradient(ldf, params)
without having to construct a separate ADgradient object.
If you prefer, you can also construct a new LogDensityFunction with a new AD type afterwards.
The model, varinfo, and context will be taken from the original LogDensityFunction:
Merged pull requests:
- Remove selector stuff from VarInfo tests and link/invlink (#780) (@mhauru)
- Reverse order of prefixing & add changelog (#792) (@penelopeysm)
- Remove samplers from VarInfo - indexing (#793) (@mhauru)
- Redirect transformation to main docs (#798) (@penelopeysm)
- Run Docs and Format workflows on all PRs (#800) (@penelopeysm)
- Remove dot_tilde pipeline (#804) (@mhauru)
- Update GHA to use shared org actions (#805) (@penelopeysm)
- Remove LogDensityProblemsAD; wrap adtype in LogDensityFunction (#806) (@penelopeysm)
- Remove samplers from VarInfo - Selectors and GIDs (#808) (@mhauru)
- Bump KernelAbstractions to 0.9.33 (#809) (@penelopeysm)
- Remove LogDensityProblemsAD Extension 2 (#811) (@penelopeysm)
- Remove x86 CI (#819) (@penelopeysm)
- Export
LogDensityFunction(#820) (@penelopeysm) - Export
predictwith 0.35 (#821) (@sunxd3) - Fix predict docstring (#822) (@penelopeysm)
Closed issues:
.~seems to give incorrect answers (#28)- Error with
.~andrand(#405) - Should we have a context to indicate that we're not performing inference? (#510)
- Sampling from model prior with
missingis thread-unsafe (#641) - Decide the fate of
VarInfo.num_produce(#661) - Support for variables with changing size with
dot_tilde(#700) - Move transformation docs to docs (#713)
- Confusion regarding
.~(#722) - Issues with the dot-tilde (i.e.
.~) syntax (#761) - Update GHA (#803)
- Submodels (#807)
v0.34.2
DynamicPPL v0.34.2
- Fixed bugs in ValuesAsInModelContext as well as DebugContext where underlying PrefixContexts were not being applied. From a user-facing perspective, this means that for models which use manually prefixed submodels, e.g.
using DynamicPPL, Distributions
@model inner() = x ~ Normal()
@model function outer()
x1 ~ to_submodel(prefix(inner(), :a), false)
x2 ~ to_submodel(prefix(inner(), :b), false)
endwill: (1) no longer error when sampling due to check_model_and_trace; and (2) contain both submodel's variables in the resulting chain (the behaviour before this patch was that the second x would override the first x).
- More broadly, implemented a general
prefix(ctx::AbstractContext, ::VarName)which traverses the context tree inctxto apply all necessary prefixes. This was a necessary step in fixing the above issues, but it also means thatprefixis now capable of handling context trees with e.g. multiple prefixes at different levels of nesting.
Merged pull requests:
- Expand JET test (#782) (@penelopeysm)
- Clarify is_unconstrained docstring (#790) (@penelopeysm)
v0.34.1
DynamicPPL v0.34.1
Fix an issue that prevented merging two VarInfos if they had different dimensions for a variable.
Upper bound the compat version of KernelAbstractions to work around an issue in determining the right VarInfo type to use.
v0.34.0
DynamicPPL v0.34.0
Breaking changes
-
rngargument removed fromvalues_as_in_model, andvarinfomade non-optional. This means that the only signatures allowed arevalues_as_in_model(::Model, ::Bool, ::AbstractVarInfo) values_as_in_model(::Model, ::Bool, ::AbstractVarInfo, ::AbstractContext)
If you aren't using this function (it's probably only used in Turing.jl) then this won't affect you.