Skip to content

Bug fixes in Solovay Kitaev Decomposition (backport #14217) #14294

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
May 9, 2025

Conversation

mergify[bot]
Copy link
Contributor

@mergify mergify bot commented May 5, 2025

Summary

This PR fixes a number of bugs we have recently discovered in the Python code for the Solovay-Kitaev decomposition, together with @Cryoris and @anedumla.

Fixes include:

  • fixed a problem with the rotation axis computation for 180 degree rotations (thanks to @Cryoris for working out the math)
  • fixed a problem where the global phase of the returned circuit might have been off by $\pi$, due to the underlying algorithm approximating not the original SU(2) matrix, but its projection onto SO(3)
  • in particular fixed Global phase on Solovay-Kitaev decomposition seems wrong #9552.

Longer-term, we will deprecate the Python code for Solovay-Kitaev decomposition altogether, and switch to the new improved pass written in Rust that also fixes these problems (see #14203), however for backward compatibility we need to temporarily support the Python code as well, and thus it makes sense to fix the problems on the Python side too.

Details and comments

Other changes:

  • There was a very strange "back door" for returning a circuit with the original unitary matrix if the computed matrix is not close to the identity. This behavior is not consistent with the documented description of the pass and was removed. (Or rather the functions to_circuit and to_dag remain for backwards compatibility but are no longer used by the main pass).
  • The GateSequence class used to store both the SO(3) matrix as product and the SU(2) matrix as product_su2, however the parameter product_su2 was not updated correctly in various places (and it was not even clear what to do within GateSequence.from_matrix). As product_su2 was almost not used anywhere in the algorithm (with the exception of one place where its usage did not seem to be correct anyway), it was simply removed to avoid confusion and unnecessary computations.

This is an automatic backport of pull request #14217 done by [Mergify](https://mergify.com).

* Fix _compute_rotation_axis method

The method used to return [0, 0, 0] for rotation axis when theta is very close to 0 (and yet not within 1e010).
This commit fixes this by noting that the rotation axis of an SO(3) matrix is simply the eigenvector of this
matrix corresponding to eigenvalue 1.

* Fixes related to SU(2) vs. SO(3)

The implemented algorithm has a global phase uncertainty of +-1, due to approximating not the
original SU(2) matrix but its projection onto SO(3). This fixes the global phase of the
computed approximation.

In addition, the product_su2 matrix in GateSequence was not correctly computed in many cases,
leading to incorrect values when using this attribute. Since this is not needed for the actual
algorithm (and spends unnecessary effort for computing it), this also completely removes this
attribute.

Co-authored-by: Almudena Carrera Vazquez <almudenacarreravazquez@hotmail.com>

* Fix the tests.

One of the tests was simply wrong because the reference circuit has the wrong global phase.
The tests that check the gates in the final decomposition should not assume that SGate is included and SdgGate is not.

* reno

* fix to the global phase

* bug fix (forgetting that gate_matrix_su2 is not SU(2) was a sequence)

* adding test

* Restoring the previous fast code for _compute_rotation_axis based on Rodrigues formula, while additionally handling the case of 180-degree rotation

* removing old code

* review comments

* switching back to using _to_dag and _to_circuit

I actually no longer think that these methods would ever return a circuit with unitary gates, so it does not really matter

* Addressing review comments

* pass over release notes combining the original and the suggested wordings

* Update releasenotes/notes/fix-sk-decomposition-23da3ee4b6a10d62.yaml

Co-authored-by: Julien Gacon <gaconju@gmail.com>

---------

Co-authored-by: Almudena Carrera Vazquez <almudenacarreravazquez@hotmail.com>
Co-authored-by: Julien Gacon <gaconju@gmail.com>
(cherry picked from commit 6892608)

# Conflicts:
#	test/python/transpiler/test_solovay_kitaev.py
@mergify mergify bot requested a review from alexanderivrii as a code owner May 5, 2025 16:20
@mergify mergify bot added the conflicts used by mergify when there are conflicts in a port label May 5, 2025
@mergify mergify bot requested review from ShellyGarion and a team as code owners May 5, 2025 16:20
Copy link
Contributor Author

mergify bot commented May 5, 2025

Cherry-pick of 6892608 has failed:

On branch mergify/bp/stable/1.4/pr-14217
Your branch is up to date with 'origin/stable/1.4'.

You are currently cherry-picking commit 68926088b.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   qiskit/synthesis/discrete_basis/commutator_decompose.py
	modified:   qiskit/synthesis/discrete_basis/gate_sequence.py
	modified:   qiskit/synthesis/discrete_basis/generate_basis_approximations.py
	modified:   qiskit/synthesis/discrete_basis/solovay_kitaev.py
	new file:   releasenotes/notes/fix-sk-decomposition-23da3ee4b6a10d62.yaml

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   test/python/transpiler/test_solovay_kitaev.py

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

@qiskit-bot
Copy link
Collaborator

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

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

  • @Qiskit/terra-core

@github-actions github-actions bot added the Changelog: Bugfix Include in the "Fixed" section of the changelog label May 5, 2025
@github-actions github-actions bot added this to the 1.4.3 milestone May 5, 2025
@Cryoris Cryoris removed the conflicts used by mergify when there are conflicts in a port label May 6, 2025
@ElePT ElePT enabled auto-merge May 8, 2025 11:44
@ElePT ElePT added this pull request to the merge queue May 9, 2025
Merged via the queue into stable/1.4 with commit efcdfdc May 9, 2025
18 of 19 checks passed
@jakelishman jakelishman deleted the mergify/bp/stable/1.4/pr-14217 branch June 9, 2025 15:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: Bugfix Include in the "Fixed" section of the changelog
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants