From 9b8820a9d95b7b2aabbd7d0edba71f46c8ff299e Mon Sep 17 00:00:00 2001
From: Benoit Valiron <benoit.valiron@lri.fr>
Date: Tue, 12 Feb 2019 10:08:27 +0100
Subject: [PATCH] Sec. 1.3.3 -- Note: in previous log, please read "1.3.2"
---
NEWPROPOSAL/FULLPROP.tex | 35 +++++++++++++++++++++--------------
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/NEWPROPOSAL/FULLPROP.tex b/NEWPROPOSAL/FULLPROP.tex
index 9d90521..1de718c 100644
--- a/NEWPROPOSAL/FULLPROP.tex
+++ b/NEWPROPOSAL/FULLPROP.tex
@@ -704,7 +704,7 @@ architectures and error correcting schemes to the system
\oldt{\benREM{This
paragraph needs refactoring, but I need Belen's input to make a
- vaguely coherent new text}
+ vaguely\\coherent new text}
Since the overall goal of the project is to produce a
\emph{retargetable} compiler, able to generate executables for
multiple architectures, these differing characteristics must be taken
@@ -743,10 +743,22 @@ will be used to compare and choose amongst the possible solutions.
\subsubsection{Machine-independent optimisation}
\label{sec:repr-reas-azx}
-\oldt{The formal mechanisms for transforming the \azx diagrams produced by
+The formal mechanisms for transforming the \azx diagrams produced by
HLL compilers into optimised, physically implementable computations
are the theoretical core of this proposal, and developing effective
-techniques for working with \azx diagrams are a prerequisite for our success.
+techniques for working with \azx diagrams are a prerequisite for our
+success. We forsee three stage in the compilation process of an \azx
+term into a physical machine. The first two stages are
+machine-independent (\ref{wp:theory}) while the last stage is machine
+dependent (\ref{wp:usefulstuff}).
+
+The first stage of the compilation process represents a ``generic optimisation'' subroutine (\ref{task:basic-opt}), which may be applied to arbitrary \zx terms.
+This subroutine will re-write \zx terms into ones with fewer resources in a broadly applicable sense, such as fewer total nodes or fewer nodes which realise non-Clifford transformations (for instance, corresponding to $T$ gates).
+This may be developed independently of the results of WP1 or WP2 using existing techniques (as well as incorporating any further useful techniques developed in \ref{task:axioms} and~\ref{task:algorithms}).
+
+The second stage of the compilation process is to take a generic \zx term expressing a computation on idealised quantum systems, and re-write it as a \zx term representing an equivalent transformation of error-corrected qubits (\ref{task:ECC}).
+As well as the \zx terms to translate, this will take as input a specification the particular error correction code or other fault-tolerance construction to apply.
+
Recent breakthroughs in the theory of the \zx-calculus
\cite{Jeandel2017A-Complete-Axio,NW-2017}, have shown that whenever two
@@ -766,7 +778,7 @@ presentations of the Clifford+T \zx-calculus and develop strategies
for effectively simplifying \zx-diagrams. These include Knuth-Bendix
completion and theory synthesis.
In task~\ref{task:axioms}, we will extend the
-\zx-calculus in two dimensions. The first is to expand into complete
+\zx-calculus in two respects. The first is to expand into complete
and universal qudit variations to work effectively beyond 2-level
systems, and the second is to gain a deeper understanding of the role
played by W-type tensors as they interact with the generators of the
@@ -786,7 +798,8 @@ information such as timing, noise, or fidelity. In real-world systems, these
can vary vastly between qubits interacting in different ways
(e.g. neighbouring in ion trap vs. interactions mediated by optical
channel~\cite{PhysRevX.4.041041}) or stored in different physical
-modes.}
+modes.
+
@@ -794,6 +807,7 @@ modes.}
\label{sec:comp-quant-softw}
\oldt{
+ \benREM{To update}
In the second phase we switch attention to real computers. The first
target is a classical simulator running on HPC hardware provided by
our industrial partner Bull. This will leverage existing expertise in
@@ -807,7 +821,7 @@ N. de Beaudrap for NQIT) or our advisory board (L. DiCarlo in Delft).
Since these architectures are dissimilar, tackling both is an ideal
demonstration of our approach. The completion of this phase will
allow quantum programs represented as \azx terms to be run on real
-hardware.
+hardware.}
An \azx term produced by the compiler front-end is, by design, an
abstract tensor network, perhaps annotated with some useful
@@ -852,13 +866,6 @@ The tasks to be performed within WP4 may be broadly described in terms of how th
These stages are: (i)~an initial round of generic, hardware-independent optimisations; (ii)~application of some choice of strategy for error correction; (iii)~translation to a specialised annotation system which represents the parameters and constraints of a specific hardware implementation; and finally (iv)~another round of optimisation within the constraints imposed by the error correction and hardware models.
In addition to the development of the tools for these stages, WP4 will develop an interface for the specification of the annotation systems used in stages (iii) and~(iv) above, allowing for easy extension of the \azx compiler to arbitrary hardware systems and allowing \azx to act as a general-purpose quantum compiler.
-The first stage of the compilation process represents a ``generic optimisation'' subroutine (\ref{task:basic-opt}), which may be applied to arbitrary \zx terms.
-This subroutine will re-write \zx terms into ones with fewer resources in a broadly applicable sense, such as fewer total nodes or fewer nodes which realise non-Clifford transformations (for instance, corresponding to $T$ gates).
-This may be developed independently of the results of WP1 or WP2 using existing techniques (as well as incorporating any further useful techniques developed in \ref{task:axioms} and~\ref{task:algorithms}).
-
-The second stage of the compilation process is to take a generic \zx term expressing a computation on idealised quantum systems, and re-write it as a \zx term representing an equivalent transformation of error-corrected qubits (\ref{task:ECC}).
-As well as the \zx terms to translate, this will take as input a specification the particular error correction code or other fault-tolerance construction to apply.
-
The third stage of the compilation process attempts to map a \zx term into an equivalent \zx term which closely models the constraints of a target architecture (\ref{task:runnable}).
@@ -871,7 +878,7 @@ This will involve the development of a theory of re-writing techniques developed
By performing a final round of optimisations using a theory of rewrites which apply to all ArcTAn annotation systems, we aim to make possible a reduction in the resources used in any particular hardware platform without requiring the use of bespoke techniques for each target architecture.
Annotation systems representing the hardware implementation are to be provided by the development environment, using a standardised interface.
-By providing public documentation for this interface~(\ref{task:backendapi}), we enable third-party developers to extend the functionality of the \azx compiler to arbitrary platforms, thus ensuring the suitability of the \azx compiler as part of a general-purpose quantum software development platform.}
+By providing public documentation for this interface~(\ref{task:backendapi}), we enable third-party developers to extend the functionality of the \azx compiler to arbitrary platforms, thus ensuring the suitability of the \azx compiler as part of a general-purpose quantum software development platform.
\subsection{Interdisciplinary nature}
--
GitLab