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
The _anti_commutation_graph function which is used by group_ops in AbelianGrouper sometimes returns anti commutation graphs which has edges with commutable operators instead of anti-commutable operators.
Below, acg is the anti commutation graph for sparse_pauli. acg contains (1,2) which corresponds to the Sparse Pauli operators ('XX', (coeff)) and ('YY', (coeff)) which are commutable. Therefore, (1,2) should not be in the anti commutation graph.
I think it may not be worth fixing this bug. I don't know the origin anyway. It depends on how when the PauliList PR is merged (#5993) and when a PR for #6624 might be ready.
What does qubit-wise commutativity mean? Each pair of qubits must commute? Doesn't this mean only identical strings commute?
EDIT: Ok. Isha showed me an explanation.
Yes. for example, XI and XX are qubit-wise commutable.
This concept is introduced in https://arxiv.org/abs/1704.05018.
They said grouping into TPB sets.
Information
What is the current behavior?
The _anti_commutation_graph function which is used by group_ops in AbelianGrouper sometimes returns anti commutation graphs which has edges with commutable operators instead of anti-commutable operators.
Below,
acg
is the anti commutation graph forsparse_pauli
.acg
contains(1,2)
which corresponds to the Sparse Pauli operators('XX', (coeff))
and('YY', (coeff))
which are commutable. Therefore,(1,2)
should not be in the anti commutation graph.Steps to reproduce the problem
What is the expected behavior?
The _anti_commutation_graph function should only return edges which have operators that are not commutable.
Note: Fixing #6624 would also fix this issue for group_ops implemented with PauliLists.
The text was updated successfully, but these errors were encountered: