-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Conversation
* 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
Cherry-pick of 6892608 has failed:
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 |
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:
|
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:
SU(2)
matrix, but its projection ontoSO(3)
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:
to_circuit
andto_dag
remain for backwards compatibility but are no longer used by the main pass).GateSequence
class used to store both the SO(3) matrix asproduct
and the SU(2) matrix asproduct_su2
, however the parameterproduct_su2
was not updated correctly in various places (and it was not even clear what to do withinGateSequence.from_matrix
). Asproduct_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).