Is the BayesianNetwork do operator mathematically correct?

[gweesip]

From the docs, the BayesianNetwork.do method:

Applies the do operation. The do operation removes all incoming edges to variables in nodes and marginalizes their CPDs to only contain the variable itself.

But the DAG.do method:

... has the effect of removing all edges from the parents of X and setting X to the given value x.

I believe the DAG interpretation of the do operator is correct and since the underlying graph of a BeyesianNetwork is a DAG, it doesn't really make sense to me that they are different operations. Furthermore, neither of these methods currently allow you to specify a value for the do variable, so we are missing the second half of the effect specified. The BayesianNetwork version marginalizes out all the other variables, but this doesn't have the effect of "setting X to the given value x" either.

edit: If using this for inference on an modified model, there is a simple workaround of simply adding the variable and value to the evidence of a query, but this is an easy thing to miss/forget, especially if you assume that the do operator has already handled it.

[ankurankan]

@gweesip I believe the method that you are actually looking for is CausalInference.query. That allows for setting specific values for the intervention variables.

The idea behind having a do method for DAG/BN was to allow for network structure level analysis for interventions. But I do agree that this has become confusing with do methods for both DAG and BNs. I think a potential solution could be keep the do method for DAG as it is right now (and fix the documentation), and change the BN one to allow specifying values for the do variables. What do you think?

[gweesip]

@ankurankan I am aware of the CausalInference.query and I normally use that. I don't remember exactly what the use case was that tipped me off to this. I think I was just trying to validate that the answer I got from the query matched the answer I got from modifying the network first and then performing a query.

It was mostly just a question of why the CPD was being marginalized, but if the use case of the BayesianNetwork.do was simply network structure analysis, this may have just been the easiest way of decoupling the variable from its parents? I'm not sure if there's a convenient way setting the value other than going into the CPD values and modify those directly.

I think it'd be worthwhile to make the do methods consistent with the definition of the do operator. In the case of DAGs, there aren't really any values associated with the variables anyway, so maybe the documentation should highlight this as a structural change only. For the BayesianNetwork.do the update should account for the fact that the variable takes the assigned value with certainty (ie: changing the values in the CPD).

[ankurankan]

@gweesip

It was mostly just a question of why the CPD was being marginalized, but if the use case of the BayesianNetwork.do was simply network structure analysis, this may have just been the easiest way of decoupling the variable from its parents?

Yeah, I can't think of any other obvious ways to do this. I also think that marginalizing the variables make sense as doing a probabilistic inference on this modified network is equivalent to doing a do operation (with value specified) on the original network.

I think the best way to clarify all this would be to make the method documentations clearer. Please feel free to create an issue for this if you would like :).

[gweesip]

@ankurankan After a bit more review and thought, I have the following.

First, going back to why I was doing this in the first place, I was playing around with the rules of Do-calculus, Rule 2: Action/Observation exchange.

I also think that marginalizing the variables make sense as doing a probabilistic inference on this modified network is equivalent to doing a do operation (with value specified) on the original network.

I think I see what you're saying here. Took me a while to wrap my head around the theory behind this, but I think I see it now. Performing a BayesianNetwork.do essentially does the graph surgery part of the action/observation exchange equation, but you still have to explicitly query with the evidence to get what you're looking for.

Going back to how you might include a value in the do operation, which I think would make sense for a BayesianNetwork (given that the key difference between a normal DAG and a BayesianNetwork is that the BayesianNetwork has values associated to the variables. Essentially, a BayesianNetwork is a DAG with CPDS which comes directly from the BayesianNetwork.__init__() function). This could be handled as follows:

1. Include the value of the variable as an optional argument in BayesianNetwork.do (this makes the change backwards compatible).
2. Add a property to the BayesianNetwork class that can track/maintain any evidence passed to it. If a do is called with a value, the variable and value gets stored inside the model, which can also be leveraged by an Inference object.
3. Any queries can automatically check the property for tracked evidence and include that in the query (i.e.: the evidence passed to the query is merged with the tracked evidence before the query is performed).

All said and done, not sure that the value added by this change justifies the work and potential issues it might create for others. Maybe there's a better solution to this (Subclass/Mixin for models to track evidence?), but I think I'd agree the best solution is to simply make the documentation more clear. Maybe even a tutorial notebook to demonstrate and relate the code back to the theory. Thoughts?