You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: HISTORY.md
+19-1Lines changed: 19 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -73,7 +73,13 @@ Now, you can write `@addlogprob (; logprior=x, loglikelihood=y)` to add `x` to t
73
73
74
74
### Removal of `order` and `num_produce`
75
75
76
-
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:
76
+
The `VarInfo` type used to carry with it:
77
+
78
+
-`num_produce`, an integer which recorded the number of observe tilde-statements that had been evaluated so far; and
79
+
-`order`, an integer per `VarName` which recorded the value of `num_produce` at the time that the variable was seen.
80
+
81
+
These fields were used in particle samplers in Turing.jl.
82
+
In DynamicPPL 0.37, these fields and the associated functions have been removed:
77
83
78
84
-`get_num_produce`
79
85
-`set_num_produce!!`
@@ -82,6 +88,18 @@ The `VarInfo` type used to carry with it information about the order in which va
82
88
-`set_retained_vns_del!`
83
89
-`setorder!!`
84
90
91
+
Because this is one of the more arcane features of DynamicPPL, some extra explanation is warranted.
92
+
93
+
`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.
94
+
For example, the particle Gibbs method has a _reference particle_, for which variables are never resampled.
95
+
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.
96
+
97
+
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`.
98
+
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_.
99
+
[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`.
100
+
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.
101
+
The interested reader is referred to that PR for more details.
0 commit comments