Skip to content

Commit 9b2bee0

Browse files
penelopeysmmhauru
authored andcommitted
Expand on upstream pMCMC changes
1 parent 5c3383b commit 9b2bee0

File tree

1 file changed

+19
-1
lines changed

1 file changed

+19
-1
lines changed

HISTORY.md

Lines changed: 19 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -74,7 +74,13 @@ Now, you can write `@addlogprob (; logprior=x, loglikelihood=y)` to add `x` to t
7474

7575
### Removal of `order` and `num_produce`
7676

77-
The `VarInfo` type used to carry with it information about the order in which variables had been evaluated, and a variable called `num_produce` for where in this evaluation the `VarInfo` was at. This was used in particle samplers in Turing.jl. The particle sampler code has been simplified and no longer needs this functionality, and thus we remove it from DynamicPPL. The following exported functions are now gone:
77+
The `VarInfo` type used to carry with it:
78+
79+
- `num_produce`, an integer which recorded the number of observe tilde-statements that had been evaluated so far; and
80+
- `order`, an integer per `VarName` which recorded the value of `num_produce` at the time that the variable was seen.
81+
82+
These fields were used in particle samplers in Turing.jl.
83+
In DynamicPPL 0.37, these fields and the associated functions have been removed:
7884

7985
- `get_num_produce`
8086
- `set_num_produce!!`
@@ -83,6 +89,18 @@ The `VarInfo` type used to carry with it information about the order in which va
8389
- `set_retained_vns_del!`
8490
- `setorder!!`
8591

92+
Because this is one of the more arcane features of DynamicPPL, some extra explanation is warranted.
93+
94+
`num_produce` and `order`, along with the `del` flag in `VarInfo`, were used to control whether new values for variables were sampled during model execution.
95+
For example, the particle Gibbs method has a _reference particle_, for which variables are never resampled.
96+
However, if the reference particle is _forked_ (i.e., if the reference particle is selected by a resampling step multiple times and thereby copied), then the variables that have not yet been evaluated must be sampled anew to ensure that the new particle is independent of the reference particle.
97+
98+
Previousy, this was accomplished by setting the `del` flag in the `VarInfo` object for all variables with `order` greater or equal to than `num_produce`.
99+
Note that setting the `del` flag does not itself trigger a new value to be sampled; rather, it indicates that a new value should be sampled _if the variable is encountered again_.
100+
[This Turing.jl PR](https://github.com/TuringLang/Turing.jl/pull/2629) changes the implementation to set the `del` flag for _all_ variables in the `VarInfo`.
101+
Since the `del` flag only makes a difference when encountering a variable, this approach is entirely equivalent as long as the same variable is not seen multiple times in the model.
102+
The interested reader is referred to that PR for more details.
103+
86104
**Internals**
87105

88106
### Accumulators

0 commit comments

Comments
 (0)