|
|
|
|
Most of them use graphical objects linked together.
The states are only represented in input and output.
The intermediate states don't seem to need special processing.
Parameters are entered via system windows and the objects can't be moved on the screen from one place to another.
Example : jQuantum.
|
|
jQuantum
|
|
|
|
|
Here is another software of the same nature, in which interface seems to be older (~1995) : Qgol.
|
|
Qgol
|
|
|
|
|
To enter-parameters through a system of windows can necessitate a large amount of such windows: Quantum Computer Simulator (1).
|
|
Quantum Computer Simulator (1)
|
|
|
|
|
The limits of such graphical interfaces are sometimes emphasized by the authors themselves. For example Quasi.
But is it only an ergonomic problem or something more linked with representations ?
|
|
Quasi
|
|
|
|
|
Some simulators don't show mathematical concepts but physical ones, like Quantum Computer Simulator (2).
However this intention in not ours.
|
|
Quantum Computer Simulator (2)
|
|
|
|
|
Furthermore, some languages are script-oriented and not graphical.
Example : LanQ.
The style of programming that can be seen here could let one believe that quantum programming has the same control structures
as the classical programming; that the difference-only rests within the data structures themselves.
The problem with this kind of example is that it seems to be necessary to create as much libraries as algorithms.
Therefore implyings that the question of programming is reported in libraries.
|
|
langQ
|
preamble
basis
existing tools
representations