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 issue tracks design choices about the relationship between ReparamMessenger and other messengers that set msg["value"] such as InitMessenger, ConditionMessenger, and ReplayMessenger.
The problem is that poutine.reparam is usually applied directly to a model, often inside the model at a specific site, whereas the value-setting effect handlers are usually applied as part of inference or prediction, after or outside of poutine.reparam. As a result, the model has already been rewritten by the time a value-modifying handler sees its target sample site. This situation would be fine in a fully general lightweight effect handler system where handlers could arbitrarily modify the effects of other handlers, but Pyro's effect handlers are organized around the simplifying concept of a handler stack, limiting effects to a small safe set of application orders. Thus solutions to this issue will need to work around the stack, e.g. by adding additional global handler state, directly inspecting the stack, or applying messengers out-of-stack-order.
This issue tracks design choices about the relationship between
ReparamMessenger
and other messengers that setmsg["value"]
such asInitMessenger
,ConditionMessenger
, andReplayMessenger
.The problem is that
poutine.reparam
is usually applied directly to a model, often inside the model at a specific site, whereas the value-setting effect handlers are usually applied as part of inference or prediction, after or outside ofpoutine.reparam
. As a result, the model has already been rewritten by the time a value-modifying handler sees its target sample site. This situation would be fine in a fully general lightweight effect handler system where handlers could arbitrarily modify the effects of other handlers, but Pyro's effect handlers are organized around the simplifying concept of a handler stack, limiting effects to a small safe set of application orders. Thus solutions to this issue will need to work around the stack, e.g. by adding additional global handler state, directly inspecting the stack, or applying messengers out-of-stack-order.Tasks
ReparamMessenger
compatible withInitMessenger
, for AutoGuides and MCMC (higher priority)init_to_value
inNeuTraReparam
init_to_value
inStructuredReparam
ReparamMessenger
compatible withConditionMessenger
for posterior predictive sampling (lower priority)The text was updated successfully, but these errors were encountered: