Skip to content

v0.35.0
Compare
Choose a tag to compare
@github-actions github-actions released this 28 Feb 17:17
v0.35.0
6fe46ee
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

DynamicPPL v0.35.0

Diff since v0.34.2

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]
end

Cases 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)
end

This 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,

  • link and invlink, and their !! versions, no longer accept a sampler as an argument to specify which variables to (inv)link. The link(varinfo, model) methods remain in place, and as a new addition one can give a Tuple of VarNames to (inv)link only select variables, as in link(varinfo, varname_tuple, model).
  • set_retained_vns_del_by_spl! has been replaced by set_retained_vns_del! which applies to all variables.
  • getindex, setindex!, and setindex!! no longer accept samplers as arguments
  • unflatten no longer accepts a sampler as an argument
  • eltype(::VarInfo) no longer accepts a sampler as an argument
  • keys(::VarInfo) no longer accepts a sampler as an argument
  • VarInfo(::VarInfo, ::Sampler, ::AbstractVector) no longer accepts the sampler argument.
  • push!! and push! no longer accept samplers or Selectors as arguments
  • getgid, setgid!, updategid!, getspace, and inspace no 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.x and c.b.x.
    With this version, it will return a.c.x and b.c.x, which is more intuitive.
    (Note that this change brings to_submodel's behaviour in line with the now-deprecated @submodel macro.)

    This change also affects sampling in Turing.jl.

LogDensityFunction argument order

  • The method LogDensityFunction(varinfo, model, sampler) has been removed.
    The only accepted order is LogDensityFunction(model, varinfo, context; adtype).
    (For an explanation of adtype, 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:

Closed issues:

  • .~ seems to give incorrect answers (#28)
  • Error with .~ and rand (#405)
  • Should we have a context to indicate that we're not performing inference? (#510)
  • Sampling from model prior with missing is 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)

Contributors

mhauru, sunxd3, and penelopeysm
Assets 2
Loading