Qiskit / qiskit-fermions / 30746828464

98%

push

github

fix(operators): only anticommute edge operators sharing exactly one mode (#255)

`EdgeVertexOperator::normal_ordered` classified any two edge operators with
overlapping support as anticommuting, using `!= 4` on the set of the four
involved mode indices. That condition means "share *at least* one mode", which
wrongly includes the case where both modes coincide -- `E_jk` against `E_jk` or
`E_kj`. Those commute: `E_kj = -E_jk`, so the pair is collinear, and every
operator commutes with itself.

Because the misclassification only mattered once the sort actually swapped the
two factors, it silently produced a *different operator* rather than merely a
non-canonical form: normal-ordering changed the operator's matrix for 270 of
4368 terms of length <= 3 over 4 modes. Against Jordan-Wigner matrix ground
truth the shipped rule misclassified 24 of 256 ordered generator pairs at 4
modes; testing for an overlap of exactly one mode is correct for all of them,
verified exhaustively at 3, 4 and 5 modes and across all four
vertex/edge branch combinations.

The reason this survived is that both the docstring summary and the tests were
derived from Eq. (5) of arXiv:2512.11418v1, which is stated only for
`j != k != l != m`. None of its five relations covers the share-both-modes
case, so mirroring them faithfully left exactly that gap. Two existing tests
had in fact encoded the bug instead of catching it, and are corrected here to
use genuinely distinct indices so that they test the relation they name:

- the Rust `test_normal_ordered_gandon_rel2` asserted a sign flip for
  `E_{1,0} E_{0,1}`, i.e. `j,k,l = 1,0,1`, violating the relation's own
  precondition;
- the Python `test_anti_commutator` subtest for the same relation asserted
  `{E_{0,1}, E_{1,0}} = 0`, which is false -- that anticommutator has norm 8,
  and it only vanished because the buggy parity rule introduced a spurious
  cancellation.

`TransferVertexOperator` uses a different test in the corresponding branc... (continued)

30 of 30 new or added lines in 1 file covered. (100.0%)

11112 of 11320 relevant lines covered (98.16%)

293.5 hits per line