composite ops auto-upgrade tensors and hamiltonians #5031
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
timmysilv
commented
Jan 9, 2024
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #5031 +/- ##
==========================================
- Coverage 99.67% 99.66% -0.01%
==========================================
Files 394 394
Lines 35582 35322 -260
==========================================
- Hits 35467 35205 -262
- Misses 115 117 +2 ☔ View full report in Codecov by Sentry. |
albi3ro
approved these changes
Jan 10, 2024
lillian542
approved these changes
Jan 10, 2024
# Conflicts: # doc/releases/changelog-dev.md
timmysilv
added a commit
that referenced
this pull request
Jan 16, 2024
**Context:** Started in #5031, but missed this upgrade behaviour for `SProd` **Description of the Change:** If the base provided to `SProd.__init__` is a Tensor or Hamiltonian, auto-upgrade it to new arithmetic operators using `qml.operation.convert_to_opmath` **Benefits:** No confusing errors or unexpected behaviour when working with new operator arithmetic. **Possible Drawbacks:** N/A **Related GitHub Issues:** Fixes #5060
mudit2812
pushed a commit
that referenced
this pull request
Jan 19, 2024
**Context:** We can get some spooky-looking Franken-Operators today, and it often happens by accident. For example: ```pycon >>> qml.prod(qml.PauliX(0), 3 * qml.PauliZ(1)) PauliX(wires=[0]) @ (3) [Z1] ``` The second operand became a Hamiltonian instead of an SProd! This makes sense if you think about the order of python execution and how we implemented things, but users shouldn't have to think about that. Moreover, calling `simplify()` on that op won't work so well because things are all mixed up. **Description of the Change:** Update `CompositeOp.__init__` to replace any `Tensor` or `Hamiltonian` operands with `Prod`, `Sum`, or `SProd` operands as required. **Benefits:** User expectations are met, Operator simplification works **Possible Drawbacks:** I suspect this will bring far more benefit than drawback, but it's possible that a user is expecting some weird hybrid operator and is disappointed by this standardization [sc-53356]
mudit2812
pushed a commit
that referenced
this pull request
Jan 19, 2024
**Context:** Started in #5031, but missed this upgrade behaviour for `SProd` **Description of the Change:** If the base provided to `SProd.__init__` is a Tensor or Hamiltonian, auto-upgrade it to new arithmetic operators using `qml.operation.convert_to_opmath` **Benefits:** No confusing errors or unexpected behaviour when working with new operator arithmetic. **Possible Drawbacks:** N/A **Related GitHub Issues:** Fixes #5060
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context:
We can get some spooky-looking Franken-Operators today, and it often happens by accident. For example:
The second operand became a Hamiltonian instead of an SProd! This makes sense if you think about the order of python execution and how we implemented things, but users shouldn't have to think about that. Moreover, calling
simplify()on that op won't work so well because things are all mixed up.Description of the Change:
Update
CompositeOp.__init__to replace anyTensororHamiltonianoperands withProd,Sum, orSProdoperands as required.Benefits:
User expectations are met, Operator simplification works
Possible Drawbacks:
I suspect this will bring far more benefit than drawback, but it's possible that a user is expecting some weird hybrid operator and is disappointed by this standardization
[sc-53356]