-
Notifications
You must be signed in to change notification settings - Fork 982
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
Move on_each to cirq.Gate #4236
Conversation
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.
I don't think this follows the proposed behavior. Hopefully restricting to either 1) qubits for one qubit gate or 2) iterables of tuples for multiq gates will permit a simpler implementation as well. It's rather involved right now
@daxfohl is this ready for re-review? |
Yes, the new code only supports the strict option for multi-qubit gates, per the discussion here: #4034 (comment) |
@daxfohl, how would you feel about splitting this into two PRs, one to generalize |
some readability concerns raised above. I agree with @maffoo that this change would benefit from being split into the two proposed parts |
Sure, I can address those concerns and split into two PRs. |
First part added at #4281. We can return to this later then. I'll move it to draft status. @mpharrigan @maffoo |
Adds on_each support to the SupportsOnEachGate mixin for multi-qubit gates. The handling here is not as flexible as for single-qubit gates, which allows any tree of gates and applies them depth-first. This allows the following two options for multi-qubit gates: ``` A: varargs form gate.on_each([q1, q2], [q3, q4]) B: explicit form gate.on_each([[q1, q2], [q3, q4]]) ``` Discussion here, #4034 (comment). Part of #4236.
Closing in favor of #4303 |
Closes #2164 Copies `Two/ThreeQubitGate` to cirq.testing due to its convenience there, and deprecates the originals. BREAKING CHANGE: @balopat @95-martin-orion @tanujkhattar During the deprecation period, `isinstance(TwoQubitGate)` has been shimmed such that it will now return True iff _num_qubits_() returns 2, regardless of whether it's actually part of the class hierarchy (and same for ThreeQubitGate). It's not expected that this will cause real-world breakages, but possible. This can go before or after #4236, as they are disjoint problems.
Adds on_each support to the SupportsOnEachGate mixin for multi-qubit gates. The handling here is not as flexible as for single-qubit gates, which allows any tree of gates and applies them depth-first. This allows the following two options for multi-qubit gates: ``` A: varargs form gate.on_each([q1, q2], [q3, q4]) B: explicit form gate.on_each([[q1, q2], [q3, q4]]) ``` Discussion here, quantumlib#4034 (comment). Part of quantumlib#4236.
Closes quantumlib#2164 Copies `Two/ThreeQubitGate` to cirq.testing due to its convenience there, and deprecates the originals. BREAKING CHANGE: @balopat @95-martin-orion @tanujkhattar During the deprecation period, `isinstance(TwoQubitGate)` has been shimmed such that it will now return True iff _num_qubits_() returns 2, regardless of whether it's actually part of the class hierarchy (and same for ThreeQubitGate). It's not expected that this will cause real-world breakages, but possible. This can go before or after quantumlib#4236, as they are disjoint problems.
Part of #4034. (See #4034 (comment))
This can go before or after #4207, as they are disjoint problems.
Note that deprecating
SingleQubitGate
will be more troublesome than the others, as things like_CALIBRATION_IRRELEVANT_GATES
andNOISE_MODEL_LIKE
depend on it.