-
Notifications
You must be signed in to change notification settings - Fork 605
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
cherry-pick minor bugfixes from master #4807
Conversation
We discovered a difference between `default.qubit` and `default.qubit.legacy` over their treatment of the evolution of hamiltonians: ```python dev = qml.device('default.qubit', wires=3) coeffs = [0.1, 0.2] operators = [qml.PauliZ(0) @ qml.PauliZ(1), qml.PauliZ(0) @ qml.PauliZ(2)] hamiltonian = qml.Hamiltonian(coeffs, operators) @qml.qnode(dev) def f(): qml.evolve(hamiltonian, 0.5) return qml.density_matrix([0]) f() ``` Previously `qml.evolve(hamiltonain, t)` worked because `Evolution` was hardcoded as an accepted observable. This meant it became an accepted operation as well, even though it stated it didn't have a matrix. In `ScalarSymbolicOp`, the parent for `Evolution`, we added a special logical pathway for the matrix if the target is a Hamiltonian, but we didn't include that special logical pathway for the `has_matrix` property. This PR updates the `has_matrix` property for and allows the evolution of a hamiltonian to execute on `default.qubit`. **Warning:** This matrix is not backprop compatible. ``` dev = qml.device('default.qubit.legacy', wires=3) coeffs = [0.1, 0.2] operators = [qml.PauliZ(0) @ qml.PauliZ(1), qml.PauliZ(0) @ qml.PauliZ(2)] @qml.qnode(dev) def f(x): hamiltonian = qml.Hamiltonian(x, operators) qml.evolve(hamiltonian, 0.5) return qml.density_matrix([0]) qml.grad(f)(qml.numpy.array(coeffs)) ``` Gives ``` AttributeError: 'ArrayBox' object has no attribute 'tocsr' ``` `qml.dot` and operator arithemetic does not have these problems. --------- Co-authored-by: lillian542 <38584660+lillian542@users.noreply.github.com>
Fixes #4779 . [sc-49381] When creating an initial state, `get_final_state` was using `tape.op_wires` for the wire order, even though the simulation always occurred using the wire order `(0,1,2,3,...)`. Sometimes `tape.op_wires` would have a different order, leading to a mismatch. Now we use `sorted(circuit.op_wires)`, so they will always be in the monotonically increasing integers used by the simulation. --------- Co-authored-by: Matthew Silverman <matthews@xanadu.ai> Co-authored-by: Tom Bromley <49409390+trbromley@users.noreply.github.com>
…uit measurements (#4787) **Context:** When making terminal measurements on wires with mid-circuit measurements, the circuit was not being transformed correctly. This PR fixes that. **Description of the Change:** Wires are considered to be reused by `defer_measurements` when a measured wire has operators *and* terminal measurements applied to it after mid-circuit measurements. **Benefits:** **Possible Drawbacks:** **Related GitHub Issues:** [sc-49507]
Hello. You may have forgotten to update the changelog!
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## v0.33.1-rc0 #4807 +/- ##
===============================================
- Coverage 99.64% 99.64% -0.01%
===============================================
Files 380 380
Lines 34266 34009 -257
===============================================
- Hits 34145 33887 -258
- Misses 121 122 +1
☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @timmysilv!
Context:
These three bugs were identified as good to be released in a bugfix.
Description of the Change:
Cherry-pick the 3 commits to master onto this branch for the 0.33.1 bugfix release
Benefits:
Fixed bugs pushed out!
Possible Drawbacks:
Extra work in a critical time.
Related GitHub Issues:
#4768, #4781, #4787