Skip to content

Commit 49922f0

Browse files
committed
Add a docstring to the extension
1 parent e20190c commit 49922f0

File tree

1 file changed

+49
-0
lines changed

1 file changed

+49
-0
lines changed

ext/AbstractPPLDistributionsExt.jl

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,52 @@
1+
"""
2+
AbstractPPLDistributionsExt
3+
4+
This extension provides extra methods for `hasvalue` and `getvalue`,
5+
specifically, to deal with cases where a dictionary may not have mappings for
6+
*complete* variables (e.g. `x` where `x` is a vector or matrix), but may have
7+
mappings for *individual elements* of that variable.
8+
9+
In such a case, it is necessary to verify that all elements of that variable
10+
are present in the dictionary. Doing this requires some knowledge of the shape
11+
of `x`, which in this extension, is inferred from the distribution that `x` is
12+
to be sampled from, leading to these two methods:
13+
14+
getvalue(vals, vn, dist)
15+
hasvalue(vals, vn, dist)
16+
17+
The functionality in this extension should, in general, not be used unless
18+
absolutely necessary. For example, if the dictionary was provided by a user,
19+
the user should be expected to provide a single value for `x` rather than
20+
individual elements. To accomplish this, the original two-argument
21+
implementations
22+
23+
getvalue(vals, vn)
24+
hasvalue(vals, vn)
25+
26+
should be used.
27+
28+
This extension primarily exists because in MCMCChains.jl, each individual
29+
element of `x` will be stored separately. Information about the original shape
30+
of `x` is lost once a `Chains` object has been created. Thus, reconstructing
31+
the original values of `x` requires the use of the three-argument methods in
32+
this extension.
33+
34+
Rather than placing this functionality in MCMCChains.jl (e.g. in an
35+
MCMCChainsAbstractPPLExt), it is placed here for several reasons:
36+
37+
1. So that it is close to the original implementation of `hasvalue` and
38+
`getvalue`.
39+
40+
2. It is possible that other packages (potentially yet to be created) may also
41+
contain lossy methods of storing variable information, and thus may also
42+
need this functionality.
43+
44+
3. AbstractPPL is probably the most natural place to host this functionality,
45+
since these methods work purely on `VarName` objects.
46+
47+
This decision may be revisited in the future.
48+
"""
49+
150
module AbstractPPLDistributionsExt
251

352
using AbstractPPL: AbstractPPL, VarName, Accessors

0 commit comments

Comments
 (0)