-
Notifications
You must be signed in to change notification settings - Fork 162
Description
[This proposal is inspired the thought that we could make Distribution a subtype of GenerativeFunction: #259.]
It might be useful to have a choicemap type for containing a single value, without an address. This may require changing the definition of what a choicemap is slightly. The reason to do this is that generally a choicemap can be thought of as a graph, where each internal node is an address, and the leaf nodes are values. However, since values are not subtypes of ChoiceMap in the implementation, writing algorithms is a made a bit more complicated than it could be otherwise, and the conceptual picture of what a ChoiceMap is is not as elegant as I think it can be.
This new conceptual picture I am proposing is essentially to define a choicemap in the same way one defines a graph. We say a choicemap is an entity which either:
- stores a value
- contains a map from some set of addresses to other choicemaps
Practically speaking, I'm proposing we have something along the lines of:
struct ValueChoiceMap{T} <: ChoiceMap
val::T
end
value(vcm::ValueChoiceMap) = vcm.val
value(cm::ChoiceMap) = error()
submaps(vcm::ValueChoiceMap) = ()
function submaps(cm::ChoiceMap)
Iterators.flatten(
get_submaps_shallow(cm),
(addr => ValueChoiceMap(val) for (addr, val) in get_values_shallow(cm))
)
endThis does not break the current interface, though this value and submap interface seems to me in some sense more fundamental than the get_value, has_value, get_submap, get_values_shallow, get_submaps_shallow interface. We could provide implementations for all the current functions in terms of these value and submaps functions. In many cases these would not be quite as performant, but if we had default implementations in terms of these, users could always add their own more performant versions of other functions.