qiskit
qiskit copied to clipboard
Qiskit
Parameter handling in SparsePauliOp
Summary
Takeover #7215.
Details and comments
TODO:
- [ ] Tests
- [ ] Releasenote
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 the following people are requested to review this:
- @Qiskit/terra-core
- @ikkoham
Pull Request Test Coverage Report for Build 3140920284
- 22 of 22 (100.0%) changed or added relevant lines in 1 file are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage increased (+0.002%) to 84.469%
| Totals | |
|---|---|
| Change from base Build 3139567056: | 0.002% |
| Covered Lines: | 59957 |
| Relevant Lines: | 70981 |
💛 - Coveralls
Yes, it is up for discussion whether this is the best implementation, but we need the Parameterized SparsePauliOp as a new feature for 0.22. I will do my best to check performance and add more tests and documentations.
Probably it's not a problem, since numpy in Rust can have PyObjects as elements.
Probably it's not a problem, since numpy in Rust can have
PyObjects as elements.
The bigger issue with this is that to do any numeric operations on an ndarray with an object dtype in rust is that we'll need to callback to python to use python's functions which kind of defeats the purpose of doing anything from rust because we'll end up being bound by python's performance. But it's not really a blocker because I expect for any implementation of #8772 we'll keep the python class and can just dispatch to rust if it's a complex dtype and leave the python code for the object dtype.
