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
Right now the entire poutine stack is applied at every Pyro primitive site, at least until a block is reached. Although the transparent flag takes care of many use cases we care about, it might be better if each poutine in the stack has to call the next one itself, so that otherwise they are never called at all. In the case where there are two or more non-transparent poutines in the stack, it seems wasteful to draw a sample from one and then immediately discard it at another (and potentially incorrect, if e.g. the stochastic function at the site produces exchangeable not but i.i.d. samples).
To this end, @ngoodman suggested the following changes:
we make available next_pyro_sample(), etc, functions that call the next lower poutine method. if it doesn't get called then lower poutine layers simply don't run; the return value is the prev_val (which no longer needs to be an explicit arg to sample, etc).
instead of having a transparent flag, the default behavior of the base poutine class would be to be transparent. we would provide a poutine.forward that provides the standard non-transparent methods.
The purpose of this issue is to discuss the details of potential changes to the poutine stack. See also #51 .
The text was updated successfully, but these errors were encountered:
For posterity/discussion: our poutine abstraction is very related to algebraic effect handlers, and making this connection more directly may help us really nail the design - see this library code and paper
our poutine abstraction is very related to algebraic effect handlers
Indeed! FWIW, the implementation in that paper is based on free monads, which is something I explored for a PPL over here. (Inspired in part by Practical Probabilistic Programming with Monads.) However, one significant difference is that what I have at present is closed, in the sense used in the paper you link, rather than open like pyro. Let me know if I can help out.
Right now the entire poutine stack is applied at every Pyro primitive site, at least until a block is reached. Although the
transparent
flag takes care of many use cases we care about, it might be better if each poutine in the stack has to call the next one itself, so that otherwise they are never called at all. In the case where there are two or more non-transparent poutines in the stack, it seems wasteful to draw a sample from one and then immediately discard it at another (and potentially incorrect, if e.g. the stochastic function at the site produces exchangeable not but i.i.d. samples).To this end, @ngoodman suggested the following changes:
The purpose of this issue is to discuss the details of potential changes to the poutine stack. See also #51 .
The text was updated successfully, but these errors were encountered: