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

Correct integer widths in Rust/Python hand-off #7849

Merged
merged 2 commits into from
Mar 31, 2022

Conversation

jakelishman
Copy link
Member

Summary

Various locations in the Rust API take a usize as input. For the most
part, Python integers will successfully be passed in at the correct size
if they fit. Numpy np.uint64 types, however, will fail conversion if
running on a 32-bit machine. This is particularly relevant when the
values are being passed as an array.

Details and comments

Needs to test the wheel builds first - it's fine if it fails macos_arm because there's a separate fix in progress for that.

There are other places where we do an "arbitrary int" -> usize hand-off, but I think that PyO3 does the right thing, even if given an effective u64 to convert to u32, provided the represented value fits. I think this method is the only problematic one, because it won't convert arrays of u64 to u32 (very reasonably).

Various locations in the Rust API take a `usize` as input.  For the most
part, Python integers will successfully be passed in at the correct size
if they fit.  Numpy `np.uint64` types, however, will fail conversion if
running on a 32-bit machine.  This is particularly relevant when the
values are being passed as an array.
@jakelishman jakelishman added priority: high Changelog: None Do not include in changelog labels Mar 31, 2022
@jakelishman jakelishman added this to the 0.20 milestone Mar 31, 2022
@jakelishman jakelishman requested a review from a team as a code owner March 31, 2022 14:43
@jakelishman jakelishman force-pushed the stochastic-swap-integer-sizes branch from a5e970d to ef9beee Compare March 31, 2022 14:44
@jakelishman jakelishman added the on hold Can not fix yet label Mar 31, 2022
@mtreinish
Copy link
Member

Yeah, we only need to worry about this when going from a numpy array to the rust extension as it's passed by reference from the underlying c array generated by numpy to the rust code (using numpy's c api). For the normal python -> rust path pyo3 will handle the conversion from an int type to the equivalent rust numeric type for us and if it's invalid (either because it's too large or negative for an unsigned int) it will raise an exception.

Copy link
Member

@mtreinish mtreinish left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for fixing this

@mtreinish mtreinish added automerge and removed on hold Can not fix yet labels Mar 31, 2022
@coveralls
Copy link

coveralls commented Mar 31, 2022

Pull Request Test Coverage Report for Build 2072577619

  • 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 83.701%

Totals Coverage Status
Change from base Build 2072575312: 0.0%
Covered Lines: 53973
Relevant Lines: 64483

💛 - Coveralls

@mtreinish mtreinish added the Rust This PR or issue is related to Rust code in the repository label Mar 31, 2022
@mergify mergify bot merged commit c06753d into Qiskit:main Mar 31, 2022
@jakelishman jakelishman deleted the stochastic-swap-integer-sizes branch April 1, 2022 20:44
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 priority: high 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.

3 participants