some work as suggested by Simon
This commit is contained in:
parent
1a9123e82f
commit
102ed77cba
Binary file not shown.
Before Width: | Height: | Size: 133 KiB After Width: | Height: | Size: 129 KiB |
|
@ -4,11 +4,11 @@
|
||||||
\section{Source Code for the Benchmarks}
|
\section{Source Code for the Benchmarks}
|
||||||
\label{ref:code_benchmarks}
|
\label{ref:code_benchmarks}
|
||||||
|
|
||||||
The benchmarks used in \ref{ref:performance} are done using this code. Note
|
The benchmarks used in \ref{ref:performance} are based on this code. Note
|
||||||
that the execution time is measured which is inherently noisy. To account for
|
that the execution time is measured which is inherently noisy. To account for
|
||||||
the noise several strategies are used:
|
the noise several strategies are used:
|
||||||
|
|
||||||
\begin{enumerate}[1]
|
\begin{enumerate}[1.]
|
||||||
\item{The same circuit is applied to the starting state several times. The
|
\item{The same circuit is applied to the starting state several times. The
|
||||||
minimal result is used as the noise must be positive}
|
minimal result is used as the noise must be positive}
|
||||||
\item{Several circuits are applied to the starting state. The remaining
|
\item{Several circuits are applied to the starting state. The remaining
|
||||||
|
@ -30,15 +30,9 @@ The code used to benchmark the three regimes is analogous and not included here.
|
||||||
|
|
||||||
Because the whole graphs are barely percetible windows have been used
|
Because the whole graphs are barely percetible windows have been used
|
||||||
in Figure \ref{fig:graph_high_linear_regime} and Figure \ref{fig:graph_intermediate_regime}.
|
in Figure \ref{fig:graph_high_linear_regime} and Figure \ref{fig:graph_intermediate_regime}.
|
||||||
For the sake of completeness the whole graphs are included here in Figure \ref{fig:graph_low_linear_regime_full},
|
For the sake of completeness the whole graphs are included here in
|
||||||
Figure \ref{fig:graph_intermediate_regime_full} and Figure \ref{fig:graph_high_linear_regime_full}.
|
Figure \ref{fig:graph_intermediate_regime_full} and Figure \ref{fig:graph_high_linear_regime_full}.
|
||||||
|
|
||||||
\begin{figure}[H]
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{graphics/graph_low_linear_regime.png}
|
|
||||||
\caption[Typical Graphical State in the Low-Linear Regime]{Typical Graphical State in the Low-Linear Regime}
|
|
||||||
\label{fig:graph_low_linear_regime_full}
|
|
||||||
\end{figure}
|
|
||||||
|
|
||||||
\begin{figure}[H]
|
\begin{figure}[H]
|
||||||
\centering
|
\centering
|
||||||
|
@ -57,9 +51,9 @@ Figure \ref{fig:graph_intermediate_regime_full} and Figure \ref{fig:graph_high_l
|
||||||
\section{Code to Generate the Example Graphs}
|
\section{Code to Generate the Example Graphs}
|
||||||
\label{ref:code_example_graphs}
|
\label{ref:code_example_graphs}
|
||||||
|
|
||||||
This code has been used to generate the example graphs used in
|
This code has been used to generate the example graphs in \ref{ref:performance}
|
||||||
\ref{ref:performance}. Note that generating the graph is done using a random
|
and \ref{ref:complete_graphs}. Note that generating the graph is done with
|
||||||
circuit as used in \ref{ref:code_benchmarks}. The generated \lstinline{dot}
|
a random circuit as in \ref{ref:code_benchmarks}. The generated \lstinline{dot}
|
||||||
code is converted to an image using
|
code is converted to an image using
|
||||||
\lstinline{dot i_regime.dot -Tpng -o i_regime.png}.
|
\lstinline{dot i_regime.dot -Tpng -o i_regime.png}.
|
||||||
|
|
||||||
|
@ -69,17 +63,17 @@ code is converted to an image using
|
||||||
\section{Code to Benchmark \lstinline{ufunc} Gates against Python}
|
\section{Code to Benchmark \lstinline{ufunc} Gates against Python}
|
||||||
\label{ref:benchmark_ufunc_py}
|
\label{ref:benchmark_ufunc_py}
|
||||||
|
|
||||||
It has been mentioned several times that the implementation using
|
It has been mentioned several times that the implementation with
|
||||||
\lstinline{ufuncs} as gates is faster than using a \lstinline{python}
|
\lstinline{ufuncs} as gates is faster than a pure \lstinline{python}
|
||||||
implementation. To support this statement a simple benchmark can be used. The
|
implementation. To support this statement a simple benchmark is written. The
|
||||||
relatively simple Pauli $X$ is used, more complicated gates like $CX$ or $H$
|
relatively simple Pauli $X$ gate us implemented, more complicated gates like $CX$ or $H$
|
||||||
have worse performance when implemented in \lstinline{python}. The performance
|
have worse performance when written in \lstinline{python}. The performance
|
||||||
improvement when using the \lstinline{ufunc} is a factor around $6.4$ in this tested
|
improvement when in this example is a factor around $6.4$.
|
||||||
case. One must however note that the tested \lstinline{python} code is not
|
One must note that the tested \lstinline{python} code is not
|
||||||
realistic and in a possible applications there would be a significant overhead.
|
realistic and in a possible application there would be a significant overhead.
|
||||||
|
|
||||||
\lstinputlisting[title={Code to Benchmark \lstinline{ufunc} Gates against Python}, language=Python, breaklines=True]{extra_benchmark/benchmark.py}
|
\lstinputlisting[title={Code to Benchmark \lstinline{ufunc} Gates against Python}, language=Python, breaklines=True]{extra_benchmark/benchmark.py}
|
||||||
|
|
||||||
When using \lstinline{result_py[0::2] = qm_state[1::2]} the result is identical and
|
When using \lstinline{result_py[0::2] = qm_state[1::2]} the result is identical and
|
||||||
the performance is only increased by a factor around $1.7$. This method is however not
|
the performance is only increased by a factor around $1.7$. This method is not
|
||||||
applicable to general act-qbits and the bit mask has to be used.
|
applicable to general act-qbits and the bit mask has to be used.
|
||||||
|
|
|
@ -2,8 +2,8 @@
|
||||||
\chapter{Conclusion and Outlook}
|
\chapter{Conclusion and Outlook}
|
||||||
|
|
||||||
As seen in \ref{ref:performance} simulation using stabilizers is exponentially
|
As seen in \ref{ref:performance} simulation using stabilizers is exponentially
|
||||||
faster than simulating using state vectors. Using a graphical representation
|
faster than simulating with dense state vectors. The graphical representation
|
||||||
for the stabilizers is on average more efficiently than using a stabilizer
|
for stabilizer states is on average more efficiently than the stabilizer
|
||||||
tableaux. In particular one can simulate more qbits while only applying
|
tableaux. In particular one can simulate more qbits while only applying
|
||||||
Clifford gates.
|
Clifford gates.
|
||||||
|
|
||||||
|
@ -13,7 +13,7 @@ stabilizer code requires $5$ qbits to encode one logical qbit
|
||||||
\cite{nielsen_chuang_2010}. Several layers of data encoding increase the
|
\cite{nielsen_chuang_2010}. Several layers of data encoding increase the
|
||||||
number of required qbits exponentially.
|
number of required qbits exponentially.
|
||||||
|
|
||||||
Simulating in the stabilizer formalism is rather uninteresting from a physical
|
Simulating in the stabilizer formalism is uninteresting from a physical
|
||||||
point of view as basically no physically interesting simulations can be
|
point of view as basically no physically interesting simulations can be
|
||||||
performed: As shown in \ref{ref:meas_stab} probability amplitudes have to be
|
performed: As shown in \ref{ref:meas_stab} probability amplitudes have to be
|
||||||
$0, \frac{1}{2}, 1$; this leaves very few points in time that could be
|
$0, \frac{1}{2}, 1$; this leaves very few points in time that could be
|
||||||
|
@ -21,7 +21,7 @@ simulated by applying a transfer matrix. Algorithms like the quantum fourier
|
||||||
transform also require non-Clifford gates for qbit counts $n \neq 2, 4$.
|
transform also require non-Clifford gates for qbit counts $n \neq 2, 4$.
|
||||||
|
|
||||||
The basic idea of not simulating a state but (after imposing some conditions on
|
The basic idea of not simulating a state but (after imposing some conditions on
|
||||||
the Hilbert space) other objects that describe the state is extremely
|
the Hilbert space) other objects that describe the state is
|
||||||
interesting for physics as often the exponentially large or infinitely large
|
interesting for physics as often the exponentially large or infinitely large
|
||||||
Hilbert spaces cannot be mapped to a classical (super) computer. One key idea
|
Hilbert spaces cannot be mapped to a classical (super) computer. One key idea
|
||||||
to take from the stabilizer formalism is to simulate the Hamiltonian instead of
|
to take from the stabilizer formalism is to simulate the Hamiltonian instead of
|
||||||
|
@ -34,14 +34,14 @@ ground state of this Hamiltonian.
|
||||||
|
|
||||||
While trying to extend the stabilizer formalism one inevitably hits the
|
While trying to extend the stabilizer formalism one inevitably hits the
|
||||||
question:\\ \textit{Why is there a constraint on the $R_\phi$ angle? Why is it
|
question:\\ \textit{Why is there a constraint on the $R_\phi$ angle? Why is it
|
||||||
$\frac{\pi}{2}$?}\\ The answer to this question is hidden in the Clifford
|
$\frac{\pi}{2}$?}\\ The answer to this question can be found by taking a look
|
||||||
group. Recalling Definition \ref{def:clifford_group} the Clifford group is not
|
at the Clifford group. Recalling Definition \ref{def:clifford_group} the
|
||||||
defined to be generated by $H, S, CZ$ but by its property of normalizing the
|
Clifford group is not defined to be generated by $H, S, CZ$, but by its property
|
||||||
multilocal Pauli group. Storing and manipulating the multilocal Pauli group is
|
of normalizing the multilocal Pauli group. Storing and manipulating the
|
||||||
only so efficient (or possible) because it is the tensor product of Pauli
|
multilocal Pauli group is only so efficient (or possible) because it is the
|
||||||
matrices. A general unitary on $n$ qbits would be a $2^{n} \times 2^{n}$ matrix
|
tensor product of Pauli matrices. A general unitary on $n$ qbits would be
|
||||||
which requires more space than a dense state vector. The Clifford group is
|
a $2^{n} \times 2^{n}$ matrix which requires more space than a dense state
|
||||||
a group preserving this tensor product property.
|
vector. The Clifford group is a group preserving this tensor product property.
|
||||||
|
|
||||||
%{{{
|
%{{{
|
||||||
%When lifting the constraint that $\ket{\varphi}$ is stabilized by the multilocal Pauli
|
%When lifting the constraint that $\ket{\varphi}$ is stabilized by the multilocal Pauli
|
||||||
|
@ -103,10 +103,10 @@ a group preserving this tensor product property.
|
||||||
The stabilizer formalism as introduced in \ref{ref:stab_states} has since been
|
The stabilizer formalism as introduced in \ref{ref:stab_states} has since been
|
||||||
generalized to normalizers of a finite Abelian group over the Hilbert space
|
generalized to normalizers of a finite Abelian group over the Hilbert space
|
||||||
\cite{bermejovega_lin_vdnest2015}\cite{bermejovega_vdnest2018}\cite{vandennest2019}\cite{vandennest2018}.
|
\cite{bermejovega_lin_vdnest2015}\cite{bermejovega_vdnest2018}\cite{vandennest2019}\cite{vandennest2018}.
|
||||||
This allows to simulate more classes of circuits efficiently on classical computers
|
This allows to simulate more classes of circuits efficiently on classical
|
||||||
including the Quantum Fourier Transforms which is often believed to be
|
computers including the Quantum Fourier Transforms which is often believed to
|
||||||
responsible for exponential speedups. One must note that in the definition of
|
be responsible for exponential speedups. One must note that in the definition
|
||||||
the QFTs as in \cite{vandennest2018} the QFT depends on the Abelian group it
|
of the QFTs as in \cite{vandennest2018} the QFT depends on the Abelian group it
|
||||||
acts on. In particular the QFT on the group that decomposes the Hilbert space
|
acts on. In particular the QFT on the group that decomposes the Hilbert space
|
||||||
as seen in this paper ($Z_2^n$) is just the tensor product of the $H$ gates.
|
as seen in this paper ($Z_2^n$) is just the tensor product of the $H$ gates.
|
||||||
The QFT as used in \ref{ref:quantum_algorithms} for the phase estimation
|
The QFT as used in \ref{ref:quantum_algorithms} for the phase estimation
|
||||||
|
@ -117,6 +117,6 @@ the Clifford group \cite{vandennest2018}.
|
||||||
|
|
||||||
The exponential speedup of quantum computing is often attributed to
|
The exponential speedup of quantum computing is often attributed to
|
||||||
entanglement, superposition and interference effects
|
entanglement, superposition and interference effects
|
||||||
\cite{uwaterloo}\cite{21732}\cite{vandennest2018}. Stabilizer states
|
\cite{uwaterloo}\cite{21732}\cite{vandennest2018}. Stabilizer states show
|
||||||
however show both entanglement, superposition and interference effects;
|
entanglement, superposition and interference effects; as do computations using
|
||||||
as do computations done using general normalizers \cite{vandennest2018}.
|
general normalizers \cite{vandennest2018}.
|
||||||
|
|
|
@ -2,13 +2,13 @@
|
||||||
\chapter{Implementation}
|
\chapter{Implementation}
|
||||||
|
|
||||||
This chapter discusses how the concepts introduced before are implemented into
|
This chapter discusses how the concepts introduced before are implemented into
|
||||||
a simulator. Futher the infrastructure around the simulation and some tools are
|
a simulator. Further the infrastructure around the simulation and some tools are
|
||||||
explained.
|
explained.
|
||||||
|
|
||||||
The implementation is written as the \lstinline{python3} package \lstinline{pyqcs} \cite{pyqcs}. This allows
|
The implementation is written as the \lstinline{python3} package \lstinline{pyqcs} \cite{pyqcs}. This allows
|
||||||
users to quickly construct circuits, apply them to states and measure
|
users to quickly construct circuits, apply them to states and measure
|
||||||
amplitudes. Full access to the state (including intermediate states) has been
|
amplitudes. Full access to the states (including intermediate states) has been
|
||||||
priorized over execution speed. To keep the simulation speed as high as
|
prioritized over execution speed. To keep the simulation speed as high as
|
||||||
possible under these constraints some parts are implemented in \lstinline{C}.
|
possible under these constraints some parts are implemented in \lstinline{C}.
|
||||||
|
|
||||||
\section{Dense State Vector Simulation}
|
\section{Dense State Vector Simulation}
|
||||||
|
@ -23,30 +23,29 @@ useful features when it comes to computations:
|
||||||
\item{The projection on the integer states is trivial.}
|
\item{The projection on the integer states is trivial.}
|
||||||
\item{For any qbit $j$ and $0 \le i \le 2^n-1$ the coefficient $c_i$ is part of the $\ket{1}_j$ amplitude iff
|
\item{For any qbit $j$ and $0 \le i \le 2^n-1$ the coefficient $c_i$ is part of the $\ket{1}_j$ amplitude iff
|
||||||
$i \& (1 << j)$ and part of the $\ket{0}_j$ amplitude otherwise.}
|
$i \& (1 << j)$ and part of the $\ket{0}_j$ amplitude otherwise.}
|
||||||
\item{For a qbit $j$ the coefficients $c_i$ and $c_{i \hat{ } (1 << j)}$ are the conjugated coefficients.}
|
\item{For a qbit $j$ the coefficients $c_i$ and $c_{i \wedge (1 << j)}$ are the conjugated coefficients.}
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
Where $\hat{}$ is the binary XOR, $\&$ the binary AND and $<<$ the binary
|
Where $\wedge$ is the binary XOR, $\&$ the binary AND and $<<$ the binary
|
||||||
leftshift operator.
|
leftshift operator.
|
||||||
|
|
||||||
While implementing the dense state vectors two key points were allowing
|
While implementing the dense state vectors two key points were a simple way to
|
||||||
a simple and readable way to use them and simple access to the states by users
|
use them and easy access to the underlaying data. To meet both requirements
|
||||||
that want more information than an abstracted view could allow. To meet both
|
the states are implemented as Python objects that provide abstract features such
|
||||||
requirements the states are implemented as Python objects providing abstract
|
as normalization checking, checking for sufficient qbit number when applying
|
||||||
features such as normalization checking, checking for sufficient qbit number
|
a circuit, computing overlaps with other states, a stringify method and stored
|
||||||
when applying a circuit, computing overlaps with other states, a stringify
|
measurement results. To store the measurement results a NumPy \lstinline{int8}
|
||||||
method and stored measurement results. To store the measurement results
|
array \cite{numpy_array} is used; this is called the classical state. The
|
||||||
a NumPy \lstinline{int8} array \cite{numpy_array} is used; this is called the
|
Python states also have a NumPy \lstinline{cdouble} array that stores the
|
||||||
classical state. The Python states also have a NumPy \lstinline{cdouble} array
|
quantum mechanical state. Using NumPy arrays has the advantage that access to
|
||||||
that stores the quantum mechanical state. Using NumPy arrays has the advantage
|
the data is simple and safe while operations on the states can be implemented
|
||||||
that access to the data is simple and safe while operations on the states can
|
in \lstinline{C} \cite{numpy_ufunc} providing a considerable speedup
|
||||||
be implemented in \lstinline{C} \cite{numpy_ufunc} providing a considerable
|
\ref{ref:benchmark_ufunc_py}.
|
||||||
speedup \ref{ref:benchmark_ufunc_py}.
|
|
||||||
|
|
||||||
This quantum mechanical state is the component vector in integer basis
|
This quantum mechanical state is the component vector in integer basis
|
||||||
therefore it has $2^n$ components. Storing those components is acceptable in
|
therefore it has $2^n$ components. Storing those components is acceptable in
|
||||||
a range from $1$ to $30$ qbits; above this range the state requires space in
|
a range from $1$ to $30$ qbits; above this range the state requires space in
|
||||||
the order of $1 \mbox{ GiB}$ which is in the range of usual RAM sizes for
|
the order of magnitude $1 \mbox{ GiB}$ which is in the range of usual RAM sizes for
|
||||||
personal computers. For higher qbit numbers moving to high performance
|
personal computers. For higher qbit numbers moving to high performance
|
||||||
computers and other simulators is necessary.
|
computers and other simulators is necessary.
|
||||||
|
|
||||||
|
@ -72,7 +71,7 @@ A basic set of gates is implemented in PyQCS:
|
||||||
\item{Hadamard $H$ gate.}
|
\item{Hadamard $H$ gate.}
|
||||||
\item{Pauli $X$ or \textit{NOT} gate.}
|
\item{Pauli $X$ or \textit{NOT} gate.}
|
||||||
\item{Pauli $Z$ gate.}
|
\item{Pauli $Z$ gate.}
|
||||||
\item{The $S$ phase gate.}
|
\item{Phase gate $S$.}
|
||||||
\item{$Z$ rotation $R_\phi$ gate.}
|
\item{$Z$ rotation $R_\phi$ gate.}
|
||||||
\item{Controlled $X$ gate: $CX$.}
|
\item{Controlled $X$ gate: $CX$.}
|
||||||
\item{Controlled $Z$ gate: $CZ$.}
|
\item{Controlled $Z$ gate: $CZ$.}
|
||||||
|
@ -98,8 +97,8 @@ new_state = circuit * state
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
|
|
||||||
|
|
||||||
The elementary gates such as $H, R_\phi, CX$ are implemented as single gate
|
The elementary gates are implemented as single gate
|
||||||
circuits and can be constructing using the built-in generators. The generators
|
circuits and can be constructed using the built-in generators. These generators
|
||||||
take the act-qbit as first argument, parameters such as the control qbit or an
|
take the act-qbit as first argument, parameters such as the control qbit or an
|
||||||
angle as second argument:
|
angle as second argument:
|
||||||
|
|
||||||
|
@ -117,7 +116,7 @@ Out[2]: (0.7071067811865476+0j)*|0b0>
|
||||||
+ (0.7071067811865476+0j)*|0b11>
|
+ (0.7071067811865476+0j)*|0b11>
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
|
|
||||||
Large circuits can be constructed using the binary OR operator \lstinline{|} in
|
Large circuits can be built using the binary OR operator \lstinline{|} in
|
||||||
an analogy to the pipeline operator on many *NIX shells. As usual circuits are
|
an analogy to the pipeline operator on many *NIX shells. As usual circuits are
|
||||||
read from left to right similar to pipelines on *NIX shells:
|
read from left to right similar to pipelines on *NIX shells:
|
||||||
|
|
||||||
|
@ -141,7 +140,7 @@ Out[2]: (0.7071067811865477+0j)*|0b0>
|
||||||
\end{lstlisting}
|
\end{lstlisting}
|
||||||
%}
|
%}
|
||||||
|
|
||||||
A quick way to generate circuits programatically is to use the \lstinline{list_to_circuit}
|
A quick way to generate circuits programmatically is to use the \lstinline{list_to_circuit}
|
||||||
function:
|
function:
|
||||||
|
|
||||||
%\adjustbox{max width=\textwidth}{
|
%\adjustbox{max width=\textwidth}{
|
||||||
|
@ -168,7 +167,7 @@ For the graphical state $(V, E, O)$ the list of vertices $V$ can be stored impli
|
||||||
by demanding $V = \{0, ..., n - 1\}$. This leaves two components that have to be stored:
|
by demanding $V = \{0, ..., n - 1\}$. This leaves two components that have to be stored:
|
||||||
The edges $E$ and the vertex operators $O$. Storing the vertex operators is
|
The edges $E$ and the vertex operators $O$. Storing the vertex operators is
|
||||||
done using a \lstinline{uint8_t} array. Every local Clifford operator is
|
done using a \lstinline{uint8_t} array. Every local Clifford operator is
|
||||||
associated with an integer ranging from $0$ to $24$, their order is
|
associated with an integer ranging from $0$ to $23$. Their order is
|
||||||
|
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\begin{aligned}
|
\begin{aligned}
|
||||||
|
@ -216,20 +215,20 @@ The edges are stored in an adjacency matrix
|
||||||
Recalling some operations on the graph as described in
|
Recalling some operations on the graph as described in
|
||||||
\ref{ref:dynamics_graph}, \ref{ref:meas_graph} or Lemma \ref{lemma:M_a} one
|
\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
|
sees that it is important to efficiently access and modify the neighbourhood of
|
||||||
a vertex. To ensure good performance when accessing the neighbourhood while
|
a vertex. Also one must take care to keep the memory required to store a state
|
||||||
keeping the required memory low a linked list-array hybrid is used to store
|
low. To meet both requirements a linked list-array hybrid is used. For every
|
||||||
the adjacency matrix. For every vertex the neighbourhood is stored in a sorted
|
vertex the neighbourhood is stored in a sorted linked list (which is a sparse
|
||||||
linked list (which is a sparse representation of a column vector) and these
|
representation of a column vector) and these adjacency lists are stored in
|
||||||
adjacency lists are stored in a length $n$ array.
|
a length $n$ array.
|
||||||
|
|
||||||
Using this storage method all operations including searching and toggling edges
|
Using this storage method all operations - including searching and toggling edges -
|
||||||
inherite their time complexity from the sorted linked list.
|
inherit their time complexity from the sorted linked list.
|
||||||
|
|
||||||
\subsection{Operations on Graphical States}
|
\subsection{Operations on Graphical States}
|
||||||
|
|
||||||
Operations on Graphical States are divided into three classes: Local Clifford
|
Operations on Graphical States are divided into three classes: Local Clifford
|
||||||
operations, the CZ operation and measurements. The graphical states are
|
operations, the CZ operation and measurements. The graphical states are
|
||||||
implemented in \lstinline{C} and are exported to python3 in the class
|
implemented in \lstinline{C} and are exported to \lstinline{python3} in the class
|
||||||
\lstinline{RawGraphState}. This class has three main methods to implement the
|
\lstinline{RawGraphState}. This class has three main methods to implement the
|
||||||
three classes of operations.
|
three classes of operations.
|
||||||
|
|
||||||
|
@ -249,7 +248,7 @@ three classes of operations.
|
||||||
returns either $1$ or $0$ as a measurement result.}
|
returns either $1$ or $0$ as a measurement result.}
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
Because this way of modifying the state is rather unconvenient and might lead to many
|
Because this way of modifying the state is inconvenient and might lead to many
|
||||||
errors the \lstinline{RawGraphState} is wrapped by the pure python class\\
|
errors the \lstinline{RawGraphState} is wrapped by the pure python class\\
|
||||||
\lstinline{pyqcs.graph.state.GraphState}. It allows the use of circuits as
|
\lstinline{pyqcs.graph.state.GraphState}. It allows the use of circuits as
|
||||||
described in \ref{ref:pyqcs_circuits} and provides the method
|
described in \ref{ref:pyqcs_circuits} and provides the method
|
||||||
|
@ -258,7 +257,7 @@ vector state.
|
||||||
|
|
||||||
\subsection{Pure C Implementation}
|
\subsection{Pure C Implementation}
|
||||||
|
|
||||||
Because python tends to be rather slow \cite{benchmarkgame} and might not run on any architecture
|
Because python tends to be slow \cite{benchmarkgame} and might not run on any architecture
|
||||||
a pure \lstinline{C} implementation of the graphical simulator is also provided.
|
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
|
It should be seen as a reference implementation that can be extended to the needs
|
||||||
of the user.
|
of the user.
|
||||||
|
@ -267,37 +266,43 @@ This implementation reads byte code from a file and executes it. The execution i
|
||||||
always done in three steps:
|
always done in three steps:
|
||||||
|
|
||||||
\begin{enumerate}[1]
|
\begin{enumerate}[1]
|
||||||
\item{Initializing the state according the the header of the bytecode file.}
|
\item{Initializing the state according the header of the byte code file.}
|
||||||
\item{Applying operations given by the byte code to the state. This includes local
|
\item{Applying operations given by the byte code to the state. This includes local
|
||||||
Clifford gates, $CZ$ gates and measurements (the measurement outcome is ignored).}
|
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
|
\item{Sampling the state according the description in the header of the byte code
|
||||||
file and writing the sampling results to either a file or \lstinline{stdout}. }
|
file and writing the sampling results to either a file or \lstinline{stdout}. }
|
||||||
\end{enumerate}
|
\end{enumerate}
|
||||||
|
|
||||||
\section{Utilities}
|
\section{Utilities}
|
||||||
|
|
||||||
To make both using the simulators more convenient and to help with using them
|
The package \lstinline{pyqcs} ships with several utilities that are supposed to
|
||||||
in as scientific or educational context several utilities have been written.
|
make using the simulators more convenient. Some utilities are designed to help
|
||||||
This chapter explains some of them.
|
in a scientific and educational context. This chapter explains some of them.
|
||||||
|
|
||||||
\subsection{Sampling and Circuit Generation}
|
\subsection{Sampling and Circuit Generation}
|
||||||
|
|
||||||
The function \lstinline{pyqcs.sample} provides a simple way to sample from
|
The function \lstinline{pyqcs.sample} provides a simple way to sample from
|
||||||
a state. Copies of the state are made when necessary and the results are
|
a state. Copies of the state are made when necessary, and the results are
|
||||||
returned in a \lstinline{collections.Counter} object. Several qbits can be
|
returned in a \lstinline{collections.Counter} object. Several qbits can be
|
||||||
sampled at once; they can be passed to the function either as an integer which
|
sampled at once; they can be passed to the function either as an integer which
|
||||||
will be interpreted as a bit mask and the least significant bit will be sampled
|
will be interpreted as a bit mask, and the least significant bit will be sampled
|
||||||
first. When passing the qbits to sample as a list of integers the integers are
|
first. When passing the qbits to sample as a list of integers the integers are
|
||||||
interpreted as qbit indices and are measured in the order they appear.
|
interpreted as qbit indices and are measured in the order they appear.
|
||||||
|
|
||||||
If the keyword argument \lstinline{keep_states} is \lstinline{True} the
|
If the keyword argument \lstinline{keep_states} is \lstinline{True} the
|
||||||
sampling function will include the resulting states in the result. At the
|
sampling function will include the collapsed states in the result. At the
|
||||||
moment this works for dense vectors only. Checking for equality on graphical
|
moment this works for dense vectors only. Checking for equality on graphical
|
||||||
states has yet to be implemented but has $NP$ computational hardness
|
states is not implemented due to the computational hardness.
|
||||||
\cite{dahlberg_ea2019}.
|
\cite{bouchet1991} introduced an algorithm to test whether two VOP-free graph states
|
||||||
|
are equivalent with complexity $\mathcal{O}\left(n^4\right)$.
|
||||||
|
So checking for equivalency is $c-NP$ complete because the vertex operators have
|
||||||
|
to be checked as well. It might be necessary to compute all equivalent graphical
|
||||||
|
states. \cite{dahlberg_ea2019} showed that counting equivalent VOP-free
|
||||||
|
graphical states is $\#P$ complete. Showing that two graphical states are
|
||||||
|
equivalent might considerably hard.
|
||||||
|
|
||||||
Writing circuits out by hand can be rather painful. The function\\
|
Writing circuits out by hand can be inconvenient. 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 particularly helpful in combination with python's
|
This is particularly helpful in combination with python's
|
||||||
\lstinline{listcomp}:
|
\lstinline{listcomp}:
|
||||||
|
|
||||||
|
@ -308,41 +313,40 @@ circuit_H = list_to_circuit([H(i) for i in range(nqbits)])
|
||||||
The module \lstinline{pyqcs.util.random_circuits} provides the method described
|
The module \lstinline{pyqcs.util.random_circuits} provides the method described
|
||||||
in \ref{ref:performance} to generate random circuits for both graphical and
|
in \ref{ref:performance} to generate random circuits for both graphical and
|
||||||
dense vector simulation. Using the module \lstinline{pyqcs.util.random_graphs}
|
dense vector simulation. Using the module \lstinline{pyqcs.util.random_graphs}
|
||||||
one can generate random graphical states which is more performant than using
|
one can generate random graphical states which is faster than using random
|
||||||
random circuits.
|
circuits.
|
||||||
|
|
||||||
The function \lstinline{pyqcs.util.to_circuit.graph_state_to_circuit} converts
|
The function \lstinline{pyqcs.util.to_circuit.graph_state_to_circuit} converts
|
||||||
graphical states to circuits (mapping the $\ket{0b0..0}$ to this state).
|
graphical states to circuits (mapping the $\ket{0b0..0}$ to this state).
|
||||||
Using these circuits the graphical state can be copied or converted to a
|
By utilization of these circuits the graphical state can be copied or converted to a
|
||||||
dense vector state. Further it is a way to optimize circuits and later run them on
|
dense vector state. Further it is a way to optimize circuits and later run them on
|
||||||
other simulators. Also the circuits can be exported to \lstinline{qcircuit} code
|
other simulators. Also the circuits can be exported to \lstinline{qcircuit} code
|
||||||
(see below) which is a relatively readable way to represent graphical states.
|
(see below) which is a way to represent graphical states.
|
||||||
|
|
||||||
\subsection{Exporting and Flattening Circuits}
|
\subsection{Exporting and Flattening Circuits}
|
||||||
|
|
||||||
Circuits can be drawn using the \LaTeX package \lstinline{qcircuit}; all
|
Circuits can be drawn with the \LaTeX package \lstinline{qcircuit}; all
|
||||||
circuits in this documents use \lstinline{qcircuit}. To visualize the circuits
|
circuits in this documents use \lstinline{qcircuit}. To visualize
|
||||||
built using \lstinline{pyqcs} the function\\
|
\lstinline{pyqcs} circuits the function\\
|
||||||
\lstinline{pyqcs.util.to_diagram.circuit_to_diagram} can be used to generate
|
\lstinline{pyqcs.util.to_diagram.circuit_to_diagram} can be used to generate
|
||||||
\lstinline{qcircuit} code that can be used in \LaTeX documents or exported to
|
\lstinline{qcircuit} code. The diagrams produced by this function are not
|
||||||
PDFs directly. The diagrams produced by this function are not optimized and the
|
optimized, and the diagrams can be unnecessary long. Usually this can be fixed
|
||||||
diagrams can be unnecessary long. Usually this can be fixed easily by editing
|
easily by editing the resulting code manually.
|
||||||
the produced code manually.
|
|
||||||
|
|
||||||
The circuits constructed using the \lstinline{|} operator have a tree structure
|
The circuits constructed using the \lstinline{|} operator have a tree structure
|
||||||
which is rather unconvenient when optimizing circuits or exporting them.
|
which is rather inconvenient when optimizing circuits or exporting them.
|
||||||
The function \\
|
The function \\
|
||||||
\lstinline{pyqcs.util.flatten.flatten} converts a circuit
|
\lstinline{pyqcs.util.flatten.flatten} converts a circuit
|
||||||
to a list of single gate circuits that can be analyzed or exported easily.
|
to a list of single gate circuits that can be simply analyzed or exported.
|
||||||
|
|
||||||
|
|
||||||
\section{Performance}
|
\section{Performance}
|
||||||
\label{ref:performance}
|
\label{ref:performance}
|
||||||
|
|
||||||
To test the performance and compare it to the dense vector simulator the python
|
Testing the performance and comparing the graphical with the dense vector
|
||||||
module is used. Although the pure \lstinline{C} implementation has potential
|
simulator is done with the python module. Although the pure \lstinline{C}
|
||||||
for better performance the python module is better comparable to the dense
|
implementation has potential for better performance the python module is better
|
||||||
vector simulator which is a python module as well.
|
comparable to the dense vector simulator which is a python module as well.
|
||||||
|
|
||||||
For performance tests (and for tests against the dense vector simulator) random
|
For performance tests (and for tests against the dense vector simulator) random
|
||||||
circuits are used. Length $m$ circuits are generated from the probability space
|
circuits are used. Length $m$ circuits are generated from the probability space
|
||||||
|
@ -351,13 +355,10 @@ circuits are used. Length $m$ circuits are generated from the probability space
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\Omega = \left(\{1, ..., 4n\} \otimes \{1, ..., n-1\} \otimes [0, 2\pi)\right)^{\otimes m}
|
\Omega = \left(\{1, ..., 4n\} \otimes \{1, ..., n-1\} \otimes [0, 2\pi)\right)^{\otimes m}
|
||||||
\end{equation}
|
\end{equation}
|
||||||
|
with the uniform distribution. The continuous part $[0, 2\pi)$ is ignored when
|
||||||
with the uniform distribution. The continous part $[0, 2\pi)$ is unused when
|
generating random circuits for the graphical simulator; in order to generate
|
||||||
generating random circuits for the graphical simulator; when generating random
|
random circuits for dense vector simulations this is used as the argument $\phi$ of the
|
||||||
circuits for dense vector simulations this is the argument $\phi$ of the
|
$R_\phi$ gate. For $m=1$ an outcome is mapped to a gate where
|
||||||
$R_\phi$ gate.
|
|
||||||
|
|
||||||
For $m=1$ an outcome is mapped to a gate using
|
|
||||||
|
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\begin{aligned}
|
\begin{aligned}
|
||||||
|
@ -378,7 +379,7 @@ Using this method circuits are generated and applied both to graphical and
|
||||||
dense vector states and the time required to execute the operations
|
dense vector states and the time required to execute the operations
|
||||||
\cite{timeit} is measured. The resulting graph can be seen in
|
\cite{timeit} is measured. The resulting graph can be seen in
|
||||||
Figure \ref{fig:scaling_qbits_linear} and Figure \ref{fig:scaling_qbits_log}.
|
Figure \ref{fig:scaling_qbits_linear} and Figure \ref{fig:scaling_qbits_log}.
|
||||||
Note that in both cases the length of the circuits have been scaled linearely
|
Note that in both cases the length of the circuits have been scaled linearly
|
||||||
with the amount of qbits and the measured time was divided by the number of
|
with the amount of qbits and the measured time was divided by the number of
|
||||||
qbits:
|
qbits:
|
||||||
|
|
||||||
|
@ -403,10 +404,10 @@ qbits:
|
||||||
\label{fig:scaling_qbits_log}
|
\label{fig:scaling_qbits_log}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
The reason for this scaling will be clear later; one can observe that the
|
The reason for this scaling will be clear later. From simulation data one can
|
||||||
performance of the graphical simulator increases in some cases with growing
|
observe that the performance of the graphical simulator increases in some cases
|
||||||
number of qbits when the circuit length is constant. The code used to generate the
|
with growing number of qbits when the circuit length is constant. The code used
|
||||||
data for these plots can be found in \ref{ref:code_benchmarks}.
|
to generate the data for these plots can be found in \ref{ref:code_benchmarks}.
|
||||||
|
|
||||||
As described by \cite{andersbriegel2005} the graphical simulator is exponentially
|
As described by \cite{andersbriegel2005} the graphical simulator is exponentially
|
||||||
faster than the dense vector simulator. According to \cite{andersbriegel2005} it
|
faster than the dense vector simulator. According to \cite{andersbriegel2005} it
|
||||||
|
@ -414,11 +415,12 @@ is considerably faster than a simulator using the straight forward approach simu
|
||||||
the stabilizer tableaux like CHP \cite{CHP} with an average runtime behaviour
|
the stabilizer tableaux like CHP \cite{CHP} with an average runtime behaviour
|
||||||
of $\mathcal{O}\left(n\log(n)\right)$ instead of $\mathcal{O}\left(n^2\right)$.
|
of $\mathcal{O}\left(n\log(n)\right)$ instead of $\mathcal{O}\left(n^2\right)$.
|
||||||
|
|
||||||
One should be aware that the gate execution time (the time required to apply a gate
|
One should be aware that the gate execution time (the time required to apply
|
||||||
to the state) highly depends on the state it is applied to. For the dense vector
|
a gate to the state) highly depends on the state it is applied to. For the
|
||||||
simulator and CHP this is not true: Gate execution time is constant for all gates
|
dense vector simulator and CHP this is not true: Gate execution time is
|
||||||
and states. Because the graphical simulator has to toggle neighbourhoods the
|
constant for all gates and states. Because the graphical simulator has to
|
||||||
gate execution time of the $CZ$ gate varies greatly. The plot Figure \ref{fig:scaling_circuits_linear}
|
toggle neighbourhoods the gate execution time of the $CZ$ gate varies
|
||||||
|
significantly. The plot Figure \ref{fig:scaling_circuits_linear}
|
||||||
shows the circuit execution time for two different numbers of qbits. One can observe three
|
shows the circuit execution time for two different numbers of qbits. One can observe three
|
||||||
regimes:
|
regimes:
|
||||||
|
|
||||||
|
@ -430,11 +432,11 @@ regimes:
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
\begin{description}
|
\begin{description}
|
||||||
\item[Low-Linear Regime] {Here the circuit execution time scales approximately linearely
|
\item[Low-Linear Regime] {\textit{(Ca. $0-10N_q$ gates)} Here the circuit execution time scales approximately linear
|
||||||
with the number of gates in the circuit (i.e. the $CZ$ gate execution time is approximately constant).
|
with the number of gates in the circuit (i.e. the $CZ$ gate execution time is approximately constant).
|
||||||
}
|
}
|
||||||
\item[Intermediate Regime]{The circuit execution time has a nonlinear dependence on the circuit length.}
|
\item[Intermediate Regime]{\textit{(Ca. $10N_q-20N_q$ gates)} The circuit execution time has a nonlinear dependence on the circuit length.}
|
||||||
\item[High-Linear Regime]{This regime shows a linear dependence on the circuit length; the slope is
|
\item[High-Linear Regime]{\textit{(Above ca. $20N_q$ gates)} This regime shows a linear dependence on the circuit length; the slope is
|
||||||
higher than in the low-linear regime.}
|
higher than in the low-linear regime.}
|
||||||
\end{description}
|
\end{description}
|
||||||
|
|
||||||
|
@ -445,6 +447,19 @@ regimes:
|
||||||
\label{fig:scaling_circuits_measurements_linear}
|
\label{fig:scaling_circuits_measurements_linear}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
|
|
||||||
|
These three regimes can be explained when considering the graphical states that
|
||||||
|
typical live in these regimes. With increased circuit length the amount of
|
||||||
|
edges increases which makes toggling neighbourhoods harder. Graphs from the
|
||||||
|
low-linear, intermediate and high-linear regime can be seen in Figure
|
||||||
|
\ref{fig:graph_low_linear_regime}, Figure \ref{fig:graph_intermediate_regime}
|
||||||
|
and Figure \ref{fig:graph_high_linear_regime}. Due to the great amount of edges
|
||||||
|
in the intermediate and high-linear regime the pictures show a window of the
|
||||||
|
actual graph. The full images are in \ref{ref:complete_graphs}. Further the
|
||||||
|
regimes are not clearly visible for $n>30$ qbits therefore choosing smaller graphs is
|
||||||
|
not possible. The code that was used to generate these images can be found
|
||||||
|
in \ref{ref:code_example_graphs}.
|
||||||
|
|
||||||
\begin{figure}
|
\begin{figure}
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=\linewidth]{graphics/graph_low_linear_regime.png}
|
\includegraphics[width=\linewidth]{graphics/graph_low_linear_regime.png}
|
||||||
|
@ -466,35 +481,18 @@ regimes:
|
||||||
\label{fig:graph_high_linear_regime}
|
\label{fig:graph_high_linear_regime}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
These two regimes can be explained when considering the graphical states that
|
|
||||||
typical live in these regimes. With increased circuit length the amount of
|
|
||||||
edges increases which makes toggling neighbourhoods harder. Graphs from the
|
|
||||||
low-linear, intermediate and high-linear regime can be seen in Figure
|
|
||||||
\ref{fig:graph_low_linear_regime}, Figure \ref{fig:graph_intermediate_regime}
|
|
||||||
and Figure \ref{fig:graph_high_linear_regime}. Due to the great amount of edges
|
|
||||||
in the intermediate and high-linear regime the pictures show a window of the
|
|
||||||
actual graph. The full images are in \ref{ref:complete_graphs}. Further the
|
|
||||||
regimes are not clearly visible for $n>30$ qbits so choosing smaller graphs is
|
|
||||||
not possible. The code that was used to generate these images can be found
|
|
||||||
in \ref{ref:code_example_graphs}.
|
|
||||||
|
|
||||||
The Figure \ref{fig:scaling_circuits_measurements_linear} brings more substance
|
The Figure \ref{fig:scaling_circuits_measurements_linear} brings more substance
|
||||||
to this interpretation. In this simulation the Pauli $X$ gate has been replaced
|
to this interpretation. In this simulation the Pauli $X$ gate has been replaced
|
||||||
by the measurement gate $M$, .i.e. in every gate drawn from the probability
|
by the measurement gate $M$, .i.e. in every gate drawn from the probability
|
||||||
space a qbit is measured with probability $\frac{1}{4}$. As described in
|
space a qbit is measured with probability $\frac{1}{4}$. Pauli measurements
|
||||||
\cite{hein_eisert_briegel2008} the Schmidt measure for entropy is bounded from
|
decrease the entanglement (and the amount of edges) in a state
|
||||||
above by Pauli persistency, i.e. the minimal amount of Pauli measurements
|
|
||||||
required to disentangle a state. This Pauli persistency is closely related to
|
|
||||||
the amount (and structure of) vertices in the graph
|
|
||||||
\cite{hein_eisert_briegel2008}. In particular Pauli measurements decrease the
|
|
||||||
entanglement (and the amount of edges) in a state
|
|
||||||
\cite{hein_eisert_briegel2008}\cite{li_chen_fisher2019}. The frequent
|
\cite{hein_eisert_briegel2008}\cite{li_chen_fisher2019}. The frequent
|
||||||
measurements in the simulation therefore keeps the amount of edges low thus
|
measurements in the simulation therefore keeps the amount of edges low thus
|
||||||
preventing a transition from the low linear regime to the intermediate regime.
|
preventing a transition from the low linear regime to the intermediate regime.
|
||||||
|
|
||||||
|
|
||||||
Because states with more qbits reach the intermediate regime at higher circuit
|
Because states with more qbits reach the intermediate regime at higher circuit
|
||||||
lengths it is important to account for this virtual performance boost when
|
lengths it is important to compensate 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.
|
||||||
|
|
||||||
|
@ -502,15 +500,15 @@ in Figure \ref{fig:scaling_qbits_linear} had to be scaled with the qbit number.
|
||||||
|
|
||||||
Although the simulator(s) are in a working state and have been tested there is
|
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
|
still some work that can be done. A noise model helping to teach and analyze
|
||||||
noisy execution is one particularly interesting piece of work. To allow a user
|
noisy execution would be an interesting improvement to implement. In order to
|
||||||
to execute circuits on other machines, including both real hardware and
|
allow a user to execute circuits on other machines, including both real
|
||||||
simulators, a module that exports circuits to OpenQASM \cite{openqasm} seems
|
hardware and simulators, a module that exports circuits to OpenQASM
|
||||||
useful.
|
\cite{openqasm} seems useful.
|
||||||
|
|
||||||
The current implementation of some graphical operations can be optimized. While
|
The current implementation of some graphical operations can be optimized. While
|
||||||
clearing VOPs as described in \ref{ref:dynamics_graph} the neighbourhood of
|
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
|
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
|
forward implementation, but often the $L_a$ transformation is performed several
|
||||||
times on the same vertex. The neighbourhood would have to be toggled either
|
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
|
once or not at all depending on whether the number of $L_a$ transformations is
|
||||||
odd or even.
|
odd or even.
|
||||||
|
|
|
@ -3,7 +3,7 @@
|
||||||
|
|
||||||
Quantum computing has been a rapidly growing field over the last years with
|
Quantum computing has been a rapidly growing field over the last years with
|
||||||
many companies and institutions working on building and using quantum computers
|
many companies and institutions working on building and using quantum computers
|
||||||
\cite{ibmq}\cite{intelqc}\cite{microsoftqc}\cite{dwavesys}\cite{lrzqc}\cite{heise25_18}.
|
\cite{ibmq}\cite{intelqc}\cite{microsoftqc}\cite{dwavesys}.
|
||||||
One important topic in this research is quantum error correction
|
One important topic in this research is quantum error correction
|
||||||
\cite{nielsen_chuang_2010}\cite{gottesman2009}\cite{gottesman1997}\cite{shor1995}
|
\cite{nielsen_chuang_2010}\cite{gottesman2009}\cite{gottesman1997}\cite{shor1995}
|
||||||
that will allow the execution of arbitrarily long quantum circuits \cite{nielsen_chuang_2010}.
|
that will allow the execution of arbitrarily long quantum circuits \cite{nielsen_chuang_2010}.
|
||||||
|
|
|
@ -43,7 +43,7 @@ with
|
||||||
|
|
||||||
Note that $X = HZH$ and $Z = R_{\pi}$, so the set of $H, R_\phi$ is sufficient.
|
Note that $X = HZH$ and $Z = R_{\pi}$, so the set of $H, R_\phi$ is sufficient.
|
||||||
Further note that the basis vectors are chosen s.t. $Z\ket{0} = +\ket{0}$ and $Z\ket{1} = -\ket{1}$;
|
Further note that the basis vectors are chosen s.t. $Z\ket{0} = +\ket{0}$ and $Z\ket{1} = -\ket{1}$;
|
||||||
transforming to the other Pauli eigenstates is done using $H$ and $SH$
|
transforming to the other Pauli eigenstates is done using $H$ and $S$
|
||||||
|
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
S := R_{\frac{\pi}{2}} = \left(\begin{array}{cc} 1 & 0 \\ 0 & i\end{array}\right)
|
S := R_{\frac{\pi}{2}} = \left(\begin{array}{cc} 1 & 0 \\ 0 & i\end{array}\right)
|
||||||
|
@ -148,10 +148,10 @@ For a single-qbit gate $U$ and a qbit $j = 0, 1, ..., n - 1$
|
||||||
|
|
||||||
In particular for $X, Z$
|
In particular for $X, Z$
|
||||||
\begin{equation}\label{eq:CX_pr}
|
\begin{equation}\label{eq:CX_pr}
|
||||||
CX(i, j) = \ket{0}\bra{0}_j\otimes I_i + \ket{1}\bra{1}_j \otimes X_i
|
CX_{i, j} = \ket{0}\bra{0}_j\otimes I_i + \ket{1}\bra{1}_j \otimes X_i
|
||||||
\end{equation}
|
\end{equation}
|
||||||
\begin{equation}\label{eq:CZ_pr}
|
\begin{equation}\label{eq:CZ_pr}
|
||||||
CZ(i, j) = \ket{0}\bra{0}_j\otimes I_i + \ket{1}\bra{1}_j \otimes Z_i .
|
CZ_{i, j} = \ket{0}\bra{0}_j\otimes I_i + \ket{1}\bra{1}_j \otimes Z_i .
|
||||||
\end{equation}
|
\end{equation}
|
||||||
|
|
||||||
This follows the definition given in \cite{barenco_ea_1995}.
|
This follows the definition given in \cite{barenco_ea_1995}.
|
||||||
|
@ -283,7 +283,8 @@ Where $T\ket{\varphi} = \exp(2\pi i\varphi) \ket{\varphi}$ and the measurement
|
||||||
result $\tilde{\varphi} = \frac{x}{2^n}$ is an estimation for $\varphi$. If
|
result $\tilde{\varphi} = \frac{x}{2^n}$ is an estimation for $\varphi$. If
|
||||||
a success rate of $1-\epsilon$ and an accuracy of $| \varphi - \tilde{\varphi}
|
a success rate of $1-\epsilon$ and an accuracy of $| \varphi - \tilde{\varphi}
|
||||||
| < 2^{-m}$ is wanted, then $N = m + \log_2(2 + \frac{1}{2\epsilon})$ qbits are
|
| < 2^{-m}$ is wanted, then $N = m + \log_2(2 + \frac{1}{2\epsilon})$ qbits are
|
||||||
required \cite{nielsen_chuang_2010}\cite{lehner2019}.
|
required \cite{nielsen_chuang_2010}.
|
||||||
|
The gate $FT^\dagger$ is the inverse quantum fourier transform as described in \cite{nielsen_chuang_2010}.
|
||||||
|
|
||||||
%Another possible way to use quantum computers in physics is to simulate a system's
|
%Another possible way to use quantum computers in physics is to simulate a system's
|
||||||
%time evolution using the transfer matrix. By mapping an interesting system to
|
%time evolution using the transfer matrix. By mapping an interesting system to
|
||||||
|
|
|
@ -98,7 +98,7 @@ group.
|
||||||
$g_i$ and $m$ is the smallest integer for which these statements hold.
|
$g_i$ and $m$ is the smallest integer for which these statements hold.
|
||||||
\end{definition}
|
\end{definition}
|
||||||
|
|
||||||
From now on the generators $\langle S^{(i)} \rangle_{i=0, ..., n-1}$ will be
|
From now on the generators $\langle S^{(i)} \rangle_{i}$ will be
|
||||||
used as the required properties of a set of stabilizers that can be studied on
|
used as the required properties of a set of stabilizers that can be studied on
|
||||||
its generators.
|
its generators.
|
||||||
|
|
||||||
|
@ -552,14 +552,14 @@ Therefore the associated graph is changed as given in the third equation.
|
||||||
\label{ref:sec_g_states}
|
\label{ref:sec_g_states}
|
||||||
|
|
||||||
The definition of a VOP-free graph state above raises an obvious question: Can
|
The definition of a VOP-free graph state above raises an obvious question: Can
|
||||||
any stabilizer state be described using just a graph? The answer is straight
|
any stabilizer state be described using just a graph? The answer is no. The
|
||||||
forward: No. The most simple cases are the single qbit states $\ket{0},\ket{1}$
|
most simple cases are the single qbit states $\ket{0},\ket{1}$ and $\ket{+_Y},
|
||||||
and $\ket{+_Y}, \ket{-_Y}$. But there is an extension to the VOP-free graph
|
\ket{-_Y}$. But there is an extension to the VOP-free graph states that allows
|
||||||
states that allows the representation of an arbitrary stabilizer state. The
|
the representation of an arbitrary stabilizer state. The proof that any
|
||||||
proof that indeed any state can be represented is purely constructive. As seen
|
state can be represented is purely constructive. As seen in Theorem
|
||||||
in Theorem \ref{thm:clifford_group_approx} any $c \in C_n$ can be constructed
|
\ref{thm:clifford_group_approx} any $c \in C_n$ can be constructed from $CZ$
|
||||||
from $CZ$ and $C_L$. In the following discussion it will become clear that both
|
and $C_L$. In the following discussion it will become clear that both $C_L$ and
|
||||||
$C_L$ and $CZ$ can be applied to a general graph state
|
$CZ$ can be applied to a general graph state
|
||||||
\footnote{
|
\footnote{
|
||||||
One can show that any stabilizer state is local Clifford equivalent to
|
One can show that any stabilizer state is local Clifford equivalent to
|
||||||
a VOP-free graph state, i.e. only tensor products of $C_L$ matrices are
|
a VOP-free graph state, i.e. only tensor products of $C_L$ matrices are
|
||||||
|
@ -586,9 +586,9 @@ $C_L$ and $CZ$ can be applied to a general graph state
|
||||||
The notation in \cite{andersbriegel2005} is different. Instead of using $(V, E, O)$
|
The notation in \cite{andersbriegel2005} is different. Instead of using $(V, E, O)$
|
||||||
to represent any stabilizer $(V, E)$ is used to represent what is called a VOP-free
|
to represent any stabilizer $(V, E)$ is used to represent what is called a VOP-free
|
||||||
graph state in this paper. Then the state $\ket{\bar{G}}$ is extended with local Clifford
|
graph state in this paper. Then the state $\ket{\bar{G}}$ is extended with local Clifford
|
||||||
gates $c_1, ..., c_n$ to an arbitrary stabilizer state. The state is then denoted as
|
gates $c_1, ..., c_n$ to an arbitrary stabilizer state. The full state is denoted as
|
||||||
$\ket{\bar{G}; (c_1, ..., c_n)} \equiv \ket{\bar{G}; \vec{c}}$. This paper prefers
|
$\ket{\bar{G}; (c_1, ..., c_n)} \equiv \ket{\bar{G}; \vec{c}}$. This paper prefers
|
||||||
the notation using $(V, E, O)$ as it both emphasizes the use of stabilizers and is closer
|
the notation $(V, E, O)$ as it both emphasizes the use of stabilizers and is closer
|
||||||
to the representation used in the simulator.
|
to the representation used in the simulator.
|
||||||
}.
|
}.
|
||||||
\end{definition}
|
\end{definition}
|
||||||
|
@ -603,11 +603,12 @@ immediately:
|
||||||
The great advantage of this representation of a stabilizer state is its space
|
The great advantage of this representation of a stabilizer state is its space
|
||||||
requirement: Instead of storing $n^2$ Pauli matrices only some vertices (which
|
requirement: Instead of storing $n^2$ Pauli matrices only some vertices (which
|
||||||
often are implicit), the edges and some vertex operators ($n$ matrices) have to
|
often are implicit), the edges and some vertex operators ($n$ matrices) have to
|
||||||
be stored. The following theorem will improve this even further: instead of $n$
|
be stored. Theorem \ref{thm:cl24} will improve this even further: Instead of $n$
|
||||||
matrices it is sufficient to store $n$ integers representing the vertex
|
matrices it is sufficient to store $n$ integers representing the vertex
|
||||||
operators:
|
operators.
|
||||||
|
|
||||||
\begin{theorem}
|
\begin{theorem}
|
||||||
|
\label{thm:cl24}
|
||||||
$C_L$ has $24$ degrees of freedom disregarding a global phase \cite{andersbriegel2005}.
|
$C_L$ has $24$ degrees of freedom disregarding a global phase \cite{andersbriegel2005}.
|
||||||
\end{theorem}
|
\end{theorem}
|
||||||
\begin{proof} It is clear that $\forall a \in C_L$ a is a group isomorphism $P
|
\begin{proof} It is clear that $\forall a \in C_L$ a is a group isomorphism $P
|
||||||
|
@ -643,9 +644,9 @@ operation on graph states \cite{andersbriegel2005}.
|
||||||
|
|
||||||
So far the graphical representation of stabilizer states is just another way to
|
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
|
store basically a stabilizer tableaux that might require less memory than the
|
||||||
tableaux used in CHP \cite{CHP}. The true power of this formalism is seen when
|
tableaux used in CHP \cite{CHP}. The power of this formalism can be seen by
|
||||||
studying its dynamics. The simplest case is a local Clifford operator $c_j$
|
studying its dynamics. The simplest case is a local Clifford operator $c_j$
|
||||||
acting on a qbit $j$: The stabilizers are changed to $\langle c_j S^{(i)}
|
acting on a qbit $j$ changing the stabilizers to $\langle c_j S^{(i)}
|
||||||
c_j^\dagger\rangle_i$. Using the definition of the graphical representation one
|
c_j^\dagger\rangle_i$. Using the definition of the graphical representation one
|
||||||
sees that just the vertex operators are changed and the new vertex operators
|
sees that just the vertex operators are changed and the new vertex operators
|
||||||
are given by
|
are given by
|
||||||
|
@ -658,9 +659,9 @@ are given by
|
||||||
\end{equation}
|
\end{equation}
|
||||||
|
|
||||||
The action of a $CZ$ gate on the state $(V, E, O)$ is in most cases less
|
The action of a $CZ$ gate on the state $(V, E, O)$ is in most cases less
|
||||||
trivial. Let $a \neq b$ be two qbits, now consider the action of $CZ_{a,b}$ on
|
trivial. Let $a \neq b$ be two qbits. Consider the action of $CZ_{a,b}$ on
|
||||||
$(V, E, O)$. The cases given here follow the implementation of a $CZ$
|
$(V, E, O)$. The cases given here follow the implementation of a $CZ$
|
||||||
application in \cite{pyqcs}, the respective paragraphs from
|
application in \cite{pyqcs}. The respective paragraphs from
|
||||||
\cite{andersbriegel2005} are given in italic. Most of the discussion follows
|
\cite{andersbriegel2005} are given in italic. Most of the discussion follows
|
||||||
the one given in \cite{andersbriegel2005} closely.
|
the one given in \cite{andersbriegel2005} closely.
|
||||||
|
|
||||||
|
@ -681,7 +682,7 @@ options with and without an edge between the qbits and $24$ Clifford operators
|
||||||
on each vertex.
|
on each vertex.
|
||||||
|
|
||||||
All those states and the resulting state after a $CZ$ application can be
|
All those states and the resulting state after a $CZ$ application can be
|
||||||
computed which leads to another interesting result that will be useful later:
|
computed which leads to another interesting insight that will be useful later:
|
||||||
If one vertex has the vertex operator $I$ the resulting state can be chosen
|
If one vertex has the vertex operator $I$ the resulting state can be chosen
|
||||||
such that at least one of the vertex operators is $I$ again and in particular
|
such that at least one of the vertex operators is $I$ again and in particular
|
||||||
the identity on the vertex can be preserved under the application of a $CZ$.
|
the identity on the vertex can be preserved under the application of a $CZ$.
|
||||||
|
@ -692,7 +693,7 @@ has non-operand (i.e. neighbours that are neither $a$ nor $b$) neighbours. In
|
||||||
this case one can try to clear the vertex operators which will succeed for at
|
this case one can try to clear the vertex operators which will succeed for at
|
||||||
least one qbit.
|
least one qbit.
|
||||||
|
|
||||||
The transformation given in Lemma \ref{lemma:M_a} is used to "clear" the vertex
|
The transformation given in Lemma \ref{lemma:M_a} is used to clear the vertex
|
||||||
operators. Recalling that the transformation $M_j$ toggles the neighbourhood of
|
operators. Recalling that the transformation $M_j$ toggles the neighbourhood of
|
||||||
vertex $j$ gives substance to the following theorem:
|
vertex $j$ gives substance to the following theorem:
|
||||||
|
|
||||||
|
@ -729,7 +730,7 @@ steps:
|
||||||
}
|
}
|
||||||
\end{enumerate}
|
\end{enumerate}
|
||||||
|
|
||||||
This algorithm has the important properties that if the algorithm succeeds $o_a
|
This algorithm has the important properties that if it succeeds $o_a
|
||||||
= I$ and $o_b$ has picked up powers of $\sqrt{iZ}^\dagger$. If $b$ has
|
= I$ and $o_b$ has picked up powers of $\sqrt{iZ}^\dagger$. If $b$ has
|
||||||
non-operand neighbours after clearing the vertex operators on $a$, then the
|
non-operand neighbours after clearing the vertex operators on $a$, then the
|
||||||
vertex operators on $b$ can be cleared using the same algorithm which gives
|
vertex operators on $b$ can be cleared using the same algorithm which gives
|
||||||
|
@ -755,23 +756,24 @@ non-operand neighbours and $b$ does not. Now the state $\ket{G}$ has the form
|
||||||
\end{equation}
|
\end{equation}
|
||||||
|
|
||||||
As $o_b$ commutes with all operators but $CZ_{a,b}$ and $s \in \{0, 1\}$
|
As $o_b$ commutes with all operators but $CZ_{a,b}$ and $s \in \{0, 1\}$
|
||||||
indicates whether there is an edge between $a$ and $b$.
|
indicates whether there is an edge between $a$ and $b$. Applying the $CZ$
|
||||||
|
gives
|
||||||
|
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\begin{aligned}
|
\begin{aligned}
|
||||||
CZ_{a,b}\ket{G} &= CZ_{a,b}\left(\prod\limits_{o_i \in O \setminus \{o_b\}} o_i \right) \left(\prod\limits_{\{i,j\} \in E \setminus \{a,b\}} CZ_{i,j}\right) o_b (CZ_{a,b})^s \ket{+} \\
|
CZ_{a,b}\ket{G} &= CZ_{a,b}\left(\prod\limits_{o_i \in O \setminus \{o_b\}} o_i \right) \left(\prod\limits_{\{i,j\} \in E \setminus \{a,b\}} CZ_{i,j}\right) o_b (CZ_{a,b})^s \ket{+} \\
|
||||||
&= \left(\prod\limits_{o_i \in O \setminus \{o_b\}} o_i \right) \left(\prod\limits_{\{i,j\} \in E \setminus \{a,b\}} CZ_{i,j}\right) \ket{+}_{n-2} \otimes \left(CZ_{a,b} o_b (CZ_{a,b})^s \ket{+}_2\right) \\
|
&= \left(\prod\limits_{o_i \in O \setminus \{o_b\}} o_i \right) \left(\prod\limits_{\{i,j\} \in E \setminus \{a,b\}} CZ_{i,j}\right) \ket{+}_{n-2} \otimes \left(CZ_{a,b} o_b (CZ_{a,b})^s \ket{+}_2\right). \\
|
||||||
\end{aligned}
|
\end{aligned}
|
||||||
\end{equation}
|
\end{equation}
|
||||||
|
|
||||||
This allows to re-use the method in Case 2 to apply the $CZ$ while keeping the
|
This allows to reuse the method in Case 2 to apply the $CZ$ while keeping the
|
||||||
$o_a = I$.
|
$o_a = I$.
|
||||||
|
|
||||||
As it has been shown how both $CZ$ and $C_L$ act on a graph state $\ket{G}$
|
As it has been shown how both $CZ$ and $C_L$ act on a graph state $\ket{G}$
|
||||||
and the resulting state is a graph state as well this proofs constructively
|
and the resulting state is a graph state as well this proofs constructively
|
||||||
that the graphical representation of a stabilizer state is indeed able to
|
that the graphical representation of a stabilizer state is able to represent
|
||||||
represent any stabilizer state. If one wants to do computations using this
|
any stabilizer state. If one wants to do computations using this formalism it
|
||||||
formalism it is however also necessary to perform measurements.
|
is also necessary to perform measurements.
|
||||||
|
|
||||||
\subsection{Measurements on Graph States}
|
\subsection{Measurements on Graph States}
|
||||||
\label{ref:meas_graph}
|
\label{ref:meas_graph}
|
||||||
|
@ -781,7 +783,7 @@ the graph after a measurement is described in \cite{hein_eisert_briegel2008}.
|
||||||
|
|
||||||
Recalling \ref{ref:meas_stab} it is clear that one has to compute the
|
Recalling \ref{ref:meas_stab} it is clear that one has to compute the
|
||||||
commutator of the observable $g_a = Z_a$ with the stabilizers to get the
|
commutator of the observable $g_a = Z_a$ with the stabilizers to get the
|
||||||
probability amplitudes which is a quite expensive computation in theory. It is
|
probability amplitudes which is a expensive computation in theory. It is
|
||||||
possible to simplify the problem by pulling the observable behind the vertex
|
possible to simplify the problem by pulling the observable behind the vertex
|
||||||
operators. For this consider the projector $P_{a,s} = \frac{I + (-1)^sZ_a}{2}$
|
operators. For this consider the projector $P_{a,s} = \frac{I + (-1)^sZ_a}{2}$
|
||||||
|
|
||||||
|
@ -807,11 +809,11 @@ projector as $o_a$ is a Clifford operator
|
||||||
\end{aligned}
|
\end{aligned}
|
||||||
\end{equation}
|
\end{equation}
|
||||||
|
|
||||||
Where $\tilde{g}_a \in \{\pm X_a, \pm Y_a, \pm Z_a\}$. Therefore, it is
|
Where $\tilde{g}_a \in \{\pm X_a, \pm Y_a, \pm Z_a\}$. Therefore, it is enough
|
||||||
enough to study the measurements of any Pauli operator on the vertex operator
|
to study the measurements of any Pauli operator on the VOP-free graph states.
|
||||||
free graph states. The commutators of the observable with the $K_G^{(i)}$ are
|
The commutators of the observable with the $K_G^{(i)}$ are easy to compute.
|
||||||
quite easy to compute. Note that Pauli matrices either commute or anticommute
|
Note that Pauli matrices either commute or anticommute and it is simpler to
|
||||||
and it is easier to list the operators that anticommute:
|
list the operators that anticommute:
|
||||||
|
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\begin{aligned}
|
\begin{aligned}
|
||||||
|
@ -826,25 +828,26 @@ $\tilde{g}_a = X_a (-X_a)$ is measured the result $s=0(1)$ is obtained with
|
||||||
probability $1$ and $(V, E, O)$ is unchanged. In any other case the results
|
probability $1$ and $(V, E, O)$ is unchanged. In any other case the results
|
||||||
$s=1$ and $s=0$ have probability $\frac{1}{2}$ and both graph and vertex
|
$s=1$ and $s=0$ have probability $\frac{1}{2}$ and both graph and vertex
|
||||||
operators have to be updated. Further it is clear that measurements of
|
operators have to be updated. Further it is clear that measurements of
|
||||||
$-\tilde{g}_a$ and $\tilde{g}_a$ are related by just inverting the result $s$.
|
$-\tilde{g}_a$ and $\tilde{g}_a$ are related by inverting the result $s$.
|
||||||
|
|
||||||
The calculations to obtain the transformation on graph and vertex operators are
|
The calculations to obtain the transformation on graph and vertex operators are
|
||||||
lengthy and follow the scheme of Lemma \ref{lemma:M_a}. \cite[Section
|
lengthy and follow the scheme of Lemma \ref{lemma:M_a}. \cite[Section
|
||||||
IV]{hein_eisert_briegel2008} also contains the steps required to obtain the
|
IV]{hein_eisert_briegel2008} also contains the steps required to obtain the
|
||||||
following results
|
following results:
|
||||||
|
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\begin{aligned}
|
\begin{aligned}
|
||||||
U_{Z,s} &= \left(\prod\limits_{b \in n_a} Z_b^s\right) X_a^s H_a \\
|
U_{Z,s} &= \left(\prod\limits_{b \in n_a} Z_b^s\right) X_a^s H_a \\
|
||||||
U_{Y,s} &= \prod\limits_{b \in n_a} \sqrt{(-1)^{1-s} iZ_b} \sqrt{(-1)^{1-s} iZ_a}.\\
|
U_{Y,s} &= \prod\limits_{b \in n_a} \sqrt{(-1)^{1-s} iZ_b} \sqrt{(-1)^{1-s} iZ_a}\\
|
||||||
\end{aligned}
|
\end{aligned}
|
||||||
\end{equation}
|
\end{equation}
|
||||||
|
|
||||||
These transformations split it two parts: the first is a result of Lemma
|
These transformations split it in two parts: the first is a result of Lemma
|
||||||
\ref{lemma:stab_measurement}. The second part makes sure that the qbit $a$ is
|
\ref{lemma:stab_measurement}. The second part makes sure that the qbit $a$ is
|
||||||
diagonal in measured observable and has the correct eigenvalue. When comparing
|
diagonal in the measured observable and has the correct eigenvalue. When comparing
|
||||||
with Lemma \ref{lemma:stab_measurement} in both cases $Y,Z$ the anticommuting
|
with Lemma \ref{lemma:stab_measurement} in both cases $Y$ and $Z$ the anticommuting
|
||||||
stabilizer $K_G^{(a)}$ is chosen. The graph is changed according to
|
stabilizer $K_G^{(a)}$ is chosen. The graph is changed according to
|
||||||
|
\footnote{$n_a \otimes n_a$ should be read as $\{\{i,j\} | i,j \in n_a, i \neq j\}$.}
|
||||||
|
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\begin{aligned}
|
\begin{aligned}
|
||||||
|
@ -854,7 +857,7 @@ stabilizer $K_G^{(a)}$ is chosen. The graph is changed according to
|
||||||
\end{equation}
|
\end{equation}
|
||||||
|
|
||||||
|
|
||||||
For $g_a = X_a$ one has to choose a $b \in n_a$ and the transformations are
|
For $g_a = X_a$ one has to choose a neighbour $b \in n_a$ and the transformations are
|
||||||
|
|
||||||
\begin{equation}
|
\begin{equation}
|
||||||
\begin{aligned}
|
\begin{aligned}
|
||||||
|
|
|
@ -190,11 +190,13 @@
|
||||||
urldate={19.09.2019},
|
urldate={19.09.2019},
|
||||||
title={IBM Q - What is quantum computing?},
|
title={IBM Q - What is quantum computing?},
|
||||||
author={IBM},
|
author={IBM},
|
||||||
|
note={https://www.ibm.com/quantum-computing/learn/what-is-quantum-computing/},
|
||||||
year=2019
|
year=2019
|
||||||
}
|
}
|
||||||
@online{
|
@online{
|
||||||
intelqc,
|
intelqc,
|
||||||
url={https://newsroom.intel.com/press-kits/quantum-computing/\#gs.2s0dux},
|
url={https://newsroom.intel.com/press-kits/quantum-computing/\#gs.2s0dux},
|
||||||
|
note={https://newsroom.intel.com/press-kits/quantum-computing/\#gs.2s0dux},
|
||||||
urldate={19.09.2019},
|
urldate={19.09.2019},
|
||||||
title={Intel Press Kit: Quantum Computing},
|
title={Intel Press Kit: Quantum Computing},
|
||||||
author={Intel},
|
author={Intel},
|
||||||
|
@ -203,6 +205,7 @@
|
||||||
@online{
|
@online{
|
||||||
microsoftqc,
|
microsoftqc,
|
||||||
url={https://www.microsoft.com/en-us/quantum/default.aspx},
|
url={https://www.microsoft.com/en-us/quantum/default.aspx},
|
||||||
|
note={https://www.microsoft.com/en-us/quantum/default.aspx},
|
||||||
urldate={19.09.2019},
|
urldate={19.09.2019},
|
||||||
title={Quantum Computing | Microsoft},
|
title={Quantum Computing | Microsoft},
|
||||||
author={Microsoft},
|
author={Microsoft},
|
||||||
|
@ -211,6 +214,7 @@
|
||||||
@online{
|
@online{
|
||||||
dwavesys,
|
dwavesys,
|
||||||
url={https://www.dwavesys.com/quantum-computing},
|
url={https://www.dwavesys.com/quantum-computing},
|
||||||
|
note={https://www.dwavesys.com/quantum-computing},
|
||||||
urldate={19.09.2019},
|
urldate={19.09.2019},
|
||||||
title={Quantum Computing | D-Wave Systems},
|
title={Quantum Computing | D-Wave Systems},
|
||||||
author={D-Wave Systems Inc}
|
author={D-Wave Systems Inc}
|
||||||
|
@ -218,6 +222,7 @@
|
||||||
@online{
|
@online{
|
||||||
lrzqc,
|
lrzqc,
|
||||||
url={https://www.lrz.de/wir/newsletter/2019-08/\#LRZ_bereit_fuer_bayerische_Quantechnologie},
|
url={https://www.lrz.de/wir/newsletter/2019-08/\#LRZ_bereit_fuer_bayerische_Quantechnologie},
|
||||||
|
note={https://www.lrz.de/wir/newsletter/2019-08/\#LRZ_bereit_fuer_bayerische_Quantechnologie},
|
||||||
urldate={19.09.2019},
|
urldate={19.09.2019},
|
||||||
title={LRZ-Newsletter Nr. 08/2019 vom 01.08.2019},
|
title={LRZ-Newsletter Nr. 08/2019 vom 01.08.2019},
|
||||||
author={S. Vieser},
|
author={S. Vieser},
|
||||||
|
@ -226,6 +231,7 @@
|
||||||
@online{
|
@online{
|
||||||
heise25_18,
|
heise25_18,
|
||||||
url={https://www.heise.de/select/ct/2018/25/1544250249368810},
|
url={https://www.heise.de/select/ct/2018/25/1544250249368810},
|
||||||
|
note={https://www.heise.de/select/ct/2018/25/1544250249368810},
|
||||||
urldate={19.09.2019},
|
urldate={19.09.2019},
|
||||||
title={Europa entfesselt Quanten-Power},
|
title={Europa entfesselt Quanten-Power},
|
||||||
author={Arne Grävemeyer},
|
author={Arne Grävemeyer},
|
||||||
|
@ -287,3 +293,10 @@
|
||||||
title={The Computer Language Benchmarks Game},
|
title={The Computer Language Benchmarks Game},
|
||||||
note={https://benchmarksgame-team.pages.debian.net/benchmarksgame/}
|
note={https://benchmarksgame-team.pages.debian.net/benchmarksgame/}
|
||||||
}
|
}
|
||||||
|
@article{
|
||||||
|
bouchet1991,
|
||||||
|
author={Andrk Bouchet},
|
||||||
|
title={Recognizing locally equivalent graphs},
|
||||||
|
year=1991,
|
||||||
|
note={https://pdf.sciencedirectassets.com/271536/1-s2.0-S0012365X00X02166/1-s2.0-0012365X9390357Y/main.pdf}
|
||||||
|
}
|
||||||
|
|
|
@ -90,11 +90,12 @@ Supervised by Prof. Dr. Christoph Lehner}
|
||||||
|
|
||||||
\newpage
|
\newpage
|
||||||
\textbf{Erklärung zur Anfertigung:}\\
|
\textbf{Erklärung zur Anfertigung:}\\
|
||||||
Ich habe die Arbeit selbständig verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel be-
|
Ich habe die Arbeit selbständig verfasst, keine anderen als die angegebenen
|
||||||
nutzt und bisher keiner anderen Prüfungsbehörde vorgelegt. Außerdem bestätige ich hiermit, dass die
|
Quellen und Hilfsmittel benutzt und bisher keiner anderen Prüfungsbehörde
|
||||||
vorgelegten Druckexemplare und die vorgelegte elektronische Version der Arbeit identisch sind, dass ich
|
vorgelegt. Außerdem bestätige ich hiermit, dass die vorgelegten Druckexemplare
|
||||||
über wissenschaftlich korrektes Arbeiten und Zitieren aufgeklärt wurde und dass ich von den in § 24 Abs.
|
und die vorgelegte elektronische Version der Arbeit identisch sind, dass ich
|
||||||
5 vorgesehenen Rechtsfolgen Kenntnis habe.
|
über wissenschaftlich korrektes Arbeiten und Zitieren aufgeklärt wurde und dass
|
||||||
|
ich von den in § 24 Abs. 5 vorgesehenen Rechtsfolgen Kenntnis habe.
|
||||||
\\
|
\\
|
||||||
\\
|
\\
|
||||||
Unterschrift:
|
Unterschrift:
|
||||||
|
|
Loading…
Reference in New Issue
Block a user