Extend litinski transformation for all Pauli rotations by ShellyGarion · Pull Request #15974 · Qiskit/qiskit

ShellyGarion · 2026-04-09T07:51:09Z

Summary

Extend Litinski transformation for the Pauli rotations RX and RY.
Extend Litinski transformation for PPR and PPM.

Close #15862

Details and comments

In order to support PPR/PPM, this PR should include the following functions and methods:

clifford.evolve_single_qubit_pauli - evolve a single qubit pauli (X,Y,Z) by the given Clifford
pauli_compose(P1, P2) - a function that composes two n-qubit paulis P1 and P2
evolve_pauli_by_clifford(P, C) - a function that uses the above in order to evolve an n-qubit pauli P by a clifford C

The functions above part were moved to #16137, and this PR should be based on #16137 (DensePauli class)

update the Litinski transform for PPM and PPR, which shall use the evolved pauli.
update the litinski transform to treat RZ/RX/RY with pi/2 angles as Clifford gates
update the litinski transform to treat PPR with pi/2 angles as Clifford gates

This PR should therefore replace #14677
This PR should be based on #16137 (DensePauli class)

In a follow up PR, we shall better organize and extend the functionality in rust of the DensePauli and Clifford classes.

alexanderivrii

Thanks Shelly for starting this work. Though what we want is a bit more general that what you have right now: we would like to evolve an arbitrary (multi-qubit) Pauli under a Clifford, that is given $P$ finding $Q$ such that $P C = C Q$, and to extend LitinskiTransformation to handle circuits with PPR and PPM gates.

alexanderivrii · 2026-04-19T10:37:49Z

Thanks Shelly, I agree that we really-really need a good Rust structure for representing Paulis, and this is a really great start.

It's still not completely clear to me how exactly you are planning to use it for extending Litinski transformation to handle general Pauli product rotations and measurements. For instance, are you thinking of refactoring PauliProductRotation and PauliProductMeasurement to something like

pub struct PauliProductRotation {
    pub pauli: Pauli,
    pub angle: Param,
}
pub struct PauliProductMeasurement {
    pub pauli: Pauli,  // "neg" is incorporated into `pauli_phase`
}

Though this specific suggestion is not perfect as it would require storing and reasoning about an unnecessary internal pauli_phase field for Pauli product rotations, as well as introduce additional values for the pauli_phase field for PauliProductMeasurement.

alexanderivrii

Thanks Shelly, I have left some more comments.

alexanderivrii · 2026-04-20T08:43:10Z

+    for qbit in 0..(pauli_num_qubits) {
+        let out_pauli = Pauli {
+            pauli_z: out_z,
+            pauli_x: out_x,
+            pauli_phase: out_phase,
+        };
+
+        // evolve the singe qubit pauli by cliff
+        let pz = pauli_z[qbit];
+        let px = pauli_x[qbit];
+        let (ev_p_sign, ev_p_z, ev_p_x, ev_p_indices) =
+            cliff.evolve_single_qubit_pauli(pz, px, qbit);
+
+        let evolved_pauli_phase = if ev_p_sign { 2 as u8 } else { 0 as u8 };
+        // transform the evolved pauli to a dense format
+        let mut evolved_pauli_z = vec![false; pauli_num_qubits];
+        let mut evolved_pauli_x = vec![false; pauli_num_qubits];
+        for (&i, (&zv, &xv)) in ev_p_indices.iter().zip(ev_p_z.iter().zip(ev_p_x.iter())) {
+            evolved_pauli_z[i as usize] = zv;
+            evolved_pauli_x[i as usize] = xv;
+        }
+        // compose the ouput evolved dense paulies
+        let evolved_pauli = Pauli {
+            pauli_z: evolved_pauli_z,
+            pauli_x: evolved_pauli_x,
+            pauli_phase: evolved_pauli_phase,
+        };


Logic-wise, this seems ok. But this does create a new Pauli object (with dense vectors z and x) a large number of times (pauli_num_qubits). I am wondering if you can improve performance of this code: by avoiding to conjugate by Is (as these do not change pauli), and by introducing a variant of evolve_pauli_by_clifford that modifies pauli in-place.

I added a check that the single qubit Pauli isn't I (and some tests) in d744ad3.

is the variant of evolve_pauli_by_clifford that modifies pauli in-place needed for this PR? we'll add PPM/PPR and consider this.

this should be part of #16137

alexanderivrii · 2026-04-27T07:02:35Z

+/// Compose the Paulis p1 and p2.
+/// Returns the output Pauli.
+pub fn pauli_compose(p1: &Pauli, p2: &Pauli) -> Pauli {


Can you please clarify: do we first apply p1 and then p2, or the other way around?

it's like p1.compose(p2) in the default python code:
https://quantum.cloud.ibm.com/docs/en/api/qiskit/qiskit.quantum_info.Pauli#compose
I also added a comment in d1a354a

this should be part of #16137

alexanderivrii · 2026-04-27T07:03:14Z

+pub struct Pauli {
+    pub pauli_z: Vec<bool>,
+    pub pauli_x: Vec<bool>,
+    pub pauli_phase: u8,


I think after the offline discussion, we want this to be xz-phase and not the group phase.

this should be part of #16137

Cryoris · 2026-04-29T08:52:55Z

        qct.global_phase = 0

+        # The original circuit (written only using Clifford gates, PPR and PPM).
+        PPRZ = PauliProductRotationGate(Pauli("Z"), np.pi / 4)


Can we put this into a separate test and use only PPRs (except maybe for the CX)? It would be good to keep the original test in place as reference that the old paths still work as expected.

The pass doesn't identify yet PPR gates (or RZ/RX/RY gates) with pi/2 angles as Cliffords. I'll add this capability and then update this test accordingly.

now there is a seperate test! see c62bb18

…fords

ShellyGarion · 2026-05-11T13:28:08Z

 use qiskit_circuit::{BlocksMode, Qubit, VarsMode};

+use super::remove_identity_equiv::average_gate_fidelity_below_tol; // ToDo: move a shared file?
+use super::substitute_pi4_rotations::is_angle_close_to_multiple_of_pi_k; // ToDo: move a shared file?


shoule we move these functions (as well as is_ppr_angle_close_to_multiple_of_pi2 below to a shared place)?
perhaps unifying them?
and if so - where?

ShellyGarion · 2026-05-11T13:29:12Z

+    "pauli_product_measurement",
+];
+
+const MINIMUM_TOL: f64 = 1e-12; // ToDo: add approxination_degree to the pass?


should we add an approxination_degree to the pass?
(to decide when a rotation gate is close enough to a pi/2 rotation, and then clifford)

alexanderivrii

Thanks for the great work, Shelly. Functionality-wise, this is shaping up quite well, I have left a few comments. I have not carefully looked at the dense_pauli code since we are planning to replace it by a more efficient code anyway, and I have not deeply looked at all of the tests yet.

The other question is: what benchmarks should we consider for measuring the performance of the new aspects of the LitinskiTransformation pass: identifying clifford-like rotations (especially PPRs) and commuting PPRs through Cliffords? Note that I am not suggesting to add these benchmarks to ASV as a part of this PR, but having some script to evaluate the pass performance is quite important.

alexanderivrii · 2026-05-12T06:33:33Z

    }
+    /// Modifies the tableau in-place by appending RZ-gate,
+    /// with an angle that is an integer multiple of pi/2
+    pub fn append_rz(&mut self, qubit: usize, multiple: usize) {


Nitpick about the naming. Seeing the function append_rz defined for a Clifford class is confusing, as appending an RZ gate to a Clifford generally no longer results in a Clifford. Moreover, RZ gates correspond to rotation angles, not "multiples". Maybe you can call this append_multiple_of_s or append_clifford_rz. The same comment applies to other new functions in this file.

we have a similar function in the python clifford class:

qiskit/qiskit/quantum_info/operators/symplectic/clifford_circuits.py

Line 351 in 2be7c41

def _append_rz(clifford, qubit, multiple):

alexanderivrii · 2026-05-12T06:42:39Z

+            1 => self.append_s(qubit),
+            2 => self.append_z(qubit),
+            3 => self.append_sdg(qubit),
+            _ => unreachable!("RZ is only applicable for multiples of pi/2 rotations."),


If we have this function as a part of public API, we should be able to call it with any integer multiple of pi/2, not necessarily reduced modulo 4. The change is to match multiple.rem_euclid(4) instead. Again, this comment applies to other new functions in this file.

done in 1b5c7bf

alexanderivrii · 2026-05-12T06:52:08Z

+                (true, false) => {}                                      // pauli Z on qubit
+                (true, true) => self.append_sx(indices[qubit] as usize), // pauli Y on qubit
+                (false, true) => self.append_h(indices[qubit] as usize), // pauli X on qubit
+                (false, false) => {} // pauli I on qubit (shouldn't get it since pauli is sparse)


I don't understand this comment that "pauli is sparse". You are defining a public function which accepts slices of z-values, x-values and indices. Nothing prevents a possible user of this function to pass paulis with I-terms, and actually I think this should be an acceptable behavior. If you really want to have a function that does not accept I-terms, I would like to see this reflected in the name and the docstring, and possibly have this function return some kind of an error rather than panicking or silently performing an incorrect computation.

I'm not sure what is the best way to handle the "I" terms in this case, since it also affects the CX ladders.

"I" terms are handled here: f6068d1

alexanderivrii · 2026-05-12T06:55:50Z

+    }
+    /// Modifies the tableau in-place by appending PPR gate,
+    /// with an angle that is an integer multiple of pi/2
+    pub fn append_ppr(


Should we add some rust tests for append_ppr? Yes, I know that we are not doing this at the moment, but maybe it's a good time to start.

Added a test here: 519cfba
(it still doesn't work for PPR with "I" terms, which I'm not sure what is the best way to handle)

"I" terms are handled here (including tests): f6068d1

alexanderivrii · 2026-05-12T06:59:36Z

 use qiskit_circuit::{BlocksMode, Qubit, VarsMode};

+use super::remove_identity_equiv::average_gate_fidelity_below_tol; // ToDo: move a shared file?
+use super::substitute_pi4_rotations::is_angle_close_to_multiple_of_pi_k; // ToDo: move a shared file?


I think we should eventually move these, but it does not have to be a part of this PR. In fact, let's leave this cleanup to a followup, since there are likely other common utility functions scattered throughout the code base.

when we merge this, let's open an issue to track the code organization

alexanderivrii · 2026-05-12T07:25:29Z

+    As well as the rotation gates above with angles that are integral multiples of :math:`pi/2`
+    (which are also Clifford).


As per your previous question, we should add the approximation_degree to the pass and slightly improve this comment (explaining the role of approximation degree when detecting Clifford rotations). Also you should mention PPRs here, right?

alexanderivrii · 2026-05-12T07:26:18Z

+    In addition, rotation gates and :class:`.PauliProductRotationGates` with angles 
+    that are integral multiples of :math:`pi/2` are treated as Clifford gates.


same comment as before that this should be related to the approximation degree.

alexanderivrii · 2026-05-12T07:27:14Z

-        self.assertNotIn("rz", qc_litinski.count_ops())
+        # self.assertNotIn("rz", qc_litinski.count_ops()) # ToDo: can we replace it by another check?


what is the reason for this?

This is since after Litinski we still have some remaining RZ gates with pi/2 angles (which are Clifford)

Any suggestion about how to update this test?

I see, so now the Clifford-like RZ(pi/2) moves to the Clifford part of the circuit. I guess this is what we want (the alternative could be to synthesize this into explicit Clifford gates, but I don't like this either). Maybe then we can have two subtests: with fix_clifford=True we expect the operators to be equal, and with fix_clifford=False we expect to see no RZ gates remaining.

that's a nice idea, I enhanced the QFT test here: 457dcc2

alexanderivrii · 2026-05-12T07:28:54Z

+    def test_rotation_clifford_gates(self):
+        """Test circuit with rotation gates with multiple pi/2 angles which are clifford gates."""


Do we also have a test with non-clifford rotations, clifford rotations and genuine cliffords?

see 519cfba
(still without PPRs with "I" terms)

"I" terms are handled here: f6068d1
and some tests are added

alexanderivrii · 2026-05-12T07:31:20Z

+        # The transformed circuit (as shown at the bottom-right of the figure).
+        expected = QuantumCircuit(4, 4)
+        expected.append(PauliProductRotationGate(Pauli("Z"), np.pi / 4), [0])
+        expected.append(PauliProductRotationGate(Pauli("YX"), np.pi / 4), [1, 2])
+        expected.append(PauliProductRotationGate(Pauli("Y"), -np.pi / 4), [3])
+        expected.append(PauliProductRotationGate(Pauli("YZZZ"), -np.pi / 4), [0, 1, 2, 3])
+        expected.append(PauliProductMeasurement(Pauli("YZZY")), [0, 1, 2, 3], [0])
+        expected.append(PauliProductMeasurement(Pauli("XX")), [0, 1], [1])
+        expected.append(PauliProductMeasurement(Pauli("-Z")), [2], [2])
+        expected.append(PauliProductMeasurement(Pauli("XX")), [0, 3], [3])


In this and in other new tests, how do we know that the expected circuit is correct? Without measures/PPMs I would suggest to add comparing Operators.

this is correct from the example given in Litinski's paper. We can't compare the Operators in this case due to the measures

alexanderivrii · 2026-05-12T08:33:53Z

After discussing with Shelly, a nice set of benchmarks would be to take the ASV benchmarks we already use for measuring the performance of LitinskiTransformation, apply ConvertToPauliRotations to them (hence obtaining a circuit with many PPRs including many Clifford-like PPRs), and then apply this extended LitinskiTransformation pass.

extend litinski transformation for rx and ry

6d85e81

ShellyGarion added this to the 2.5.0 milestone Apr 9, 2026

ShellyGarion added this to Qiskit 2.5 Apr 9, 2026

ShellyGarion added the fault tolerance related to fault tolerance compilation label Apr 9, 2026

github-project-automation Bot moved this to Ready in Qiskit 2.5 Apr 9, 2026

merge main branch

4495a29

alexanderivrii reviewed Apr 9, 2026

View reviewed changes

Comment thread crates/quantum_info/src/clifford.rs Outdated

Comment thread crates/transpiler/src/passes/litinski_transformation.rs Outdated

ShellyGarion mentioned this pull request Apr 9, 2026

[WIP] Pauli evolve in rust #14677

Closed

ShellyGarion added 3 commits April 9, 2026 12:02

replace pauli str by pauli_z, pauli_x

48c341f

add comments on the pauli

7c77ed5

add a test for two-qubit cliffords

1b7629b

ShellyGarion mentioned this pull request Apr 9, 2026

Zhang's algorithm for optimizing Pauli rotations #15086

Open

ShellyGarion added 9 commits April 13, 2026 15:36

replace get_inverse_pauli by evolve_single_qubit_pauli_by_clifford

10baa04

minor fix

025622f

the test_two_qubit_evolve_clifford_gate now checks circuit equality

27c53d8

simplify function name to evolve_single_qubit_pauli

6e4148d

update comments

fd9ff5e

fix misprint

e368971

fix confict with main

b3d5602

add a basic Pauli class. add pauli_compose function

778d552

fix year

699cd4f

add evolve_pauli_by_clifford

284ee64

alexanderivrii reviewed Apr 20, 2026

View reviewed changes

ShellyGarion added 4 commits April 20, 2026 15:02

update dense_pauli.rs code following review

d744ad3

add some more tests for pauli I

0bb2ec5

handle PPR gates

2170be0

formatting

ab3599f

alexanderivrii reviewed Apr 27, 2026

View reviewed changes

add a helper function to pad paulis

d1a354a

Cryoris reviewed Apr 29, 2026

View reviewed changes

Cryoris mentioned this pull request Apr 30, 2026

Enable a multi-IR pipeline for bicycle compilation #15860

Open

6 tasks

alexanderivrii mentioned this pull request May 5, 2026

DensePauli class in Rust #16137

Open

3 tasks

ShellyGarion assigned Cryoris and alexanderivrii May 6, 2026

ShellyGarion added 10 commits May 10, 2026 13:35

add append_rx, append_ry, append_rz to the clifford rust class

4d4b886

make function public

ec9795a

litinski transformation now handles RX/RY/RZ with pi/2 angles as clif…

0a38e2c

…fords

add tests with RX/RY/RZ gates and pi/2 angles

de36c3d

remove print

ced111f

formatting

3036ed9

no need to make the module public

d33977c

add append_ppr method to clifford class

479194d

litinski now handles PPR with pi/2 angles as cliffords

3569230

add tests for PPR with pi/2 angles

c62bb18

ShellyGarion added the Changelog: Added Add an "Added" entry in the GitHub Release changelog. label May 11, 2026

ShellyGarion added 2 commits May 11, 2026 16:25

enhance the docstring

ba4bdc0

add release notes

5dfdeea

ShellyGarion changed the title ~~[WIP] Extend litinski transformation for all Pauli rotations~~ Extend litinski transformation for all Pauli rotations May 11, 2026

ShellyGarion commented May 11, 2026

View reviewed changes

alexanderivrii reviewed May 12, 2026

View reviewed changes

ShellyGarion added 7 commits May 12, 2026 12:15

add a test for PPRs with and w/o pi/2 angles

519cfba

move modulo 4 to clifford class from litinski

1b5c7bf

update comments

12423db

update docstring

80f6640

update test_qft_circuits

457dcc2

change set to list in test

872098b

enhance clifford.append_ppr to handle pauli I terms

f6068d1

		As well as the rotation gates above with angles that are integral multiples of :math:`pi/2`
		(which are also Clifford).

		In addition, rotation gates and :class:`.PauliProductRotationGates` with angles
		that are integral multiples of :math:`pi/2` are treated as Clifford gates.

		self.assertNotIn("rz", qc_litinski.count_ops())
		# self.assertNotIn("rz", qc_litinski.count_ops()) # ToDo: can we replace it by another check?

		def test_rotation_clifford_gates(self):
		"""Test circuit with rotation gates with multiple pi/2 angles which are clifford gates."""

Conversation

ShellyGarion commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details and comments

Uh oh!

alexanderivrii left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

alexanderivrii commented Apr 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

alexanderivrii left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

alexanderivrii Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShellyGarion Apr 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexanderivrii left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ShellyGarion May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ShellyGarion commented Apr 9, 2026 •

edited

Loading

alexanderivrii commented Apr 19, 2026 •

edited

Loading

alexanderivrii Apr 20, 2026 •

edited

Loading

ShellyGarion Apr 27, 2026 •

edited

Loading

ShellyGarion May 12, 2026 •

edited

Loading

ShellyGarion May 12, 2026 •

edited

Loading

ShellyGarion May 12, 2026 •

edited

Loading