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
[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:
This 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.
The text was updated successfully, but these errors were encountered:
georgematheos
changed the title
Simplify choicemaps via "value
Simplify choicemaps via "value choicemaps"
May 12, 2020
Ah, maybe I should have put #263 (comment) here. TLDR: 👍, with the suggestion that "with no address" be reframed as "with empty key-path" aka "at nesting level zero."
[This proposal is inspired the thought that we could make
Distribution
a subtype ofGenerativeFunction
: #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 aChoiceMap
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:
Practically speaking, I'm proposing we have something along the lines of:
This does not break the current interface, though this
value
andsubmap
interface seems to me in some sense more fundamental than theget_value, has_value, get_submap, get_values_shallow, get_submaps_shallow
interface. We could provide implementations for all the current functions in terms of thesevalue
andsubmaps
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.The text was updated successfully, but these errors were encountered: