added something about future work on the sumulator
This commit is contained in:
parent
c30cc44c40
commit
0c99006196
|
@ -301,7 +301,7 @@ states has yet to be implemented but can be done in polynomial time
|
||||||
|
|
||||||
Writing circuits out by hand can be rather painful. The function\\
|
Writing circuits out by hand can be rather painful. The function\\
|
||||||
\lstinline{pyqcs.list_to_circuit} Converts a list of circuits to a circuit.
|
\lstinline{pyqcs.list_to_circuit} Converts a list of circuits to a circuit.
|
||||||
This is particularely helpful in combination with python's
|
This is particularly helpful in combination with python's
|
||||||
\lstinline{listcomp}:
|
\lstinline{listcomp}:
|
||||||
|
|
||||||
\begin{lstlisting}[caption={Generating a Large Circuit Efficiently}]
|
\begin{lstlisting}[caption={Generating a Large Circuit Efficiently}]
|
||||||
|
@ -473,3 +473,26 @@ lengths it is important to account for this virtual performance boost when
|
||||||
comparing with other simulation methods. This explains why the circuit length
|
comparing with other simulation methods. This explains why the circuit length
|
||||||
in Figure \ref{fig:scaling_qbits_linear} had to be scaled with the qbit number.
|
in Figure \ref{fig:scaling_qbits_linear} had to be scaled with the qbit number.
|
||||||
|
|
||||||
|
\subsection{Future Work}
|
||||||
|
|
||||||
|
Although the simulator(s) are in a working state and have been tested there is
|
||||||
|
still some work that can be done. A noise model helping to teach and analyze
|
||||||
|
noisy execution is one particularly interesting piece of work that should be
|
||||||
|
done. To allow a user to execute circuits on other machines, including both
|
||||||
|
real hardware and simulators, a module that exports circuits to OpenQASM
|
||||||
|
\cite{openqasm} seems useful.
|
||||||
|
|
||||||
|
The current implementation of some graphical operations can be optimized. While
|
||||||
|
clearing VOPs as described in \ref{ref:dynamics_graph} the neighbourhood of
|
||||||
|
a vertex is toggled for every $L_a$ transformation. This is the most straight
|
||||||
|
forward implementation but often the $L_a$ transformation is performed several
|
||||||
|
times on the same vertex. The neighbourhood would have to be toggled either
|
||||||
|
once or not at all depending on whether the number of $L_a$ transformations is
|
||||||
|
odd or even.
|
||||||
|
|
||||||
|
When toggling an edge the simulator uses a series of well tested basic linked
|
||||||
|
list operations: Searching an element in the list, inserting an element into
|
||||||
|
the list and deleting an element from the list. This is known to have no bugs
|
||||||
|
but the performance could be increased by operating directly on the linked
|
||||||
|
list. Some initial work to improve this behaviour is already done but does not
|
||||||
|
work at the moment.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user