You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to enable multi-qubit operations that contain multiple control and/or multiple target components, and maintain Swap operations (which have no control), and also enable Swaps that are controlled we need to revise Q’s text-as-input syntax. (This is related to #18.)
Currently the order of an operation’s registerIndices array determines the control / target nature of the operation. (Swap operations are intended to be exempt from this logic.) Q assumes that a registerIndex at array index #0 is a control, and any array index > 0 is a target. As a result a Bell state currently looks like this:
H X#0
I X#1
Note how the CNOT is represented as a Pauli X gate but with multiple registers indices. It can be trivially written upside-down like this:
I X#1
H X#0
However there is no way in the current notation to describe a double-controlled Pauli X gate, also known as a Toffoli gate or CCNOT. Adding more indices would just add more target components. The following would be a CNOT with a single control on register 1 that potentially applies a Pauli X gate to register 2 and register 3:
H X#0
I X#1
I X#2
Note also how this syntax requires an operation ID when it would otherwise be ambiguous which multi-register operation components are related in a given moment of time.
H X.0#0
H X.1#0
I X.0#1
I X.1#1
I was never fully satisfied with this solution because it felt like extra cognitive overhead—the exact thing I wanted to avoid with this syntax. (Q ought to do the work for you.)
Proposed syntax change
Let’s do away with the need for operation IDs entirely (thereby eliminating that additional cognitive overhead) while also allowing for an arbitrary number of controls or targets. Here is a Bell state followed by a Swap operation using this potential new syntax:
H C S
I X1 S1
Note how the control component of the CNOT is now explicitly stated with C and the Pauli X component (X) is assumed to be a target. No operation IDs are required because sibling components are referenced relative to the register index. Here the number 1 in X1 means “attach this component to the component that is 1 register above here.” The Swap uses the same register-index-relative numbering.
It can be arbitrarily flipped upside-down like so. Note how now the control component of the CNOT is paired with a relative register index command.
I X S
H C1 S1
Now we can construct a similar circuit to those above, but substituting a basic CNOT for one with two target components, and substituting a Swap for a controlled-Swap. Note how each component that is paired with a number is essentially saying “join me to the operation above me.” It is also immediately clear—without having to sort a list of numbers in your head—which component is a control.
H C C
I X1 S1
I X1 S1
The following expands on the above circuit by adding a second control component both to the Pauli X and Swap operations.
H C C
I C1 C1
I X1 S1
I X1 S1
The “overlapping CNOTs” example above can now be written like so—which is immediately cleaner, clearer, and also uses fewer characters:
H C
H C
I X2
I X2
This syntax would require that the register-relative values be positive; the numeric value is always saying “look this many registers above me.” (If negative numbers were allowed then it might be interpreted as “look this many registers below me.”) In this way, as the text is being interpreted by “moments ascending, registers ascending” the parser is always building upon what came before, rather than having to account for what ought to be coming later.
Impact to visual editor
Note that this syntax change may also require a subtle change to the visual circuit editor. Currently it is possible to make a mess of the wires between joined components with something like this:
X#0
X#2
X#1
X#3
This has no practical meaning for an actual quantum circuit, but it does act as a user would expect: dragging components around causes them to appear twisted. It also had a direct correlation to the text-as-input syntax; it could be represented with it. Because this “feels correct” from a user interface standpoint and causes no harm when translated to an actual circuit it felt desirable to allow this. But now there will be no way to represent it in text. Perhaps it’s time to “auto-untangle” the components of multi-register operations in the visual interface.
The text was updated successfully, but these errors were encountered:
In order to enable multi-qubit operations that contain multiple control and/or multiple target components, and maintain Swap operations (which have no control), and also enable Swaps that are controlled we need to revise Q’s text-as-input syntax. (This is related to #18.)
Currently the order of an operation’s
registerIndices
array determines the control / target nature of the operation. (Swap operations are intended to be exempt from this logic.) Q assumes that aregisterIndex
at array index #0 is a control, and any array index > 0 is a target. As a result a Bell state currently looks like this:Note how the CNOT is represented as a Pauli X gate but with multiple registers indices. It can be trivially written upside-down like this:
However there is no way in the current notation to describe a double-controlled Pauli X gate, also known as a Toffoli gate or CCNOT. Adding more indices would just add more target components. The following would be a CNOT with a single control on register 1 that potentially applies a Pauli X gate to register 2 and register 3:
Note also how this syntax requires an operation ID when it would otherwise be ambiguous which multi-register operation components are related in a given moment of time.
I was never fully satisfied with this solution because it felt like extra cognitive overhead—the exact thing I wanted to avoid with this syntax. (Q ought to do the work for you.)
Proposed syntax change
Let’s do away with the need for operation IDs entirely (thereby eliminating that additional cognitive overhead) while also allowing for an arbitrary number of controls or targets. Here is a Bell state followed by a Swap operation using this potential new syntax:
Note how the control component of the CNOT is now explicitly stated with
C
and the Pauli X component (X
) is assumed to be a target. No operation IDs are required because sibling components are referenced relative to the register index. Here the number1
inX1
means “attach this component to the component that is 1 register above here.” The Swap uses the same register-index-relative numbering.It can be arbitrarily flipped upside-down like so. Note how now the control component of the CNOT is paired with a relative register index command.
Now we can construct a similar circuit to those above, but substituting a basic CNOT for one with two target components, and substituting a Swap for a controlled-Swap. Note how each component that is paired with a number is essentially saying “join me to the operation above me.” It is also immediately clear—without having to sort a list of numbers in your head—which component is a control.
The following expands on the above circuit by adding a second control component both to the Pauli X and Swap operations.
The “overlapping CNOTs” example above can now be written like so—which is immediately cleaner, clearer, and also uses fewer characters:
This syntax would require that the register-relative values be positive; the numeric value is always saying “look this many registers above me.” (If negative numbers were allowed then it might be interpreted as “look this many registers below me.”) In this way, as the text is being interpreted by “moments ascending, registers ascending” the parser is always building upon what came before, rather than having to account for what ought to be coming later.
Impact to visual editor
Note that this syntax change may also require a subtle change to the visual circuit editor. Currently it is possible to make a mess of the wires between joined components with something like this:
This has no practical meaning for an actual quantum circuit, but it does act as a user would expect: dragging components around causes them to appear twisted. It also had a direct correlation to the text-as-input syntax; it could be represented with it. Because this “feels correct” from a user interface standpoint and causes no harm when translated to an actual circuit it felt desirable to allow this. But now there will be no way to represent it in text. Perhaps it’s time to “auto-untangle” the components of multi-register operations in the visual interface.
The text was updated successfully, but these errors were encountered: