Skip to content

Accumulators, stage 1 #885

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 67 commits into from
May 2, 2025
Merged
Show file tree
Hide file tree
Changes from 10 commits
Commits
Show all changes
67 commits
Select commit Hold shift + click to select a range
061acbe
Release 0.36
penelopeysm Mar 5, 2025
1496868
Merge branch 'main' into breaking
penelopeysm Mar 20, 2025
324e623
Merge branch 'main' into breaking
penelopeysm Mar 22, 2025
bb59885
Merge branch 'main' into breaking
penelopeysm Mar 25, 2025
fc32398
AbstractPPL 0.11 + change prefixing behaviour (#830)
penelopeysm Mar 28, 2025
cc5e581
Remove VarInfo(VarInfo, params) (#870)
penelopeysm Mar 28, 2025
b9c368b
Unify `{untyped,typed}_{vector_,}varinfo` constructor functions (#879)
penelopeysm Apr 9, 2025
1b8f555
Merge remote-tracking branch 'origin/main' into breaking
mhauru Apr 9, 2025
ae9b1cd
Draft of accumulators
mhauru Feb 24, 2025
4fb0bf4
Fix some variable names
mhauru Apr 10, 2025
e410f47
Merge remote-tracking branch 'origin/main' into breaking
penelopeysm Apr 11, 2025
97788bd
Fix pointwise_logdensities, gut tilde_observe, remove resetlogp!!
mhauru Apr 11, 2025
7fe03ec
Map rather than broadcast
mhauru Apr 15, 2025
5ba3530
Merge remote-tracking branch 'origin/main' into breaking
penelopeysm Apr 15, 2025
d49f7be
Start documenting accumulators
mhauru Apr 15, 2025
28bbf1c
Use Val{symbols} instead of AccTypes to index
mhauru Apr 15, 2025
a0ed665
More documentation for accumulators
mhauru Apr 15, 2025
be27636
Link varinfo by default in AD testing utilities; make test suite run …
penelopeysm Apr 16, 2025
e6453fe
Fix resetlogp!! and type stability for accumulators
mhauru Apr 16, 2025
c59400d
Fix type rigidity of LogProbs and NumProduce
mhauru Apr 16, 2025
47033ce
Fix uses of getlogp and other assorted issues
mhauru Apr 17, 2025
8b841c9
setaccs!! nicer interface and logdensity function fixes
mhauru Apr 17, 2025
3ee3989
Revert back to calling the macro @addlogprob!
mhauru Apr 22, 2025
13163f2
Remove a dead test
mhauru Apr 22, 2025
37dd6dd
Clarify a comment
mhauru Apr 22, 2025
d7013b6
Implement split/combine for PointwiseLogdensityAccumulator
mhauru Apr 22, 2025
40d4caa
Switch ThreadSafeVarInfo.accs_by_thread to be a tuple
mhauru Apr 22, 2025
ff5f2cb
Fix `condition` and `fix` in submodels (#892)
penelopeysm Apr 23, 2025
c68f1bb
Merge remote-tracking branch 'origin/main' into breaking
penelopeysm Apr 23, 2025
13da08a
Revert ThreadSafeVarInfo back to Vectors and fix some AD type casting…
mhauru Apr 24, 2025
d52feec
Merge remote-tracking branch 'origin/breaking' into mhauru/custom-acc…
mhauru Apr 24, 2025
221e797
Improve accumulator docs
mhauru Apr 24, 2025
1dbcb2c
Add test/accumulators.jl
mhauru Apr 24, 2025
e1b70e0
Docs fixes
mhauru Apr 24, 2025
3f195e5
Various small fixes
mhauru Apr 24, 2025
68b974a
Make DynamicTransformation not use accumulators other than LogPrior
mhauru Apr 24, 2025
2b405d9
Fix variable order and name of map_accumulator!!
mhauru Apr 24, 2025
00cd304
Typo fixing
mhauru Apr 24, 2025
6d1048d
Small improvement to ThreadSafeVarInfo
mhauru Apr 24, 2025
4fef20f
Fix demo_dot_assume_observe_submodel prefixing
mhauru Apr 24, 2025
905b874
Merge branch 'breaking' into mhauru/custom-accumulators
mhauru Apr 24, 2025
557954a
Typo fixing
mhauru Apr 24, 2025
6f702c9
Miscellaneous small fixes
mhauru Apr 25, 2025
f748775
HISTORY entry and more miscellanea
mhauru Apr 25, 2025
5f4a532
Add more tests for accumulators
mhauru Apr 25, 2025
31967fd
Improve accumulators docstrings
mhauru Apr 25, 2025
ad2f564
Fix a typo
mhauru Apr 25, 2025
10b4f2f
Expand HISTORY entry
mhauru Apr 25, 2025
d2b670d
Add accumulators to API docs
mhauru Apr 25, 2025
8241d12
Remove unexported functions from API docs
mhauru Apr 25, 2025
7b7a3e2
Add NamedTuple methods for get/set/acclogp
mhauru Apr 25, 2025
0b08237
Fix setlogp!! with single scalar to error
mhauru Apr 25, 2025
2a4b874
Export AbstractAccumulator, fix a docs typo
mhauru Apr 25, 2025
c1e90f7
Apply suggestions from code review
mhauru Apr 28, 2025
cb1c6c6
Rename LogPrior -> LogPriorAccumulator, and Likelihood and NumProduce
mhauru Apr 28, 2025
00ef0cf
Type bound log prob accumulators with T<:Real
mhauru Apr 28, 2025
14f4788
Add @addlogprior! and @addloglikelihood!
mhauru Apr 28, 2025
c4ee4ec
Apply suggestions from code review
mhauru Apr 30, 2025
7ad9450
Move default accumulators to default_accumulators.jl
mhauru Apr 30, 2025
c5e2a6b
Fix some tests
mhauru Apr 30, 2025
fb09acc
Introduce default_accumulators()
mhauru Apr 30, 2025
e324c9b
Go back to only having @addlogprob!
mhauru Apr 30, 2025
6b7b9f8
Fix tilde_observe!! prefixing
mhauru Apr 30, 2025
048178b
Fix default_accumulators internal type
mhauru Apr 30, 2025
6437801
Make unflatten more type stable, and add a test for it
mhauru May 1, 2025
bf95169
Always print all benchmark results
mhauru May 1, 2025
efc7c53
Move NumProduce VI functions to abstract_varinfo.jl
mhauru May 1, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 82 additions & 0 deletions HISTORY.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,87 @@
# DynamicPPL Changelog

## 0.36.0

**Breaking changes**

### VarInfo constructors

`VarInfo(vi::VarInfo, values)` has been removed. You can replace this directly with `unflatten(vi, values)` instead.

The `metadata` argument to `VarInfo([rng, ]model[, sampler, context, metadata])` has been removed.
If you were not using this argument (most likely), then there is no change needed.
If you were using the `metadata` argument to specify a blank `VarNamedVector`, then you should replace calls to `VarInfo` with `DynamicPPL.typed_vector_varinfo` instead (see 'Other changes' below).

The `UntypedVarInfo` constructor and type is no longer exported.
If you needed to construct one, you should now use `DynamicPPL.untyped_varinfo` instead.

The `TypedVarInfo` constructor and type is no longer exported.
The _type_ has been replaced with `DynamicPPL.NTVarInfo`.
The _constructor_ has been replaced with `DynamicPPL.typed_varinfo`.

Note that the exact kind of VarInfo returned by `VarInfo(rng, model, ...)` is an implementation detail.
Previously, it was guaranteed that this would always be a VarInfo whose metadata was a `NamedTuple` containing `Metadata` structs.
Going forward, this is no longer the case, and you should only assume that the returned object obeys the `AbstractVarInfo` interface.

### VarName prefixing behaviour

The way in which VarNames in submodels are prefixed has been changed.
This is best explained through an example.
Consider this model and submodel:

```julia
using DynamicPPL, Distributions
@model inner() = x ~ Normal()
@model outer() = a ~ to_submodel(inner())
```

In previous versions, the inner variable `x` would be saved as `a.x`.
However, this was represented as a single symbol `Symbol("a.x")`:

```julia
julia> dump(keys(VarInfo(outer()))[1])
VarName{Symbol("a.x"), typeof(identity)}
optic: identity (function of type typeof(identity))
```

Now, the inner variable is stored as a field `x` on the VarName `a`:

```julia
julia> dump(keys(VarInfo(outer()))[1])
VarName{:a, Accessors.PropertyLens{:x}}
optic: Accessors.PropertyLens{:x} (@o _.x)
```

In practice, this means that if you are trying to condition a variable in the submodel, you now need to use

```julia
outer() | (@varname(a.x) => 1.0,)
```

instead of either of these (which would have worked previously)

```julia
outer() | (@varname(var"a.x") => 1.0,)
outer() | (a.x=1.0,)
```

If you are sampling from a model with submodels, this doesn't affect the way you interact with the `MCMCChains.Chains` object, because VarNames are converted into Symbols when stored in the chain.
(This behaviour will likely be changed in the future, in that Chains should be indexable by VarNames and not just Symbols, but that has not been implemented yet.)

**Other changes**

While these are technically breaking, they are only internal changes and do not affect the public API.
The following four functions have been added and/or reworked to make it easier to construct VarInfos with different types of metadata:

1. `DynamicPPL.untyped_varinfo([rng, ]model[, sampler, context])`
2. `DynamicPPL.typed_varinfo([rng, ]model[, sampler, context])`
3. `DynamicPPL.untyped_vector_varinfo([rng, ]model[, sampler, context])`
4. `DynamicPPL.typed_vector_varinfo([rng, ]model[, sampler, context])`

The reason for this change is that there were several flavours of VarInfo.
Some, like `typed_varinfo`, were easy to construct because we had convenience methods for them; however, the others were more difficult.
This change makes it easier to access different VarInfo types, and also makes it more explicit which one you are constructing.

## 0.35.6

Fixed the implementation of `.~`, such that running a model with it no longer requires DynamicPPL itself to be loaded.
Expand Down
4 changes: 2 additions & 2 deletions Project.toml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
name = "DynamicPPL"
uuid = "366bfd00-2699-11ea-058f-f148b4cae6d8"
version = "0.35.6"
version = "0.36.0"

[deps]
ADTypes = "47edcb42-4c32-4615-8424-f2b9edc5f35b"
Expand Down Expand Up @@ -44,7 +44,7 @@ DynamicPPLMooncakeExt = ["Mooncake"]
[compat]
ADTypes = "1"
AbstractMCMC = "5"
AbstractPPL = "0.10.1"
AbstractPPL = "0.11"
Accessors = "0.1"
BangBang = "0.4.1"
Bijectors = "0.13.18, 0.14, 0.15"
Expand Down
10 changes: 4 additions & 6 deletions benchmarks/src/DynamicPPLBenchmarks.jl
Original file line number Diff line number Diff line change
Expand Up @@ -52,8 +52,8 @@ end

Create a benchmark suite for `model` using the selected varinfo type and AD backend.
Available varinfo choices:
• `:untyped` → uses `VarInfo()`
• `:typed` → uses `VarInfo(model)`
• `:untyped` → uses `DynamicPPL.untyped_varinfo(model)`
• `:typed` → uses `DynamicPPL.typed_varinfo(model)`
• `:simple_namedtuple` → uses `SimpleVarInfo{Float64}(model())`
• `:simple_dict` → builds a `SimpleVarInfo{Float64}` from a Dict (pre-populated with the model’s outputs)

Expand All @@ -67,11 +67,9 @@ function make_suite(model, varinfo_choice::Symbol, adbackend::Symbol, islinked::
suite = BenchmarkGroup()

vi = if varinfo_choice == :untyped
vi = VarInfo()
model(rng, vi)
vi
DynamicPPL.untyped_varinfo(rng, model)
elseif varinfo_choice == :typed
VarInfo(rng, model)
DynamicPPL.typed_varinfo(rng, model)
elseif varinfo_choice == :simple_namedtuple
SimpleVarInfo{Float64}(model(rng))
elseif varinfo_choice == :simple_dict
Expand Down
1 change: 1 addition & 0 deletions docs/Project.toml
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ DataStructures = "864edb3b-99cc-5e75-8d2d-829cb0a9cfe8"
Distributions = "31c24e10-a181-5473-b8eb-7969acd0382f"
Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4"
DocumenterMermaid = "a078cd44-4d9c-4618-b545-3ab9d77f9177"
DynamicPPL = "366bfd00-2699-11ea-058f-f148b4cae6d8"
FillArrays = "1a297f60-69ca-5386-bcde-b61e274b549b"
ForwardDiff = "f6369f11-7733-5829-9624-2563aa707210"
JET = "c3a54625-cd67-489e-a8e7-0a5a0ff4e31b"
Expand Down
16 changes: 7 additions & 9 deletions docs/src/api.md
Original file line number Diff line number Diff line change
Expand Up @@ -149,7 +149,7 @@ In the past, one would instead embed sub-models using [`@submodel`](@ref), which
In the context of including models within models, it's also useful to prefix the variables in sub-models to avoid variable names clashing:

```@docs
prefix
DynamicPPL.prefix
```

Under the hood, [`to_submodel`](@ref) makes use of the following method to indicate that the model it's wrapping is a model over its return-values rather than something else
Expand Down Expand Up @@ -291,18 +291,17 @@ AbstractVarInfo

But exactly how a [`AbstractVarInfo`](@ref) stores this information can vary.

For constructing the "default" typed and untyped varinfo types used in DynamicPPL (see [the section on varinfo design](@ref "Design of `VarInfo`") for more on this), we have the following two methods:
#### `VarInfo`

```@docs
DynamicPPL.untyped_varinfo
DynamicPPL.typed_varinfo
VarInfo
```

#### `VarInfo`

```@docs
VarInfo
TypedVarInfo
DynamicPPL.untyped_varinfo
DynamicPPL.typed_varinfo
DynamicPPL.untyped_vector_varinfo
DynamicPPL.typed_vector_varinfo
```

One main characteristic of [`VarInfo`](@ref) is that samples are transformed to unconstrained Euclidean space and stored in a linearized form, as described in the [main Turing documentation](https://turinglang.org/docs/developers/transforms/dynamicppl/).
Expand Down Expand Up @@ -420,7 +419,6 @@ SamplingContext
DefaultContext
LikelihoodContext
PriorContext
MiniBatchContext
PrefixContext
ConditionContext
```
Expand Down
4 changes: 2 additions & 2 deletions docs/src/internals/varinfo.md
Original file line number Diff line number Diff line change
Expand Up @@ -227,13 +227,13 @@ Continuing from the example from the previous section, we can use a `VarInfo` wi

```@example varinfo-design
# Type-unstable
varinfo_untyped_vnv = DynamicPPL.VectorVarInfo(varinfo_untyped)
varinfo_untyped_vnv = DynamicPPL.untyped_vector_varinfo(varinfo_untyped)
varinfo_untyped_vnv[@varname(x)], varinfo_untyped_vnv[@varname(y)]
```

```@example varinfo-design
# Type-stable
varinfo_typed_vnv = DynamicPPL.VectorVarInfo(varinfo_typed)
varinfo_typed_vnv = DynamicPPL.typed_vector_varinfo(varinfo_typed)
varinfo_typed_vnv[@varname(x)], varinfo_typed_vnv[@varname(y)]
```

Expand Down
17 changes: 7 additions & 10 deletions src/DynamicPPL.jl
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,9 @@ using DocStringExtensions

using Random: Random

# For extending
import AbstractPPL: predict

# TODO: Remove these when it's possible.
import Bijectors: link, invlink

Expand All @@ -39,13 +42,9 @@ import Base:
keys,
haskey

import AbstractPPL: predict

# VarInfo
export AbstractVarInfo,
VarInfo,
UntypedVarInfo,
TypedVarInfo,
SimpleVarInfo,
push!!,
empty!!,
Expand All @@ -55,9 +54,9 @@ export AbstractVarInfo,
acclogp!!,
resetlogp!!,
get_num_produce,
set_num_produce!,
reset_num_produce!,
increment_num_produce!,
set_num_produce!!,
reset_num_produce!!,
increment_num_produce!!,
set_retained_vns_del!,
is_flagged,
set_flag!,
Expand Down Expand Up @@ -93,9 +92,6 @@ export AbstractVarInfo,
# Contexts
SamplingContext,
DefaultContext,
LikelihoodContext,
PriorContext,
MiniBatchContext,
PrefixContext,
ConditionContext,
assume,
Expand Down Expand Up @@ -167,6 +163,7 @@ include("varname.jl")
include("distribution_wrappers.jl")
include("contexts.jl")
include("varnamedvector.jl")
include("accumulators.jl")
include("abstract_varinfo.jl")
include("threadsafe.jl")
include("varinfo.jl")
Expand Down
70 changes: 52 additions & 18 deletions src/abstract_varinfo.jl
Original file line number Diff line number Diff line change
Expand Up @@ -91,36 +91,70 @@ function transformation end

# Accumulation of log-probabilities.
"""
getlogp(vi::AbstractVarInfo)
getlogjoint(vi::AbstractVarInfo)

Return the log of the joint probability of the observed data and parameters sampled in
`vi`.
"""
function getlogp end
getlogjoint(vi::AbstractVarInfo) = getlogprior(vi) + getloglikelihood(vi)
getlogp(vi::AbstractVarInfo) = getlogjoint(vi)

function setaccs!! end
function getaccs end

getlogprior(vi::AbstractVarInfo) = getacc(vi, LogPrior).logp
getloglikelihood(vi::AbstractVarInfo) = getacc(vi, LogLikelihood).logp

function setacc!!(vi::AbstractVarInfo, acc::AbstractAccumulator)
return setaccs!!(vi, setacc!!(getaccs(vi), acc))
end

setlogprior!!(vi::AbstractVarInfo, logp) = setacc!!(vi, LogPrior(logp))
setloglikelihood!!(vi::AbstractVarInfo, logp) = setacc!!(vi, LogLikelihood(logp))

"""
setlogp!!(vi::AbstractVarInfo, logp)

Set the log of the joint probability of the observed data and parameters sampled in
`vi` to `logp`, mutating if it makes sense.
"""
function setlogp!! end
function setlogp!!(vi::AbstractVarInfo, logp)
vi = setlogprior!!(vi, zero(logp))
vi = setloglikelihood!!(vi, logp)
return vi
end
Copy link
Member

@penelopeysm penelopeysm Apr 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about this the other day and thought I may as well post now. The ...logp() family of functions are no longer well-defined in a world where everything is cleanly split into prior and likelihood. (only getlogp and resetlogp still make sense) I think last time we chatted about it the decision was to maybe forward the others to the likelihood methods, but I was wondering if it's actually safer to remove them (or make them error informatively) and force people to use likelihood or prior as otherwise it risks introducing subtle bugs. Backward compatibility is important but if it comes at the cost of correctness I feel kinda uneasy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My hope was that we could deprecate them but provide the same functionality through the new functions, like above. It's a good question as to whether there are edge cases where they do not provide the same functionality. I think this is helped by the fact that PriorContext and LikelihoodContext won't exist, and hence one can't be running code where the expectation would be that ...logp() would be referring to logprior or loglikelihood in particular. And I think as long as one expects to get the logjoint out of ...logp() we can do things like above, shoving things into likelihood, and get the same results. Do you think that solves it and let's us use deprecations rather than straight-up removals, or do you see other edge cases?

Copy link
Member

@penelopeysm penelopeysm Apr 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like this is a case where setlogp is ill-defined:

lp = getlogp(vi_typed_metadata)
varinfos = map((
vi_untyped_metadata,
vi_untyped_vnv,
vi_typed_metadata,
vi_typed_vnv,
svi_typed,
svi_untyped,
svi_vnv,
svi_typed_ref,
svi_untyped_ref,
svi_vnv_ref,
)) do vi
# Set them all to the same values.
DynamicPPL.setlogp!!(update_values!!(vi, example_values, varnames), lp)
end

The logp here contains terms from both prior and likelihood, but after calling setlogp the prior would always be 0, which is inconsistent with the varinfo.

Of course, we can fix this on our end - we would get and set logprior and loglikelihood manually, and we can grep the codebase to make sure that there are no other ill-defined calls to setlogp. We can't guarantee that other people will be similarly careful, though (and us or anyone being careful also doesn't guarantee that everything will be fixed correctly).

Copy link
Member

@penelopeysm penelopeysm Apr 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While looking for other uses of setlogp, I encountered this:

https://github.com/TuringLang/Turing.jl/blob/fc32e10bc17ae3fda4d7e825b6fde45dc7bdb179/src/mcmc/hmc.jl#L201-L234

AdvancedHMC.Transition only contains a single notion of log density, so it's not obvious to me how we're going to extract the prior and likelihood components from it 😓 This might require upstream changes to AdvancedHMC. Since the contexts will be removed, I suspect LogDensityFunction also needs to be changed so that there's a way for it to return only the prior or the likelihood (or maybe it should return both).

(For the record, I'd be quite happy with making all of these changes!)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The logp here contains terms from both prior and likelihood, but after calling setlogp the prior would always be 0, which is inconsistent with the varinfo.

It is inconsistent, but as long as the user only uses getlogp, they would never see the difference, right? If some of logprior is accidentally stored in loglikelihood or vice versa, as long as one is using getlogp and DefaultContext that should be undetectable. What would be trouble is if someone mixes using e.g. setlogp!! and getlogprior, which would require adding calls to getlogprior after upgrading to a version that has deprecated setlogp!!, but probably people would end up doing that. Maybe the deprecation warning could say something about this?

Since the contexts will be removed, I suspect LogDensityFunction also needs to be changed so that there's a way for it to return only the prior or the likelihood (or maybe it should return both).

Yeah, this sort of stuff will come up (and is coming up) in multiple places. Anything that explicitly uses PriorContext or LikelihoodContext would need to be changed to use LogPrior and LogLikelihood accumulators instead. I'm currently doing this for pointwiselogdensities.


function getacc(vi::AbstractVarInfo, ::Type{AccType}) where {AccType}
return getacc(getaccs(vi), AccType)
end

function accumulate_assume!!(vi::AbstractVarInfo, r, logjac, vn, right)
return setaccs!!(vi, accumulate_assume!!(getaccs(vi), r, logjac, vn, right))
end

function accumulate_observe!!(vi::AbstractVarInfo, left, right)
return setaccs!!(vi, accumulate_observe!!(getaccs(vi), left, right))
end

function acc!!(vi::AbstractVarInfo, ::Type{AccType}, args...) where {AccType}
return setaccs!!(vi, acc!!(getaccs(vi), AccType, args...))
end

function acclogprior!!(vi::AbstractVarInfo, logp)
return acc!!(vi, LogPrior, logp)
end

function accloglikelihood!!(vi::AbstractVarInfo, logp)
return acc!!(vi, LogLikelihood, logp)
end

"""
acclogp!!([context::AbstractContext, ]vi::AbstractVarInfo, logp)
acclogp!!(vi::AbstractVarInfo, logp)

Add `logp` to the value of the log of the joint probability of the observed data and
parameters sampled in `vi`, mutating if it makes sense.
"""
function acclogp!!(context::AbstractContext, vi::AbstractVarInfo, logp)
return acclogp!!(NodeTrait(context), context, vi, logp)
end
function acclogp!!(::IsLeaf, context::AbstractContext, vi::AbstractVarInfo, logp)
return acclogp!!(vi, logp)
end
function acclogp!!(::IsParent, context::AbstractContext, vi::AbstractVarInfo, logp)
return acclogp!!(childcontext(context), vi, logp)
end
acclogp!!(vi::AbstractVarInfo, logp) = accloglikelihood!!(vi, logp)

"""
resetlogp!!(vi::AbstractVarInfo)
Expand Down Expand Up @@ -247,11 +281,11 @@ julia> values_as(SimpleVarInfo(data), Vector)
2.0
```

`TypedVarInfo`:
`VarInfo` with `NamedTuple` of `Metadata`:

```jldoctest
julia> # Just use an example model to construct the `VarInfo` because we're lazy.
vi = VarInfo(DynamicPPL.TestUtils.demo_assume_dot_observe());
vi = DynamicPPL.typed_varinfo(DynamicPPL.TestUtils.demo_assume_dot_observe());

julia> vi[@varname(s)] = 1.0; vi[@varname(m)] = 2.0;

Expand All @@ -273,11 +307,11 @@ julia> values_as(vi, Vector)
2.0
```

`UntypedVarInfo`:
`VarInfo` with `Metadata`:

```jldoctest
julia> # Just use an example model to construct the `VarInfo` because we're lazy.
vi = VarInfo(); DynamicPPL.TestUtils.demo_assume_dot_observe()(vi);
vi = DynamicPPL.untyped_varinfo(DynamicPPL.TestUtils.demo_assume_dot_observe());

julia> vi[@varname(s)] = 1.0; vi[@varname(m)] = 2.0;

Expand Down Expand Up @@ -725,7 +759,7 @@ end

# Legacy code that is currently overloaded for the sake of simplicity.
# TODO: Remove when possible.
increment_num_produce!(::AbstractVarInfo) = nothing
increment_num_produce!!(::AbstractVarInfo) = nothing

"""
from_internal_transform(varinfo::AbstractVarInfo, vn::VarName[, dist])
Expand Down
Loading
Loading