Open eliewolfe opened 5 months ago
apozas
commented
5 months ago Can't we handle this with small changes in the building of notcomm? This sounds like something that should be reasonably easy to implement by slightly modifying the loop of InflationProblem.py#L236
eliewolfe
commented
5 months ago That was my instinct as well, at first, but no. The matrix of noncommutation relations is built up at the moment using the 3d tensor InflationProblem.sources_to_check_for_party_pair_commutation.
In the example I have in mind:
Suppose we take two operators, both associated with distinct children of the intermediate latent, and the two operators have have partially-overlapping copy indices relative to sources which are parents of this (nonclassical) intermediate latent. These commute.
Suppose we take two operators, both associated with the same child of the intermediate latent, and the two operators have have partially-overlapping copy indices relative to sources which are parents of this (nonclassical) intermediate latent. These commute if any only if they share the same private setting. This sort of information cannot be encoded in sources_to_check_for_party_pair_commutation.
As such, I think the better solution is not to modify the behavior of the building of notcomm, but rather to throw an exception.
Note that there is no loss of generality in functionality. A DAG with a nonclassical intermediate latent with all classical parents is equivalent to a different DAG with a new quantum source, by the "exogenization" procedure (in any physical theory).
Suppose L-->Q-->A, where L is a classical source and Q is a quantum (or any nonclassical) intermediate latent. Operators association with A for different settings should not commute, but our current code would not pick up on this.
I propose we add an assertion that every intermediate latent which is nonclassical must have some nonclassical source parent.