Skip to content
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

Remove duplicated weyl_coordinates python function #13193

Merged
merged 1 commit into from
Oct 15, 2024

Conversation

mtreinish
Copy link
Member

Summary

This commit removes the weyl_coordinates() function from the private qiskit.synthesis.two_qubit.weyl module. This function's internal use was ported to rust as part of #11019 but it left the python implementation intact while we ensured the rust implementation was reliable longer term. Since then we've ported the majority of the two qubit synthesis to rust now and the only usage of this python implementation was the unit tests. This commit removes the python implementation and the entire internal weyl module as nothing uses it anymore. A python interface is added to the rust function and the tests are updated to call that instead.

Details and comments

Fixes: #8459

This commit removes the weyl_coordinates() function from the private
qiskit.synthesis.two_qubit.weyl module. This function's internal use was
ported to rust as part of Qiskit#11019 but it left the python implementation
intact while we ensured the rust implementation was reliable longer
term. Since then we've ported the majority of the two qubit synthesis to
rust now and the only usage of this python implementation was the unit
tests. This commit removes the python implementation and the entire
internal weyl module as nothing uses it anymore. A python interface is
added to the rust function and the tests are updated to call that
instead.

Fixes: Qiskit#8459
@mtreinish mtreinish added Changelog: None Do not include in changelog Rust This PR or issue is related to Rust code in the repository labels Sep 19, 2024
@qiskit-bot
Copy link
Collaborator

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

  • @Qiskit/terra-core
  • @kevinhartman
  • @levbishop
  • @mtreinish

@coveralls
Copy link

Pull Request Test Coverage Report for Build 10947950215

Details

  • 9 of 9 (100.0%) changed or added relevant lines in 1 file are covered.
  • 15 unchanged lines in 2 files lost coverage.
  • Overall coverage decreased (-0.02%) to 88.782%

Files with Coverage Reduction New Missed Lines %
crates/qasm2/src/lex.rs 3 92.73%
crates/qasm2/src/parse.rs 12 97.15%
Totals Coverage Status
Change from base Build 10947873036: -0.02%
Covered Lines: 73449
Relevant Lines: 82730

💛 - Coveralls

Comment on lines +219 to +234
/// Computes the Weyl coordinates for a given two-qubit unitary matrix.
///
/// Args:
/// U (np.ndarray): Input two-qubit unitary.
///
/// Returns:
/// np.ndarray: Array of the 3 Weyl coordinates.
#[pyfunction]
fn weyl_coordinates(py: Python, unitary: PyReadonlyArray2<Complex64>) -> PyObject {
let array = unitary.as_array();
__weyl_coordinates(array.into_faer_complex())
.to_vec()
.into_pyarray_bound(py)
.into()
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did we consider this public interface in any way? If not: is there any chance it might get called with matrices whose dtypes are not complex? I'm asking because the Python code would have happily lifted the matrix to be complex early in the process (during the translation to the magic basis), but this will now just error immediately if anyone's doing things like weyl_coordinates(np.eye(2)).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Except of Jake's question, this PR looks good to me.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't think that we considered this API public in any way. It was previously used internally for some things but was replaced by rust internals in 1.0 and 1.1. Right now it's not documented anywhere nor is the deleted internal module and this function is only used for tests now. The public interface for getting the weyl coordinates would be to use the TwoQubitWeylDecomposition and access the coordinate attributes. That being said if you think it's important I can change the input type to handle the casting here.

@ShellyGarion ShellyGarion added this to the 1.3.0 milestone Oct 3, 2024
@jakelishman jakelishman added this pull request to the merge queue Oct 15, 2024
Merged via the queue into Qiskit:main with commit 54fe09b Oct 15, 2024
15 checks passed
@mtreinish mtreinish deleted the rust-all-the-weyl branch October 15, 2024 15:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Changelog: None Do not include in changelog Rust This PR or issue is related to Rust code in the repository
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use of general eigenvalues solver in weyl_coordinates sometimes throws convergence error
5 participants