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}
|
||||
\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
|
||||
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
|
||||
minimal result is used as the noise must be positive}
|
||||
\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
|
||||
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}.
|
||||
|
||||
\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]
|
||||
\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}
|
||||
\label{ref:code_example_graphs}
|
||||
|
||||
This code has been used to generate the example graphs used in
|
||||
\ref{ref:performance}. Note that generating the graph is done using a random
|
||||
circuit as used in \ref{ref:code_benchmarks}. The generated \lstinline{dot}
|
||||
This code has been used to generate the example graphs in \ref{ref:performance}
|
||||
and \ref{ref:complete_graphs}. Note that generating the graph is done with
|
||||
a random circuit as in \ref{ref:code_benchmarks}. The generated \lstinline{dot}
|
||||
code is converted to an image using
|
||||
\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}
|
||||
\label{ref:benchmark_ufunc_py}
|
||||
|
||||
It has been mentioned several times that the implementation using
|
||||
\lstinline{ufuncs} as gates is faster than using a \lstinline{python}
|
||||
implementation. To support this statement a simple benchmark can be used. The
|
||||
relatively simple Pauli $X$ is used, more complicated gates like $CX$ or $H$
|
||||
have worse performance when implemented in \lstinline{python}. The performance
|
||||
improvement when using the \lstinline{ufunc} is a factor around $6.4$ in this tested
|
||||
case. One must however note that the tested \lstinline{python} code is not
|
||||
realistic and in a possible applications there would be a significant overhead.
|
||||
It has been mentioned several times that the implementation with
|
||||
\lstinline{ufuncs} as gates is faster than a pure \lstinline{python}
|
||||
implementation. To support this statement a simple benchmark is written. The
|
||||
relatively simple Pauli $X$ gate us implemented, more complicated gates like $CX$ or $H$
|
||||
have worse performance when written in \lstinline{python}. The performance
|
||||
improvement when in this example is a factor around $6.4$.
|
||||
One must note that the tested \lstinline{python} code is not
|
||||
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}
|
||||
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
\chapter{Conclusion and Outlook}
|
||||
|
||||
As seen in \ref{ref:performance} simulation using stabilizers is exponentially
|
||||
faster than simulating using state vectors. Using a graphical representation
|
||||
for the stabilizers is on average more efficiently than using a stabilizer
|
||||
faster than simulating with dense state vectors. The graphical representation
|
||||
for stabilizer states is on average more efficiently than the stabilizer
|
||||
tableaux. In particular one can simulate more qbits while only applying
|
||||
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
|
||||
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
|
||||
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
|
||||
|
|
@ -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$.
|
||||
|
||||
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
|
||||
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
|
||||
|
|
@ -34,14 +34,14 @@ ground state of this Hamiltonian.
|
|||
|
||||
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
|
||||
$\frac{\pi}{2}$?}\\ The answer to this question is hidden in the Clifford
|
||||
group. Recalling Definition \ref{def:clifford_group} the Clifford group is not
|
||||
defined to be generated by $H, S, CZ$ but by its property of normalizing the
|
||||
multilocal Pauli group. Storing and manipulating the multilocal Pauli group is
|
||||
only so efficient (or possible) because it is the tensor product of Pauli
|
||||
matrices. A general unitary on $n$ qbits would be a $2^{n} \times 2^{n}$ matrix
|
||||
which requires more space than a dense state vector. The Clifford group is
|
||||
a group preserving this tensor product property.
|
||||
$\frac{\pi}{2}$?}\\ The answer to this question can be found by taking a look
|
||||
at the Clifford group. Recalling Definition \ref{def:clifford_group} the
|
||||
Clifford group is not defined to be generated by $H, S, CZ$, but by its property
|
||||
of normalizing the multilocal Pauli group. Storing and manipulating the
|
||||
multilocal Pauli group is only so efficient (or possible) because it is the
|
||||
tensor product of Pauli matrices. A general unitary on $n$ qbits would be
|
||||
a $2^{n} \times 2^{n}$ matrix which requires more space than a dense state
|
||||
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
|
||||
|
|
@ -103,10 +103,10 @@ a group preserving this tensor product property.
|
|||
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
|
||||
\cite{bermejovega_lin_vdnest2015}\cite{bermejovega_vdnest2018}\cite{vandennest2019}\cite{vandennest2018}.
|
||||
This allows to simulate more classes of circuits efficiently on classical computers
|
||||
including the Quantum Fourier Transforms which is often believed to be
|
||||
responsible for exponential speedups. One must note that in the definition of
|
||||
the QFTs as in \cite{vandennest2018} the QFT depends on the Abelian group it
|
||||
This allows to simulate more classes of circuits efficiently on classical
|
||||
computers including the Quantum Fourier Transforms which is often believed to
|
||||
be responsible for exponential speedups. One must note that in the definition
|
||||
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
|
||||
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
|
||||
|
|
@ -117,6 +117,6 @@ the Clifford group \cite{vandennest2018}.
|
|||
|
||||
The exponential speedup of quantum computing is often attributed to
|
||||
entanglement, superposition and interference effects
|
||||
\cite{uwaterloo}\cite{21732}\cite{vandennest2018}. Stabilizer states
|
||||
however show both entanglement, superposition and interference effects;
|
||||
as do computations done using general normalizers \cite{vandennest2018}.
|
||||
\cite{uwaterloo}\cite{21732}\cite{vandennest2018}. Stabilizer states show
|
||||
entanglement, superposition and interference effects; as do computations using
|
||||
general normalizers \cite{vandennest2018}.
|
||||
|
|
|
|||
|
|
@ -2,13 +2,13 @@
|
|||
\chapter{Implementation}
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
amplitudes. Full access to the state (including intermediate states) has been
|
||||
priorized over execution speed. To keep the simulation speed as high as
|
||||
amplitudes. Full access to the states (including intermediate states) has been
|
||||
prioritized over execution speed. To keep the simulation speed as high as
|
||||
possible under these constraints some parts are implemented in \lstinline{C}.
|
||||
|
||||
\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{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.}
|
||||
\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}
|
||||
|
||||
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.
|
||||
|
||||
While implementing the dense state vectors two key points were allowing
|
||||
a simple and readable way to use them and simple access to the states by users
|
||||
that want more information than an abstracted view could allow. To meet both
|
||||
requirements the states are implemented as Python objects providing abstract
|
||||
features such as normalization checking, checking for sufficient qbit number
|
||||
when applying a circuit, computing overlaps with other states, a stringify
|
||||
method and stored measurement results. To store the measurement results
|
||||
a NumPy \lstinline{int8} array \cite{numpy_array} is used; this is called the
|
||||
classical state. The Python states also have a NumPy \lstinline{cdouble} array
|
||||
that stores the quantum mechanical state. Using NumPy arrays has the advantage
|
||||
that access to the data is simple and safe while operations on the states can
|
||||
be implemented in \lstinline{C} \cite{numpy_ufunc} providing a considerable
|
||||
speedup \ref{ref:benchmark_ufunc_py}.
|
||||
While implementing the dense state vectors two key points were a simple way to
|
||||
use them and easy access to the underlaying data. To meet both requirements
|
||||
the states are implemented as Python objects that provide abstract features such
|
||||
as normalization checking, checking for sufficient qbit number when applying
|
||||
a circuit, computing overlaps with other states, a stringify method and stored
|
||||
measurement results. To store the measurement results a NumPy \lstinline{int8}
|
||||
array \cite{numpy_array} is used; this is called the classical state. The
|
||||
Python states also have a NumPy \lstinline{cdouble} array that stores the
|
||||
quantum mechanical state. Using NumPy arrays has the advantage that access to
|
||||
the data is simple and safe while operations on the states can be implemented
|
||||
in \lstinline{C} \cite{numpy_ufunc} providing a considerable speedup
|
||||
\ref{ref:benchmark_ufunc_py}.
|
||||
|
||||
This quantum mechanical state is the component vector in integer basis
|
||||
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
|
||||
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
|
||||
computers and other simulators is necessary.
|
||||
|
||||
|
|
@ -72,7 +71,7 @@ A basic set of gates is implemented in PyQCS:
|
|||
\item{Hadamard $H$ gate.}
|
||||
\item{Pauli $X$ or \textit{NOT} gate.}
|
||||
\item{Pauli $Z$ gate.}
|
||||
\item{The $S$ phase gate.}
|
||||
\item{Phase gate $S$.}
|
||||
\item{$Z$ rotation $R_\phi$ gate.}
|
||||
\item{Controlled $X$ gate: $CX$.}
|
||||
\item{Controlled $Z$ gate: $CZ$.}
|
||||
|
|
@ -98,8 +97,8 @@ new_state = circuit * state
|
|||
\end{lstlisting}
|
||||
|
||||
|
||||
The elementary gates such as $H, R_\phi, CX$ are implemented as single gate
|
||||
circuits and can be constructing using the built-in generators. The generators
|
||||
The elementary gates are implemented as single gate
|
||||
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
|
||||
angle as second argument:
|
||||
|
||||
|
|
@ -117,7 +116,7 @@ Out[2]: (0.7071067811865476+0j)*|0b0>
|
|||
+ (0.7071067811865476+0j)*|0b11>
|
||||
\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
|
||||
read from left to right similar to pipelines on *NIX shells:
|
||||
|
||||
|
|
@ -141,7 +140,7 @@ Out[2]: (0.7071067811865477+0j)*|0b0>
|
|||
\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:
|
||||
|
||||
%\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:
|
||||
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
|
||||
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{aligned}
|
||||
|
|
@ -216,20 +215,20 @@ The edges are stored in an adjacency matrix
|
|||
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 required memory 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.
|
||||
a vertex. Also one must take care to keep the memory required to store a state
|
||||
low. To meet both requirements a linked list-array hybrid is used. 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
|
||||
inherite their time complexity from the sorted linked list.
|
||||
Using this storage method all operations - including searching and toggling edges -
|
||||
inherit their time complexity from the sorted linked list.
|
||||
|
||||
\subsection{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
|
||||
implemented in \lstinline{C} and are exported to \lstinline{python3} in the class
|
||||
\lstinline{RawGraphState}. This class has three main methods to implement the
|
||||
three classes of operations.
|
||||
|
||||
|
|
@ -249,7 +248,7 @@ three classes of operations.
|
|||
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
|
||||
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\\
|
||||
\lstinline{pyqcs.graph.state.GraphState}. It allows the use of circuits as
|
||||
described in \ref{ref:pyqcs_circuits} and provides the method
|
||||
|
|
@ -258,7 +257,7 @@ vector state.
|
|||
|
||||
\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.
|
||||
It should be seen as a reference implementation that can be extended to the needs
|
||||
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:
|
||||
|
||||
\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
|
||||
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}. }
|
||||
\end{enumerate}
|
||||
|
||||
\section{Utilities}
|
||||
|
||||
To make both using the simulators more convenient and to help with using them
|
||||
in as scientific or educational context several utilities have been written.
|
||||
This chapter explains some of them.
|
||||
The package \lstinline{pyqcs} ships with several utilities that are supposed to
|
||||
make using the simulators more convenient. Some utilities are designed to help
|
||||
in a scientific and educational context. This chapter explains some of them.
|
||||
|
||||
\subsection{Sampling and Circuit Generation}
|
||||
|
||||
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
|
||||
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
|
||||
interpreted as qbit indices and are measured in the order they appear.
|
||||
|
||||
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
|
||||
states has yet to be implemented but has $NP$ computational hardness
|
||||
\cite{dahlberg_ea2019}.
|
||||
states is not implemented due to the computational hardness.
|
||||
\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\\
|
||||
\lstinline{pyqcs.list_to_circuit} Converts a list of circuits to a circuit.
|
||||
Writing circuits out by hand can be inconvenient. The function\\
|
||||
\lstinline{pyqcs.list_to_circuit} converts a list of circuits to a circuit.
|
||||
This is particularly helpful in combination with python's
|
||||
\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
|
||||
in \ref{ref:performance} to generate random circuits for both graphical and
|
||||
dense vector simulation. Using the module \lstinline{pyqcs.util.random_graphs}
|
||||
one can generate random graphical states which is more performant than using
|
||||
random circuits.
|
||||
one can generate random graphical states which is faster than using random
|
||||
circuits.
|
||||
|
||||
The function \lstinline{pyqcs.util.to_circuit.graph_state_to_circuit} converts
|
||||
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
|
||||
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}
|
||||
|
||||
Circuits can be drawn using the \LaTeX package \lstinline{qcircuit}; all
|
||||
circuits in this documents use \lstinline{qcircuit}. To visualize the circuits
|
||||
built using \lstinline{pyqcs} the function\\
|
||||
Circuits can be drawn with the \LaTeX package \lstinline{qcircuit}; all
|
||||
circuits in this documents use \lstinline{qcircuit}. To visualize
|
||||
\lstinline{pyqcs} circuits the function\\
|
||||
\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
|
||||
PDFs directly. The diagrams produced by this function are not optimized and the
|
||||
diagrams can be unnecessary long. Usually this can be fixed easily by editing
|
||||
the produced code manually.
|
||||
\lstinline{qcircuit} code. The diagrams produced by this function are not
|
||||
optimized, and the diagrams can be unnecessary long. Usually this can be fixed
|
||||
easily by editing the resulting code manually.
|
||||
|
||||
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 \\
|
||||
\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}
|
||||
\label{ref:performance}
|
||||
|
||||
To test the performance and compare it to the dense vector simulator the python
|
||||
module is used. Although the pure \lstinline{C} implementation has potential
|
||||
for better performance the python module is better comparable to the dense
|
||||
vector simulator which is a python module as well.
|
||||
Testing the performance and comparing the graphical with the dense vector
|
||||
simulator is done with the python module. Although the pure \lstinline{C}
|
||||
implementation has potential for better performance the python module is better
|
||||
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
|
||||
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}
|
||||
\Omega = \left(\{1, ..., 4n\} \otimes \{1, ..., n-1\} \otimes [0, 2\pi)\right)^{\otimes m}
|
||||
\end{equation}
|
||||
|
||||
with the uniform distribution. The continous part $[0, 2\pi)$ is unused when
|
||||
generating random circuits for the graphical simulator; when generating random
|
||||
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 using
|
||||
with the uniform distribution. The continuous part $[0, 2\pi)$ is ignored when
|
||||
generating random circuits for the graphical simulator; in order to generate
|
||||
random circuits for dense vector simulations this is used as the argument $\phi$ of the
|
||||
$R_\phi$ gate. For $m=1$ an outcome is mapped to a gate where
|
||||
|
||||
\begin{equation}
|
||||
\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
|
||||
\cite{timeit} is measured. The resulting graph can be seen in
|
||||
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
|
||||
qbits:
|
||||
|
||||
|
|
@ -403,10 +404,10 @@ qbits:
|
|||
\label{fig:scaling_qbits_log}
|
||||
\end{figure}
|
||||
|
||||
The reason for this scaling will be clear later; one can observe that the
|
||||
performance of the graphical simulator increases in some cases with growing
|
||||
number of qbits when the circuit length is constant. The code used to generate the
|
||||
data for these plots can be found in \ref{ref:code_benchmarks}.
|
||||
The reason for this scaling will be clear later. From simulation data one can
|
||||
observe that the performance of the graphical simulator increases in some cases
|
||||
with growing number of qbits when the circuit length is constant. The code used
|
||||
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
|
||||
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
|
||||
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
|
||||
to the state) highly depends on the state it is applied to. For the dense vector
|
||||
simulator and CHP this is not true: Gate execution time is constant for all gates
|
||||
and states. Because the graphical simulator has to toggle neighbourhoods the
|
||||
gate execution time of the $CZ$ gate varies greatly. The plot Figure \ref{fig:scaling_circuits_linear}
|
||||
One should be aware that the gate execution time (the time required to apply
|
||||
a gate to the state) highly depends on the state it is applied to. For the
|
||||
dense vector simulator and CHP this is not true: Gate execution time is
|
||||
constant for all gates and states. Because the graphical simulator has to
|
||||
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
|
||||
regimes:
|
||||
|
||||
|
|
@ -430,11 +432,11 @@ regimes:
|
|||
\end{figure}
|
||||
|
||||
\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).
|
||||
}
|
||||
\item[Intermediate Regime]{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[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]{\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.}
|
||||
\end{description}
|
||||
|
||||
|
|
@ -445,6 +447,19 @@ regimes:
|
|||
\label{fig:scaling_circuits_measurements_linear}
|
||||
\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}
|
||||
\centering
|
||||
\includegraphics[width=\linewidth]{graphics/graph_low_linear_regime.png}
|
||||
|
|
@ -466,35 +481,18 @@ regimes:
|
|||
\label{fig:graph_high_linear_regime}
|
||||
\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
|
||||
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
|
||||
space a qbit is measured with probability $\frac{1}{4}$. As described in
|
||||
\cite{hein_eisert_briegel2008} the Schmidt measure for entropy is bounded from
|
||||
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
|
||||
space a qbit is measured with probability $\frac{1}{4}$. Pauli measurements
|
||||
decrease the entanglement (and the amount of edges) in a state
|
||||
\cite{hein_eisert_briegel2008}\cite{li_chen_fisher2019}. The frequent
|
||||
measurements in the simulation therefore keeps the amount of edges low thus
|
||||
preventing a transition from the low linear regime to the intermediate regime.
|
||||
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
to execute circuits on other machines, including both real hardware and
|
||||
simulators, a module that exports circuits to OpenQASM \cite{openqasm} seems
|
||||
useful.
|
||||
noisy execution would be an interesting improvement to implement. In order 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
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
Quantum computing has been a rapidly growing field over the last years with
|
||||
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
|
||||
\cite{nielsen_chuang_2010}\cite{gottesman2009}\cite{gottesman1997}\cite{shor1995}
|
||||
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.
|
||||
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}
|
||||
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$
|
||||
\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}
|
||||
\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}
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
%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.
|
||||
\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
|
||||
its generators.
|
||||
|
||||
|
|
@ -552,14 +552,14 @@ Therefore the associated graph is changed as given in the third equation.
|
|||
\label{ref:sec_g_states}
|
||||
|
||||
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
|
||||
forward: No. The most simple cases are the single qbit states $\ket{0},\ket{1}$
|
||||
and $\ket{+_Y}, \ket{-_Y}$. But there is an extension to the VOP-free graph
|
||||
states that allows the representation of an arbitrary stabilizer state. The
|
||||
proof that indeed any state can be represented is purely constructive. As seen
|
||||
in Theorem \ref{thm:clifford_group_approx} any $c \in C_n$ can be constructed
|
||||
from $CZ$ and $C_L$. In the following discussion it will become clear that both
|
||||
$C_L$ and $CZ$ can be applied to a general graph state
|
||||
any stabilizer state be described using just a graph? The answer is no. The
|
||||
most simple cases are the single qbit states $\ket{0},\ket{1}$ and $\ket{+_Y},
|
||||
\ket{-_Y}$. But there is an extension to the VOP-free graph states that allows
|
||||
the representation of an arbitrary stabilizer state. The proof that any
|
||||
state can be represented is purely constructive. As seen in Theorem
|
||||
\ref{thm:clifford_group_approx} any $c \in C_n$ can be constructed from $CZ$
|
||||
and $C_L$. In the following discussion it will become clear that both $C_L$ and
|
||||
$CZ$ can be applied to a general graph state
|
||||
\footnote{
|
||||
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
|
||||
|
|
@ -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)$
|
||||
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
|
||||
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
|
||||
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.
|
||||
}.
|
||||
\end{definition}
|
||||
|
|
@ -603,11 +603,12 @@ immediately:
|
|||
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
|
||||
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
|
||||
operators:
|
||||
operators.
|
||||
|
||||
\begin{theorem}
|
||||
\label{thm:cl24}
|
||||
$C_L$ has $24$ degrees of freedom disregarding a global phase \cite{andersbriegel2005}.
|
||||
\end{theorem}
|
||||
\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
|
||||
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$
|
||||
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
|
||||
sees that just the vertex operators are changed and the new vertex operators
|
||||
are given by
|
||||
|
|
@ -658,9 +659,9 @@ are given by
|
|||
\end{equation}
|
||||
|
||||
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$
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
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$.
|
||||
|
|
@ -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
|
||||
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
|
||||
vertex $j$ gives substance to the following theorem:
|
||||
|
||||
|
|
@ -729,7 +730,7 @@ steps:
|
|||
}
|
||||
\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
|
||||
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
|
||||
|
|
@ -755,23 +756,24 @@ non-operand neighbours and $b$ does not. Now the state $\ket{G}$ has the form
|
|||
\end{equation}
|
||||
|
||||
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{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{+} \\
|
||||
&= \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{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$.
|
||||
|
||||
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
|
||||
that the graphical representation of a stabilizer state is indeed able to
|
||||
represent any stabilizer state. If one wants to do computations using this
|
||||
formalism it is however also necessary to perform measurements.
|
||||
that the graphical representation of a stabilizer state is able to represent
|
||||
any stabilizer state. If one wants to do computations using this formalism it
|
||||
is also necessary to perform measurements.
|
||||
|
||||
\subsection{Measurements on Graph States}
|
||||
\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
|
||||
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
|
||||
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{equation}
|
||||
|
||||
Where $\tilde{g}_a \in \{\pm X_a, \pm Y_a, \pm Z_a\}$. Therefore, it is
|
||||
enough to study the measurements of any Pauli operator on the vertex operator
|
||||
free graph states. The commutators of the observable with the $K_G^{(i)}$ are
|
||||
quite easy to compute. Note that Pauli matrices either commute or anticommute
|
||||
and it is easier to list the operators that anticommute:
|
||||
Where $\tilde{g}_a \in \{\pm X_a, \pm Y_a, \pm Z_a\}$. Therefore, it is enough
|
||||
to study the measurements of any Pauli operator on the VOP-free graph states.
|
||||
The commutators of the observable with the $K_G^{(i)}$ are easy to compute.
|
||||
Note that Pauli matrices either commute or anticommute and it is simpler to
|
||||
list the operators that anticommute:
|
||||
|
||||
\begin{equation}
|
||||
\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
|
||||
$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
|
||||
$-\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
|
||||
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
|
||||
following results
|
||||
following results:
|
||||
|
||||
\begin{equation}
|
||||
\begin{aligned}
|
||||
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{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
|
||||
diagonal in measured observable and has the correct eigenvalue. When comparing
|
||||
with Lemma \ref{lemma:stab_measurement} in both cases $Y,Z$ the anticommuting
|
||||
diagonal in the measured observable and has the correct eigenvalue. When comparing
|
||||
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
|
||||
\footnote{$n_a \otimes n_a$ should be read as $\{\{i,j\} | i,j \in n_a, i \neq j\}$.}
|
||||
|
||||
\begin{equation}
|
||||
\begin{aligned}
|
||||
|
|
@ -854,7 +857,7 @@ stabilizer $K_G^{(a)}$ is chosen. The graph is changed according to
|
|||
\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{aligned}
|
||||
|
|
|
|||
|
|
@ -190,11 +190,13 @@
|
|||
urldate={19.09.2019},
|
||||
title={IBM Q - What is quantum computing?},
|
||||
author={IBM},
|
||||
note={https://www.ibm.com/quantum-computing/learn/what-is-quantum-computing/},
|
||||
year=2019
|
||||
}
|
||||
@online{
|
||||
intelqc,
|
||||
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},
|
||||
title={Intel Press Kit: Quantum Computing},
|
||||
author={Intel},
|
||||
|
|
@ -203,6 +205,7 @@
|
|||
@online{
|
||||
microsoftqc,
|
||||
url={https://www.microsoft.com/en-us/quantum/default.aspx},
|
||||
note={https://www.microsoft.com/en-us/quantum/default.aspx},
|
||||
urldate={19.09.2019},
|
||||
title={Quantum Computing | Microsoft},
|
||||
author={Microsoft},
|
||||
|
|
@ -211,6 +214,7 @@
|
|||
@online{
|
||||
dwavesys,
|
||||
url={https://www.dwavesys.com/quantum-computing},
|
||||
note={https://www.dwavesys.com/quantum-computing},
|
||||
urldate={19.09.2019},
|
||||
title={Quantum Computing | D-Wave Systems},
|
||||
author={D-Wave Systems Inc}
|
||||
|
|
@ -218,6 +222,7 @@
|
|||
@online{
|
||||
lrzqc,
|
||||
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},
|
||||
title={LRZ-Newsletter Nr. 08/2019 vom 01.08.2019},
|
||||
author={S. Vieser},
|
||||
|
|
@ -226,6 +231,7 @@
|
|||
@online{
|
||||
heise25_18,
|
||||
url={https://www.heise.de/select/ct/2018/25/1544250249368810},
|
||||
note={https://www.heise.de/select/ct/2018/25/1544250249368810},
|
||||
urldate={19.09.2019},
|
||||
title={Europa entfesselt Quanten-Power},
|
||||
author={Arne Grävemeyer},
|
||||
|
|
@ -287,3 +293,10 @@
|
|||
title={The Computer Language Benchmarks Game},
|
||||
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
|
||||
\textbf{Erklärung zur Anfertigung:}\\
|
||||
Ich habe die Arbeit selbständig verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel be-
|
||||
nutzt und bisher keiner anderen Prüfungsbehörde vorgelegt. Außerdem bestätige ich hiermit, dass die
|
||||
vorgelegten Druckexemplare und die vorgelegte elektronische Version der Arbeit identisch sind, dass ich
|
||||
über wissenschaftlich korrektes Arbeiten und Zitieren aufgeklärt wurde und dass ich von den in § 24 Abs.
|
||||
5 vorgesehenen Rechtsfolgen Kenntnis habe.
|
||||
Ich habe die Arbeit selbständig verfasst, keine anderen als die angegebenen
|
||||
Quellen und Hilfsmittel benutzt und bisher keiner anderen Prüfungsbehörde
|
||||
vorgelegt. Außerdem bestätige ich hiermit, dass die vorgelegten Druckexemplare
|
||||
und die vorgelegte elektronische Version der Arbeit identisch sind, dass ich
|
||||
über wissenschaftlich korrektes Arbeiten und Zitieren aufgeklärt wurde und dass
|
||||
ich von den in § 24 Abs. 5 vorgesehenen Rechtsfolgen Kenntnis habe.
|
||||
\\
|
||||
\\
|
||||
Unterschrift:
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user