some work here
This commit is contained in:
parent
30f75f7bb2
commit
35b7f3f088
|
@ -84,6 +84,7 @@ To allow the implementation of possible hardware related gates the class
|
|||
\lstinline{cdouble} array and builds a gate from it.
|
||||
|
||||
\subsubsection{Circuits}
|
||||
\label{ref:pyqcs_circuits}
|
||||
|
||||
As mentioned in \ref{ref:quantum_circuits} quantum circuits are central in
|
||||
quantum programming. In the implementation great care was taken to make
|
||||
|
@ -211,4 +212,69 @@ The edges are stored in an adjacency matrix
|
|||
\end{aligned}
|
||||
\end{equation}
|
||||
|
||||
Because it is
|
||||
Recalling some operations on the graph as described in
|
||||
\ref{ref:dynamics_graph}, \ref{ref:meas_graph} or Lemma \ref{lemma:M_a} one
|
||||
sees that it is important to efficiently access and modify the neighbourhood of
|
||||
a vertex. To ensure good performance when accessing the neighbourhood while
|
||||
keeping the memory requirements low a linked list-array hybrid is used to store
|
||||
the adjacency matrix. For every vertex the neighbourhood is stored in a sorted
|
||||
linked list (which is a sparse representation of a column vector) and these
|
||||
adjacency lists are stored in a length $n$ array.
|
||||
|
||||
Using this storage method all operations including searching and toggling edges
|
||||
are inherite their time complexity from the sorted linked list.
|
||||
|
||||
\subsubsection{Operations on Graphical States}
|
||||
|
||||
Operations on Graphical States are divided into three classes: Local Clifford
|
||||
operations, the CZ operation and measurements. The graphical states are
|
||||
implemented in \lstinline{C} and are exported to python3 in the class
|
||||
\lstinline{RawGraphState}. This class has three main methods to implement the
|
||||
three classes of operations.
|
||||
|
||||
%\begin{description}
|
||||
% \item[\lstinline{RawGraphState.apply_C_L}]{This method
|
||||
% implements local clifford gates. It takes the qbit index and the index
|
||||
% of the local Clifford operator (ranging form $0$ to $23$).}
|
||||
% \item[\lstinline{RawGraphState.apply_CZ}]{Applies the $CZ$ gate to the
|
||||
% state. The first argument is the act-qbit, the second the control
|
||||
% qbit (note that this is just for consistency to the $CX$ gate).}
|
||||
% \item[\lstinline{RawGraphState.measure}]{Using this method one can
|
||||
% measure a qbit. It takes the qbit index as first argument and
|
||||
% a floating point (double precision) random number as second
|
||||
% argument. This random number is used to decide the measurement outcome
|
||||
% in non-deterministic measurements. This method returns either $1$ or $0$ as
|
||||
% a measurement result.}
|
||||
%\end{description}
|
||||
|
||||
Because this way of modifying the state is rather unconvenient and might lead to many
|
||||
errors the \lstinline{RawGraphState} is wrapped by the pure python class
|
||||
\lstinline{pyqcs.graph.state.GraphState}. It allows the use of circuits as described
|
||||
in \ref{ref:pyqcs_circuits} and provides the method \lstinline{GraphState.to_naive_state}
|
||||
to convert the graphical state to a dense vector state.
|
||||
|
||||
\subsubsection{Pure \lstinline{C} Implementation}
|
||||
|
||||
Because python tends to be rather slow and might not run on any architecture
|
||||
a pure \lstinline{C} implementation of the graphical simulator is also provided.
|
||||
It should be seen as a reference implementation that can be extended to the needs
|
||||
of the user.
|
||||
|
||||
This implementation reads byte code from a file and executes it. The execution is
|
||||
always done in three steps:
|
||||
|
||||
\begin{enumerate}[1]
|
||||
\item{Initializing the state according the the header of the bytecode file.}
|
||||
\item{Applying operations given by the bytecode to the state. This includes local
|
||||
Clifford gates, $CZ$ gates and measurements (the measurement outcome is ignored).}
|
||||
\item{Sampling the state according the the description given in the header of the byte code
|
||||
file and writing the sampling results to either a file or \lstinline{stdout}. }
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Utilities}
|
||||
|
||||
TODO
|
||||
|
||||
\subsection{Performance}
|
||||
|
||||
TODO
|
||||
|
|
|
@ -581,6 +581,7 @@ one specific operation on graph states \cite{andersbriegel2005}.
|
|||
|
||||
|
||||
\subsubsection{Dynamics of Graph States}
|
||||
\label{ref:dynamics_graph}
|
||||
|
||||
So far the graphical representation of stabilizer states is just another way to
|
||||
store basically a stabilizer tableaux that might require less memory than the
|
||||
|
@ -715,6 +716,7 @@ represent any stabilizer state. If one wants to do computations using this
|
|||
formalism it is however also necessary to perform measurements.
|
||||
|
||||
\subsubsection{Measurements on Graph States}
|
||||
\label{ref:meas_graph}
|
||||
|
||||
This is adapted from \cite{andersbriegel2005}; measurement results and updating
|
||||
the graph after a measurement is described in \cite{hein_eisert_briegel2008}.
|
||||
|
|
Loading…
Reference in New Issue
Block a user