-
Notifications
You must be signed in to change notification settings - Fork 625
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
simplify state reordering logic (#4817)
**Context:** I wrote the same function twice, differing only by state flattening, to get the DQ upgrade done. It's starting to cause trouble. **Description of the Change:** Greatly simplified the state re-arrangement logic. There used to be a whole mess of things happening, but now things are much more straightforward. 1. `simulate` first puts things in our "standard" order, and this means that if any measured wires are not also operator wires, they are put to the _end_ of our tape wires. Therefore, for each measured-only wire, we just have to stack a `zeros_like(state)` to the last axis of our final state! `simulate` never tried to transpose wires back to a different ordering, so that was always wasted work. 2. `StateMP.process_state` _always_ receives the full state, and never needed to pad. No other device has done this optimization (the function used to literally just `return state` before DQ2 migration), and `simulate` already ensures that the final state has all wires in it - they just might be out of order. The only thing we might need from `process_state` is a transposition to the correct wire order. The inputted `wire_order` _should_ always be `range(len(wires))`, but whatever, we don't need to assume that. I'll paint a picture for a normal scenario: ```python @qml.qnode(qml.device("default.qubit", wires=3)) def circuit(x): qml.RX(x, 0) qml.CNOT([0, 2]) return qml.state() ``` What happens with this QNode? 1. Device preprocessing sticks the device wires (`[0, 1, 2]`) onto the `StateMP` 2. `simulate` maps the wires to our standard order. I'll demonstrate (with `probs` so I can specify wires): ```pycon >>> qs = qml.tape.QuantumScript([qml.RX(1.1, 0), qml.CNOT([0, 2])], [qml.probs(wires=[0, 1, 2])]) >>> qs.map_to_standard_wires().circuit [RX(1.1, wires=[0]), CNOT(wires=[0, 1]), probs(wires=[0, 2, 1])] ``` 3. Operate on the 2-qubit state, then stack another `[[0, 0], [0, 0]]` on the end of it (wire "1") 4. `StateMP(wires=[0, 1, 2]).process_state(state, wire_order=[0, 2, 1])` transposes the result to the correct order I also changed the torch tests to stop using a deprecated setter for default float types. **Benefits:** Duplicate code is cleaned up, existing code is simplified, no unnecessary call to transpose. **Possible Drawbacks:** - Have to call `qml.math.stack` for every wire that was not operated on. Hopefully this is usually not a lot, and it's not that costly anyway - functions now do less than they used to (I see this as a perk - they now do _exactly_ what they're supposed to)
- Loading branch information
Showing
6 changed files
with
49 additions
and
155 deletions.
There are no files selected for viewing
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
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
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
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
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
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