Typically, when using small number of qubits we want to use the LocalSimulator.
For larger numbers, we want to use the CloudSimulator.

Initially, we don't want the user to choose which simulator to use, but we want to display the simulator in use.

Automatically switch to CloudSimulator once 8 qubits are used.
Later, we want to make this configurable.

Gates are currently added after each other in the QubitFlow (as they are positioned in an HBox).
It should be possible to skip a few positions and at gates at different locations.

The project is (c) Gluon, with a BSD license.

This button would clear all the gates, and go back to 2 qubits.

Visualise status between 2 steps.

Right now, refreshrequests are sent for each qubit being altered in a gate.
By the time the Cloud comes back with a solution, the other qubits have their gates assigned, but since the refreshrequest wasn't cleared yet, no new calculation is requested.

The refactory in the QubitFlow (from HBox to Pane) breaks rendering using the Renderer.

Right-click on a gate to remove it. It will still be used by the calculations

QFT gate requires complex numbers. Other gates as well, so it's time to introduce them.

For now, only implement control qubit on 0, and NOT gate at 1

At this moment, the Simulator.calculateResults(Model m) method takes the Model, which also has properties that are not relevant to calculations.
When doing calculations in the Cloud, the Model won't be there.
We need an intermediate representation, sort of JSON, to represent the gates.

When a new qubit is added, the label states it is in |0> but the measured value shows 50%

The pom.xml does not enables access to the maven central snapshot repository

The UI representation of gates can differ from the written representation (in a JSON-style), and that representation still differs from the actual gate operations. For example, when we encounter a CNOT13, we first do a swap, then a CNOT, then a reverse swap.

With the new approach, we can visualise the probabilities of individual qubits, but not yet the probability vector as a vector.

A SWAP gate links 2 qubits and swaps them. The resulting string representation for this is [... X ... X ...]
For example, a 5 qubit system with a swap gate between qubit 0 and 3 would be
[X,I,I,X,I]

We used to add this as an overlay, but it needs to be done in the same way a regular (block)gate is added.

The visualisation of CNot draws the line between the control qubit and the target qubit wrong in case the index of the control qubit is larget than the index of the target qubit.

Combine SWAP and CNOT01 to achieve CNOTxy

This leads to a non-vertical line in e.g. CNot (top symbol is a few pixels more to the right than bottom pixel)

Similar to many circuit visualisation, use a double line to show a qubit flow once the qubit is measured.

The QFT gate spans at least 2 qubits. The gate spans adjacent qubits. For every qubit covered by this gate, we add "QFT" in the gate description.

./gradlew test
should execute all unit tests.

Remove the javafxmobile plugin from the gradle build as it is not required when having dependencies on Charm Down.

The class org.redfx.strangefx.render.Renderer contains a static variable myStage. When executing the example from https://github.com/johanvos/quantumjava and the class org.redfx.javaqc.ch05.cnot.Main the results displayed are not what was calculated.
I suspect the shared variable leads to multiple overrides of some displayed variables. The visible results might even change for each execution. Also, the barchart which is only visible for one window backs up this theory.
When I start only one part of the program like run10(); and comment the others the display is correct.

The double lines should only start at the point of the measurement gate, not before.
See quantum teleportation sample.

Test the actual results instead of only the size of the results

Allow the project to be built with maven

when running
javafx:run, the drag and drop editor should be shown.

a CNOT gate contains a control qubit and a target qubit. The gate has therefor 2 parts: "C0" at the location of the control qubit and "CNOT" at the location of the target qubit.
For example, in a 5 qubit (0..4) system, this is a valid step: [I,C0,I,CNOT,I]

QubitBoards returned by Renderer will keep a listener on the endStates which can't be removed

When a cloud calculation is done, the number of qubits might already have been changed, and that will lead to error results. We can fix that by requesting new calculations, but there will also be a error since the size of the endstates might not correspond to the size of the qubits.

starting with 0.0.4, the symbols in a CNOT are reversely rendered.