Support commutation check between Pauli-based gates and standard gates

[debasmita2102]

Summary

• Fixes LightCone pass gives index errors unexpectedly #15021 (LightCone einsum panic)
• try_pauli_generator now extracts SparseObservable from PauliEvolutionGate._extract_sparse_observable()

[qiskit-bot]

One or more of the following people are relevant to this code:

• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 22054543433

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 152 of 233 (65.24%) changed or added relevant lines in 4 files are covered.
• 69 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.01%) to 87.932%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
crates/transpiler/src/commutation_checker.rs	14	15	93.33%
crates/quantum_info/src/sparse_observable/standard_generators.rs	136	216	62.96%

Files with Coverage Reduction	New Missed Lines	%
crates/circuit/src/parameter/parameter_expression.rs	1	87.11%
crates/qasm2/src/parse.rs	6	97.63%
crates/transpiler/src/passes/high_level_synthesis.rs	62	87.52%

Totals
Change from base Build 21919504599:	-0.01%
Covered Lines:	100434
Relevant Lines:	114218

---

💛 - Coveralls

[Shobhit21287]

Hi Debasmita! Since you already used an enum for the standard gates, do you think it would be a good idea to maybe restructure this a bit and use a match statement instead to enforce that all gates have a valid representation, else it might just throw an indexing error in the future?

[Cryoris]

The introduced StandardGate enum above should just be a placeholder, instead we should use the existing StandardGate enum in operation.rs that defines all standard gates. It's fine to use a lookup table if it contains all standard gates, since we know the indices are valid 🙂

[Cryoris]

Once we're satisfied with the pipeline, meaning that (1) the light cone pass works for large numbers of qubits and (2) the ASV benchmarks show we are not slower, then we should add all other standard gates here.

[debasmita2102]

@Cryoris

"Could you add a test that checks that the light cone pass now works for a case that didn't work before? E.g. the one described in #15021 " ---does this solves the case?

[Cryoris]

Yeah that's the right direction 👍🏻 Two small comments on that test below

[Cryoris]

Reminder that we want to change this into a static lookup table for all StandardGates

[debasmita2102]

Yes, I will modify this file to use a static array (like GENERATOR_LUT) for mapping standard gates to bit terms, instead of the match statement.

[debasmita2102]

Ran the ASV benchmarks:

Benchmarks show no regression. Performance is either identical (ratio 1.00) or slightly improved (ratio ~0.94)

Benchmark	Qubits	Ratio (lightcone-fix / main)	Status
track_square_heisenberg_depth	480	1.00	Identical
time_heavy_hex_trivial	57	1.05	Stable
time_grid_line	121	0.93	Faster
time_heavy_hex_line	1081	0.94	Faster

Note on Timeouts:
Timeouts (>20s) occurred on the most extreme case (heavy_hex_line with 1081 qubits).
This affected both branches, confirming it is an existing constraint and not a regression introduced by this PR according to me.

[ShellyGarion]

Hi @debasmita2102 - thanks for this PR!
I have a few suggestions.

[ShellyGarion]

I checked all 2-qubit gates and added a few comments and suggestions.

In order to check the commutativity, I cheked commutativity with all 2-qubit paulis.
Perhaps it's worth to add this as a test? (for all 1-qubit and 2-qubit gates, and partially for 3-4-5 qubit gates)?

for pauli in ['XX', 'XY', 'XZ', 'YY', 'YX', 'YZ', 'ZZ', 'ZX', 'ZY', 'IX', 'IY', 'IZ', 'XI', 'YI', 'ZI']: # all 15 non-trivial paulis
    evo = PauliEvolutionGate(SparsePauliOp(pauli), time=1.0)
    print (pauli, scc.commute(CXGate(), [0, 1], [], evo, [0, 1], []), 
           Pauli(pauli).commutes(Pauli('XI')) & Pauli(pauli).commutes(Pauli('IZ')) & Pauli(pauli).commutes(Pauli('XZ'))) 

P.S. I think that the test suggested by Alexander Ivrii below is actually better and more accurate, as it compares the exact operators. Commutativity tests may fail if we take sums of Paulis for example.
So, you don't need to implememnt these tests.

[ShellyGarion]

RGate has 2 parameters, so I don't think this check is enough.
Like other gates with more than 1-parameter (U2, U3, U, CU) - perhaps we should skip it?

[ShellyGarion]

we should be more careful with XXMinusYY, XXPlusYY since they have 2 parameters (theta, beta).
If beta=0, then it seems to be correct.
otherwise, I'm not sure what happens. Perhaps we should skip it?

[ShellyGarion]

I don't think it is correct.

[alexanderivrii]

Hi @debasmita2102. I think it would be very useful to expose the generator_observable method that you have implemented as a part of this PR to Python. At least I would be very happy to use it myself.

For context, this method computes the generator of a standard gate and returns it as a SparseObservable. For example, $H = e^{-i ((X+Z)/(2\sqrt 2))}$, possibly up to a global phase. This would also allow to include Python tests that the generators are computed correctly.

In terms of the implementation details, I think it makes sense to move the standard_generators.rs file to quantum_info. The method generator_observable can be exposed just by adding the #[pyfunction] macro.

You should do the other standard stuff, like adding

pub fn standard_generators(m: &Bound<PyModule>) -> PyResult<()> {
    m.add_wrapped(wrap_pyfunction!(generator_observable))?;
    Ok(())
}

to standard_generators.rs file, and adding the line

add_submodule(m, ::qiskit_quantum_info::standard_generators::standard_generators, "standard_generators")?;

to crates/pyext/src/lib.rs. I am not claiming that this particular way to expose the code is the best possible, and you can probably improve on this.

In any case, this allows to call your code from Python, in the following way:

from qiskit._accelerate import standard_generators
gate_class = HGate
gen = standard_generators.generator_observable(gate_class._standard_gate)
print(gen)

with the output being

<SparseObservable with 2 terms on 1 qubit: (1+0j)(X_0) + (1+0j)(Z_0)>

Note that this is currently slightly incorrect as the terms in the generator are missing the $\pi/ (2\sqrt 2)$ factors.

Copying @ShellyGarion's suggestion from an offline discussion, we would then be able to check the correctness of the generator gen by creating the corresponding Pauli Evolution Gate and comparing the operators:

evo = PauliEvolutionGate(gen, time=1)
ok = Operator(gate_class()).equiv(Operator(evo))  # check equality up to the global phase

Does this make sense?

[ShellyGarion]

Following @alexanderivrii comment, I think we should be more careful and add signs here, if we want the generators to be equivalent to the corresponsing gate (otherwise, commutativity may fail for higher order Pauli terms).
e.g., for CX gate:

op1 = SparsePauliOp('XZ')-SparsePauliOp('XI')-SparsePauliOp('IZ')
ev1 = PauliEvolutionGate(op1, time=np.pi/4)
print (Operator(CXGate()).equiv(Operator(ev1))) #= True

[ShellyGarion]

Adding more gates equivalences:

op1 = SparsePauliOp('XZ')-SparsePauliOp('XI')-SparsePauliOp('IZ') // CX and CSX
op2 = SparsePauliOp('YZ')-SparsePauliOp('YI')-SparsePauliOp('IZ') // CY 
op3 = SparsePauliOp('ZZ')-SparsePauliOp('ZI')-SparsePauliOp('IZ') // CZ and CS and CSdg

e_CY = PauliEvolutionGate(op2, time=np.pi/4)
e_CZ = PauliEvolutionGate(op3, time=np.pi/4)
e_CSX = PauliEvolutionGate(op1, time=-np.pi/8)
e_CS = PauliEvolutionGate(op3, time=-np.pi/8)
e_CSdg = PauliEvolutionGate(op3, time=np.pi/8)

print (Operator(CYGate()).equiv(Operator(e_CY)))
print (Operator(CZGate()).equiv(Operator(e_CZ)))
print (Operator(CSXGate()).equiv(Operator(e_CSX)))
print (Operator(CSGate()).equiv(Operator(e_CS)))
print (Operator(CSdgGate()).equiv(Operator(e_CSdg)))


op0 = SparsePauliOp('IX')-SparsePauliOp('XY')  // ECR
op1 = SparsePauliOp('XX')+SparsePauliOp('YY')+SparsePauliOp('ZZ') // Swap
op2 = SparsePauliOp('XX')+SparsePauliOp('YY') // iSwap

e_ECR = PauliEvolutionGate(op0, time=np.pi/(2*np.sqrt(2)))
e_Swap = PauliEvolutionGate(op1, time=np.pi/4)
e_iSwap = PauliEvolutionGate(op2, time=-np.pi/4)

print (Operator(ECRGate()).equiv(Operator(e_ECR)))
print (Operator(SwapGate()).equiv(Operator(e_Swap)))
print (Operator(iSwapGate()).equiv(Operator(e_iSwap)))

[ShellyGarion]

More equivalences for the parametric gates - note that there should be a factor that depends of the angle ("t"):

op1 = -t/4 * SparsePauliOp('XZ') + t/4 * SparsePauliOp('XI') # CRX
op2 = - t/4 * SparsePauliOp('YZ') + t/4 * SparsePauliOp('YI') # CRY
op3 = - t/4 * SparsePauliOp('ZZ') + t/4 * SparsePauliOp('ZI') # CRZ
op4 = - t/4 * SparsePauliOp('ZZ') + t/4 * SparsePauliOp('ZI') + t/4 * SparsePauliOp('IZ') # CPhase


e_CRX = PauliEvolutionGate(op1, time=1)
e_CRY = PauliEvolutionGate(op2, time=1)
e_CRZ = PauliEvolutionGate(op3, time=1)
e_CP = PauliEvolutionGate(operator=op4, time=1)

print (Operator(CRXGate(t)).equiv(Operator(e_CRX)))
print (Operator(CRYGate(t)).equiv(Operator(e_CRY)))
print (Operator(CRZGate(t)).equiv(Operator(e_CRZ)))
print (Operator(CPhaseGate(t)).equiv(Operator(e_CP)))


op_plus = t/4 * SparsePauliOp('XX') + t/4 * SparsePauliOp('YY') # XXPlusYY with beta=0 
op_minus = t/4 * SparsePauliOp('XX') - t/4 * SparsePauliOp('YY') # XXMinusYY with beta=0

e_plus =  PauliEvolutionGate(operator=op_plus, time=1)
e_minus =  PauliEvolutionGate(operator=op_minus, time=1)

print (Operator(XXPlusYYGate(t, 0)).equiv(Operator(e_plus)))
print (Operator(XXMinusYYGate(t, 0)).equiv(Operator(e_minus)))

[ShellyGarion]

btw, for H the equivalence is:

opH = SparsePauliOp('X') + SparsePauliOp('Z')
eH = PauliEvolutionGate(opH, time=np.pi/(2 * np.sqrt(2)))
print (Operator(HGate()).equiv(Operator(eH)))

For all gates that are equivalent Pauli rotation gates (i.e. have a single Pauli term), it's the same equvialence as in #15502

[ShellyGarion]

This PR is almost ready now, only a few more comments.

[ShellyGarion]

is there a reason for the change in this line?

[debasmita2102]

The switch to saturating_sub(1) I thought for a safety fix for when an operator has no qubits (like a standalone global phase). Previously, the code used (num_qubits - 1) , which can cause a crash in Rust if the count is 0. By using saturating_sub(1), it just returns 0 . I locally tested this with a zero-qubit scalar operator and it works smoothly.4

[ShellyGarion]

I think the file "bicycle-architecture-compiler" does not belong to this PR

[ShellyGarion]

LGTM. Thank you very much @debasmita2102 for all the effort!
I'll wait with approving and merging this PR to see if @alexanderivrii or @Cryoris have any further comments.

[jakelishman]

Was any of this code generated by an LLM? There are multiple definitions of the same pyfunction, code comments that sound suspiciously like an LLM talking to itself (including saying things like "Wait, Shelly likes ...") and things that look very look automatically generated code and test cases.

If so: this very much needs an LLM attribution prominently in the PR comment, and all the code blocks that were generated by LLM need attribution to the LLM and the model/version used.

I think it might be a good idea to revert this and fix it up a bit more before re-merging. I'd rather the LLM attributions go in in exactly the same commit, so it's easier to trace through the git tracking.

[debasmita2102]

@jakelishman Thanks for this details, yes, I was experimenting with GitHub Copilot (using the Claude 4.5 Haiku model via VS Code) with some review comments and in the process, I missed a few 'internal thought' comments and redundant function wrappers in place. Cleaned it up. Also mentioned the AI attribution in those files. For example
"""
AI attribution:
Portions of the test_clifford_gates_have_generators are developed with assistance from
GitHub Copilot integrated in VS Code. The underlying model : Claude Haiku 4.5.
"""

What are the steps next? Will it be a new PR? The reason I understand (attribution about AI will remain in the same commit).