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
Can we make it easier to select the correct subsets of batched causal variables to compute some cross-world estimand like a treatment effect? This question seems important enough to be addressed before an initial release.
Currently the API is really clunky and relies on unspecified behavior (the ordering of plate dimensions created by MultiWorldCounterfactual), as can be seen in e.g. the definition of ITE in the SLC example:
Y_cf[..., 1, 0, :, :] - Y_cf[..., 0, 1, :, :]
What kind of higher-level interface could we provide for specifying quantities like this that's less error-prone than indexing into the plate dimensions but more tightly scoped in its implementation than named indexing in Funsor?
One possibility: if we were to add an optional name keyword argument to the intervene primitive, we could define a named indexing operator select_world handled by MultiWorldCounterfactual:
Then an expression like the one above could be made unambiguous:
a = intervene(a, a_, name="a")
...
b = intervene(b, b_, name="b")
...
select_world(Y_cf, dict(a=0, b=1)) - select_world(Y_cf, dict(a=1, b=0))
Specifying names for intervention sites could be largely automated in practice by modifying the do handler to use the names of pyro.sample sites supplied to it by a user.
The text was updated successfully, but these errors were encountered:
Can we make it easier to select the correct subsets of batched causal variables to compute some cross-world estimand like a treatment effect? This question seems important enough to be addressed before an initial release.
Currently the API is really clunky and relies on unspecified behavior (the ordering of plate dimensions created by
MultiWorldCounterfactual
), as can be seen in e.g. the definition of ITE in the SLC example:What kind of higher-level interface could we provide for specifying quantities like this that's less error-prone than indexing into the plate dimensions but more tightly scoped in its implementation than named indexing in Funsor?
One possibility: if we were to add an optional name keyword argument to the
intervene
primitive, we could define a named indexing operatorselect_world
handled byMultiWorldCounterfactual
:Then an expression like the one above could be made unambiguous:
Specifying names for intervention sites could be largely automated in practice by modifying the
do
handler to use the names ofpyro.sample
sites supplied to it by a user.The text was updated successfully, but these errors were encountered: