stewdio / q.js Goto Github PK

Qubit needs methods for converting between matrices and Bloch Spheres. From 𝒂 and 𝒃 to θ and ϕ and back again. And also from θ and ϕ to XYZ; coordinates for the point on the surface of the sphere.

Match h3 and h4 tags that have id attributes and place a “section” icon in the left gutter that is a hyperlink to that heading. This will make it easy to bookmark or copy the link for pasting elsewhere.

Now that we’re using Three.js (for Bloch Sphere visualization) we should look in to making a custom “slim” build with only the components we need. Lightweight is key. Make it slim!

We need to create a Q.History documentation page that is similar in nature to the existing Q class documentation pages. See Q-ComplexNumber.html as an example.

Hello,

First, thanks for this nice project. I'm interesting in using the library behind this project, but is there a way to perform interactive mesurements, i.e. just measure one qubit without measuring everything, so that I can, after receiving the measurement, eventually apply other gates, measure other qubits... Since I want an actual user to provide the measurements to do in real time, gates controlled by measurement outcomes are not enough for my need.

Thanks.

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.

Create new CSS rules that increase font size / leading, put main at left: 0, and morph nav in to a bar at the top of the page that scrolls with the doc. Not break-points. Sensible rules.

It’s kind of gross to see matrix definitions that include new Q.ComplexNumber( blah, blah ) rather than something simple like '-i'. Something like this within the Matrix constructor might be nice:

if( typeof n === 'string' ){

     n = Q.ComplexNumber.fromString( n )
}

But that means having to write Q.ComplexNumber.fromString( n )...
So this issue is a note-to-self to write that!

Now that multi-register creation is possible through the Circuit editor, we need to be able to drag those operations to new positions without destroying them.

If all components of a multi-register operation are dragged together the interface should treat them as intact, sending a set$ command to the circuit for the new position. (If portions of the operation will fall outside of the circuit’s moment and register bounds it is the job of the set$ routine to handle this.)

If some (but not all) components of a multi-register operation are dragged to new registers within the same moment—and these new positions do not overwrite a sibling component—the operation should also remain intact, sending a set$ command for the whole operation with a modified register indices array that addresses the dragged components’ new positions. If the drag-and-drop overwrites any sibling components then more logic is needed to determine how to proceed.

If some (but not all) components of a multi-register operation are dragged to a new moment then the operation must be broken in to its individual components. The control component should resolve to an identity gate. The remaining should resolve to the overall operation—for example the target component of a controlled-not gate should resolve to a Pauli-X operation.

When integrating ComplexNumber in to Q, I commented out the check in Qubit initialization for a^2 + b^2 = 1. (I just wanted everything to function again as quickly as possible.) So we (I?) need to re-implement that using ComplexNumber now...

Currently the axis labels on the Bloch Sphere explorer attempt to always face the camera (like billboarded sprites) but instead rotate in strange ways. The proper way to fix this is to raycast from the anchor in 3D space out toward the viewer and use point where that ray intersects with the viewing plane to fix a 2D label instead. Who want to help make this happen? 😉

Currently each time updateBlochVector is called it attempts to scale the Theta ring and also recalculate the geometry for the Phi arc. This is waaaay unnecessary. Should instead only re-scale and only recalculate geometry if Theta or Phi have changed respectively.

Once circuit simulation is in place we’re going to want to go hard on optimization—while still attempting to keep the source code readable and grokable. Moving Q.Matrix computation to the GPU seems like a good place to start. A lot of ground to cover between now and then.

Hi Stewart,

I love your work. Happy anniversary for Q.js!

When run XHHH in your live editor, the results make sense to me. But the results you give are inconsistent with results of other simulators such as https://quantum-circuit.com/ and http://oreilly-qc.github.io/ Results from your live editor are grouped - yet results from the other simulators are interspersed.

Can you explain why these results are so inconsistent? Another library which returns results similar to yours for this example is https://github.com/adamisntdead/qics

Currently the Matrix documentation shows the code definition of each constant as well as the mathematical representation. But it does not explain what that constant is useful for. For example, what is the HADAMARD useful for? Write descriptions for all.

In addition to the current acceptable arguments for Q.Matrix, it ought to accept a Template literal (Template string) as a solo argument to make it trivially easy for something like this:

var m = new Q.Matrix(`
    1 2 3 4
    5 6 7 8`)

This makes the task of creating arbitrary matrices much more human readable than passing nested Arrays, or even just a series of Arrays. Parsing the arguments is simple: line returns indicate row breaks and white space indicates column breaks.

But the complication is that these tokens then need to be passed to Q.ComplexNumber (which Q.Matrix already does internally), and that constructor does not have a parser for interpreting a String. For example, var c = new Q.ComplexNumber( '1+2i' ) is not a handled use case. Yet.

Anyone want to write that complex number String parser? 😅
That’s already an open issue here: #4
(And although there’s a pull request attached to that, the code changes in that request do not seem to correspond to Q.ComplexNumber at all.)

The ComplexNumber class is now in place. It is integrated in to Matrix but not Qubit. We need to finish the integration and test drive it. Once we’re satisfied all is functioning properly we can update the docs to reflect this.

The chart on /index.html explaining how to open the JavaScript console on various platforms needs icons for Firefox, Chrome, Safari, Edge, (Opera?), as well as macOS and Windows. (Similar to the compatibility chart on https://spacerocks.moar.io/) Additionally it needs illustrations for the keyboard keys to visually reiterate that these are keyboard commands.

Currently Q.Circuit.evaluate does not correctly handle SWAP operations. (Thankfully, a SWAP gate can be emulated by three zippered CNOT gates instead.) And we’re also not correctly handling controlled operations that have more than one control or more than one target.

Both issues are tied together. Currently we assume component #0 of a multi-register gate is the control and subsequent components are the targets. This means a SWAP operation is interpreted as being a controlled operation of type SWAP. This is unintended.

We’re going to have to rethink how we designate what is a control and what is a target.

Add ability to export circuits as comma-separated values, tab-separated values, and a meta routine for arbitrary-character-separated values.

Once this is functional, add a button to the circuit editor for downloading the circuit in these formats.

Then need the converse; the ability to ingest a circuit from CSV, TSV, XSV, and the ability to drop such a file on to a circuit editor and have it respond accordingly. (Also include ability to drop a text file on to a circuit editor and ingest using the Circuit.fromText routine.)

Currently the circuit editor interface uses fancy z-index / ::before / ::after CSS maneuvers to create coherent outlines and shadows for complex selection shapes. But some inconsistencies remain. Example: Operations along the top register or the first moment when selected lose their upper or left edge outlines because the header cell borders take precedence.

In general the overall strategy of z-index use needs to be given a closer look. Obviously the user-dragging clipboard needs to be the highest z-index—even above the drop-down menu as it is rendered in mobile mode. But situations like rendering the circuit editor and Bloch Sphere visualizer on the same page offer more complex sorting situations.

Investigate the current uses of z-index. Come up with a strategy for organizing z-index “zones” for various uses. Implement.

Would be nice to have a “notes” feature so that notes can be tied to specific “rectangular” areas of a circuit. For example: create a sample Grover search circuit and to label which part is the setup vs. the oracle, etc.

• Need diegetic, billboarded axes labels that follow the axes arrows.
• Need θ (theta) and ϕ (phi) labels with arc lines along the Z (up) axis.
• Need call-out latitude circle and call-out longitude circle that follow the Bloch Vector surface point.