Mobile users might want to drag multiple gates at the same time

Currently the 'quantum state display' gates are just showing decohered probabilities. The CircuitStats class needs to compute the values to feed those gates.

The drag-hint wire shown when dragging counts as an actual qubit, doubling the amount of work that must be done when the user is dragging. The simulator should opportunistically avoid simulating that extra qubit, since it has no operations.

Currently control nodes apply to entire columns and are dragged around separately from gates. This is not ideal: it forces extra columns when doing independent CNOTs, it adds extra clicks and drags for moving things around, and internally the way it affects the tensor product is... "unique".

Current ideas to improve:

• Have "upward" and "downward" control nodes. When they're dragged onto the circuit, they link to the next gate in their facing direction (and no others). (What about "both ways"? "full column"? Next-two-above?)
• Dragging the control nodes around breaks them away from linked gates, but dragging the gate brings the control node along for the ride. Similarly, gates can't be moved into an existing link (they must go to either side), but control nodes can be.
• Swap gates should never be unpaired. Come in as a 2-qubit gate that allows its ends to be dragged vertically apart, and then moves as if it was an n-qubit gate.

It would be useful to be able to make custom gates.

A few possible ideas:

• Free-form text entry of coefficients, with a singular value decomposition to repair any non-unitaryness.
• Drag a box around existing circuit area.
• How to allow for time-sensitivity?
• How to allow for gates that can apply to any number of qubits?

The code is going through three transformations (traceur, concat, uglify). Figuring out which file line 13473 is from by hand is annoying. Get each transformation step's sourcemap bits working.

Drawing the gate tooltips is currently literally slower than the 12-qubit simulation and superposition-drawing. The problem is probably the bloch sphere bit.

• Use a textbox instead of a drawn box for error info, so the information can be trivially copied
• Have a fallback CircuitStats that allows the circuit to still be edited and drawn, even though the outputs aren't working
• Detect GPU pipeline failing on startup, warn user about it, and tell them to complain
• Provide a mailto: link as well as a github issues link
• Include the JSON'd circuit and a screenshot of the canvas in the error info?

When dragging a sparse multi-qubit gate (e.g. a swap) as a single unit, the individual gates making it up could get closer together if doing so will let the thing fit on the circuit.

Currently forced to use 3 wires. Would be better if adding/removing wires was possible, with appropriate changes in displayed information.

Although touch interaction works fine on my windows laptop with a touch screen, it is completely broken on my nexus phone. Gates are somehow hard to pick up, and tend to drop during a drag. Often I try to grab a gate and instead scroll the screen. Figure out why, and fix it.

Currently the X^t/Z^t gates use the same cycle animation as the Y^t gate. But, since they rotate around different axes, it's a bit confusing for their cycle animation to look like the Y rotation.

Currently, a controlled-not whose control wire crosses over a 2x2 density matrix will not cause a spacer column to be inserted. The result is the wire being in the way of the density matrix display, and possible confusion over whether or not it is conditioning the display.

Extract the logic used to draw the control wires into functions, and re-use those functions to cause spacers to be introduced in this situation.

When two wires are showing, it's impossible to place a 4-qubit increment gate.

The circuit should expand to be at least as large as the dragged gate.

Computing a density matrix from the full superposition basically amounts to a matrix adjoint-squaring. The matrix has a column for each kept-value configuration and a row for each not-kept-value configuration, so it usually ends up highly rectangular (many more rows than columns).

Currently the code computes the density matrix by doing the full matrix multiplication in a single shader by nesting as many loops as necessary. This is probably the wrong approach. It's unclear if using a fold-based approach would be better, or if computationsof the mixed state of each wire can be overlayed in a useful way. Investigate.

The code only supports single-wire gates (+ control wires). What about gates that apply to multiple wires, like the swap gate or big QFTs?

Long circuits go off the edge of the screen. Being able to scroll would let them get much longer.

Might cause performance issues.

The unit tests for CircuitStats were commented out during the shader refactor, and need to be polished back into working condition.

A measurement gate would be useful, even if it is exactly equivalent to a controlled-not onto an otherwise unused qubit.

Currently NaNs show in the chance and Bloch gates (when you post-select down to a contradiction), but the density and amplitude displays just end up blank.

https://github.com/Strilanc/Quirk/blob/master/src/fallback.js#L120

BROWSER USER AGENT for one, more details for the other.

No operation hint should be shown at all, just like the other displays, since they apply no operation.

When the user hovers over one of the state displays, the numeric representation of the value they are hovering over should be shown as a tooltip.

Showing the state of an X^t on one wire, conditioned on a wire that's been hit with H H, shows rounding noise instead of NaN.

If the visualizations are going to continue to be useful past 5-6 qubits, there needs to be a way to filter them down. A few ideas:

• A "quantum peek" gate could show the amplitudes on a wire. Not sure how to deal with superposition. Easiest would be to say "in superposition" whenever there's more than one case to handle (after taking the controls into account).
• Animating the state visualalization when an operation is highlighted. Gray out the not-affected-due-to-controls amplitudes. Show pairings when dealing with a single qubit gate, to make it clearer how the values are interacting.
• Arranging the states with a space filling curve, instead of directly by their binary index, might make the same operation on another qubit "look" the same.
• Amplify sizes when everything is small?

Single-wire gates have sparse matrices. Taking advantage of that could give significant performance boosts and allow more wires.

Currently non-unit gates can overhang the circuit, can overlap other gates, and have hit targets smaller than their drawn span. Fix all that.

The tool is showing too much too fast with no context for people to learn it easily. Starting with a small number of gates, and maybe some hover hints about basic actions, could solve that.

The peek gate can give per-write conditional probabilities, but seeing intermediate partial quantum states would also be useful.

When I drag a gate using the touchpad on my mac, quirk doesn't redraw until after I end the drag.

Blocked by #73

There's a white space at the bottom, instead of more yellow.

This can be achieved via requestAnimationFrame.

When a single-qubit gate starts snapping to the circuit, the vertical height where it switches between wires seems wrong. This is because the grab-offset is not the relevant part anymore.

When snapping starts, round the drag offset to the nearest 'center of wire' offset.

It's a bit confusing that you need to have a gate on the second wire to see the "add a wire" wire. Just show it anytime drags are happening.

Incrementing could be done significantly cheaper if it was a single gate that touched multiple qubits and acted like a shift in texture-land.

Currently can't, for example, put two hadamard gates in the same vertical column. Causes circuits to unnecessarily spread out horizontally.

Instead of crashing and burning and drawing nothing when rendering fails, most of the content should be present and a pointer at the relevant bug should be shown.

Apparently gl.getShaderPrecisionFormat returns null or undefined in some cases, so the current code just crashes when high precision isn't supported. The webgl code needs to be tested on lower capability machines. Ideally automatically.

Look for services that can run CI tests including webgl on a variety of machines.

There's a bunch of code intended to work when webglcontextlost/webglcontextrestored happens, but it's not exercised.

(Every once in awhile I leave Quirk alone, come back later, and the canvas is blank until I interact with it. This might be related?)

Should be able to come back to a circuit later, or on another machine.

Current idea is to just have an auto-updating anchor element that always points to the "current" circuit, so saving is just a matter of bookmarking. Most of the code is already done, but it was de-activated by the ES6 rewriting noise.

Being able to hit gates with modifier tools might make the interface sparser by removing the need for having all the various square roots and inverses available up front...?

Hello Strilanc,

it was mostly working well enough for me, but when trying to return to a url via my history I got a another error.

URL
http://algorithmicassertions.com/quirk#circuit={%22cols%22:[[%22X%22,%22%E2%80%A2%22,%22X%22],[1,%22X^%E2%85%93%22,%22X^%E2%85%93%22],[1,1,%22X^%E2%85%93%22],[%22Bloch%22,%22Bloch%22,%22Bloch%22],[1,%22%E2%80%A2%22,%22%E2%80%A2%22,%22X%22],[1,%22%E2%97%A6%22,%22%E2%97%A6%22,%22X%22]]}

BROWSER USER AGENT
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Firefox/38.0

ERROR OBJECT
Error: c: malformed URI sequence in src/main.js

ERROR LOCATION
[email protected]:957:1
[email protected]:958:29
@src.min.js:960:53
[email protected]:23:13
[email protected]:28:49
@src.min.js:1607:89

When a gate is controlled, dragging the control or the gate should break the connection but dragging the connection itself should move the whole thing as a unit.

When Quirk is running in a context where history modification violates the same-origin policy (e.g. when running locally from a file:// uri), it shows the error box every time the circuit is modified due to an exception being thrown when touching the history. Instead, it should fall back to a 'current circuit' link.