Skip to content
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

Proposal to change text-as-input syntax #22

Open
stewdio opened this issue May 2, 2020 · 0 comments
Open

Proposal to change text-as-input syntax #22

stewdio opened this issue May 2, 2020 · 0 comments

Comments

@stewdio
Copy link
Owner

stewdio commented May 2, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant