Open fritzo opened 4 years ago
Perhaps
poutine.block
should merely block tracing? Are there other cases for a more limitedpoutine.block_tracing
?
I don't see any reason to change the behavior of block
right now, since it's used for things that aren't just nesting inference, but I guess we could add a separate block_tracing
that has the behavior you're looking for. The special case of block_tracing
added in #2289 is specific to auxiliary variables introduced by inference algorithms, which are not expected to be observed or replayed, but a generic block_tracing
would interact with replay
, condition
, do
and other effect handlers. Since those issues are rather abstract, I would prefer to start from a more general or unified design for nested inference and add or change effect handler behavior to support that.
poutine.do #2157 now uses site["stop"] = True (like poutine.block), thereby blocking broadcasting of the intervened site. Is the current implementation correct in the presence of multiple-sample inference algorithms, e.g. where the intervention depends on an upstream sampled variable?
poutine.do
currently only supports setting the site's value to a constant, which doesn't need to be broadcasted, and adds an auxiliary site that behaves in the usual broadcasting-aware way. As with the nested inference case, I would prefer to start from a more general design for causal and counterfactual inference under a larger class of interventions and add or change behavior to support that. It's certainly true that some changes will be necessary - for example, as you say, the current use of stop
would be incorrect for stochastic interventions.
Nested inference #1227 requires
poutine.block
ing of nested inference, but these nested inference algorithms should arguably respect outermostpoutine.broadcast
and possiblypoutine.independent
. (Note the non-broadcasted TMC versions are also interesting, but are not the only- and not the simplest- way to nest inference.)The
ConjugateReparam
#2289 needs to sample an internal variable in a broadcast-aware way, but it appears the math in SVI and HMC is correct when this internal variable is removed from the trace (at least for reparameterized variables; the non-reparameterized case is more subtle and may requirepyro.factor
with DiCE factors; TBD). I believe this_do_not_trace
hack could be removed ifpoutine.block
did not blockbroadcast
andindependent
. IndeedConjugateReparam
can be seen as nesting exact inference inside SVI, similar to #1227.poutine.do
#2157 now usessite["stop"] = True
(likepoutine.block
), thereby blocking broadcasting of the intervened site. Is the current implementation correct in the presence of multiple-sample inference algorithms, e.g. where the intervention depends on an upstream sampled variable?Perhaps
poutine.block
should merely block tracing? Are there other cases for a more limitedpoutine.block_tracing
?