Add fault edge #360
Add fault edge #360
Conversation
y-richie-y
force-pushed
the
fault-edge
branch
from
649906b to
d93e068
Compare
y-richie-y
force-pushed
the
fault-edge
branch
from
d93e068 to
8018c12
Compare
RazinShaikh
left a comment
RazinShaikh
left a comment
There was a problem hiding this comment.
There are still several places in the code that needs to be updated. You should do a find for "EdgeType." and update the relevant methods.
y-richie-y
force-pushed
the
fault-edge
branch
from
d4f54ef to
a433604
Compare
|
This might be a bit late to the party, but I also had a discussion with I believe Ben and Jackie that fault-edge should maybe not be an edge type, but be an annotation we add onto an edge. This allows for more flexibility when we add different noise models, and also means we don't have to add a separate fault-edge for for instance hadamard-edges. A benefit of the current approach though is that using fault-edges means that automatically all the other types of rewrites don't match so you don't do acidental non-fault-tolerant rewrites. So maybe we should just have a fault-edge type, and then later on we can still use edge annotations for more complicated noise models. |
|
The edge annotations can go on these fault-edges as edge_data. The rewrites on the fault-edges can be defined according to the noise models that interpret the edge data appropriately. This approach avoids matching rewrites for ideal (aka simple) edges regardless of the noise model. |
RazinShaikh
left a comment
RazinShaikh
left a comment
There was a problem hiding this comment.
I didn't check every rewrite rule but a lot of them are broken. I have given a few examples below. There are many places in the code that assumes that an edge is either a simple edge or a hadamard edge. So the rewrites involving fault-edge either behaves incorrectly or simply fail. Moreover, whenever you see "etab" that is likely to fail with fault-edge as that dictionary assumes the simple-hadamard duopoly. You probably need to check through all the methods and see if they work when the diagram has a fault edge.
| elif et == EdgeType.HADAMARD: | ||
| etab[upair(n,w2)] = [0,1] | ||
| else: | ||
| raise ValueError(f"Cannot apply Pauli commutation through {et} edge") |
There was a problem hiding this comment.
Raising the ValueError here breaks the rewrite. Consider the following diagram where we want to push the pauli. Since the pauli matcher has not been modified, the rewrite will be matched but when you apply the rewrite, it will fail. So you need to either add the correct edge type when pushing pauli or modify the pauli matcher to not match when fault edges are involved.
| def bialgebra(g: BaseGraph[VT,ET], | ||
| matches: List[Tuple[VT,VT]] | ||
| ) -> rules.RewriteOutputType[VT,ET]: | ||
| rem_verts = [] |
There was a problem hiding this comment.
Applying the bialgebra rule changes the fault edge to a hadamard edge.
| return [v for v in candidates if types[v] == VertexType.Z] | ||
|
|
||
|
|
||
| def color_change(g: BaseGraph[VT,ET], matches: List[VT]) -> rules.RewriteOutputType[VT,ET]: |
There was a problem hiding this comment.
Color change matches when one of the edge is a fault-edge but applying the rewrite fails due to an error caused by the toggle_edge method
| other_vertex = v0 | ||
| new_e = (v0, other_vertex) | ||
| if new_e not in etab: etab[new_e] = [0,0] | ||
| etab[new_e][g.edge_type(e)-1] += 1 |
There was a problem hiding this comment.
"list index out of range" when the diagram has a fault-edge. I believe any time you see "etab", the rewrite is going to fail if the diagram has fault-edge/
3 participants
In relation to the discussion in #358, I've added a very basic implementation of fault edges in pyzx which doesn't allow any rewrites. This enables to open a corresponding PR in zxlive.