-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Allow on_each for multi-qubit gates #4281
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
Conversation
@mpharrigan @maffoo Here's the first part of #4236. |
Can you provide a more detailed PR description that doesn't require the context of the previous PR to find the issue? |
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.
The splitting of the PRs makes this super clear; thanks!
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.
LGTM. @maffoo are you happy?
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.
LGTM
Automerge cancelled: A required status check is not present. Missing statuses: ['Changed files test', 'Lint check'] |
Looks like merge got canceled somehow. Can you try again? |
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.
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.
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:
Discussion here, #4034 (comment). Part of #4236.