|
| 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 | + |
1 | 50 | module AbstractPPLDistributionsExt
|
2 | 51 |
|
3 | 52 | using AbstractPPL: AbstractPPL, VarName, Accessors
|
|
0 commit comments