@@ -338,15 +338,17 @@ The categorisation of multiple post-classical resources is also novel, as is the
\REM{More here. semantics of quantum programming languages is still very young, and already many dead ends. This project gives a unique opportunity for applications to drive theory.}
Deep quantum compilation includes many tools that derive from foundational research.
The \dzxc system will be not just a compiler but also a foundational tool (for example for the characterisation of post-classical resources).
All other systems take the gate model of quantum computing as a given.
This is natural, as it is the \emph{lingua franca} of quantum computation researchers.
The project proposes a new foundation for quantum software, based on a flexible tensor-based representation, combined with mathematically rigorous semantics and formal verification.
The ability to demonstrate quantum speed-up at compile-time will enhance our understanding of quantum information.
A key example of why this is necessary, exploited by NQIT and others, is that lattice surgery operations on surface codes do not fit into the gate model, but have simple representations in the \zxcalculus\cite{BH-2017}.
The ability to demonstrate quantum speed-up at compile-time will enhance our understanding of what is unique about quantum processing.
The deep quantum compiler we will develop
will do the heavy lifting of managing resources and mapping operations to quantum hardware, %allowing the developers of both hardware and software to focus elsewhere.
%This will
facilitating the development of new architectures and technologies for quantum computing.
A key example, exploited by NQIT and others, is that lattice surgery operations on surface codes do not fit into the gate model, but have simple representations in the \zxcalculus\cite{BH-2017}.
...
...
@@ -398,6 +400,11 @@ work, and will be done early in the project
(\ref{task:algorithms},\ref{task:basic-opt}). Further, at this stage
a program can be translated to a fault-tolerant equivalent with
respect to a chosen error-correcting code.
We will also develop translations for the \dzxc system from existing quantum programming languages~(\ref{task:trans1}) early in the project.
These will provide
examples and test cases, and allow comparative
evaluation.
The annotations of the second layer provide the basis of \emph{augmented
...
...
@@ -449,61 +456,20 @@ specific annotations (\ref{wp:representation}), and rewrite strategies which exp
Concrete tensor networks have a fixed finite size, whereas algorithms
are described in parametric fashion, \eg varying according the
input size.
To accommodate this, the \dzxc system would incorporate
To use this, the \dzxc system will incorporate
a second class of annotations to represent limited forms of iteration and recursion, yielding \emph{parametric}\zx terms.
While the hardware-derived annotations are inferred in a bottom-up fashion, the parametric structure is produced top-down, based on the original
high-level quantum procedure provided as input.
This is a challenging part
of the project (\ref{task:betterboxes}); however, we have experience of
We will develop translations for the \dzxc system from existing quantum programming languages~(\ref{task:trans1}) early in the project.
These will provide
examples and test cases, and allow comparative
evaluation.
\BREM{
\begin{itemize}
% \item methodology centres around common language: AZX
% \item (\textbf{idea:} what about IZX, \textit{implemented} ZX?
% i.e. something more active/evocative than \textit{annotations})
% \item this has two layers (1) the ZX-graph layer, a technique for representing quantum processes, and (2) annotations which describe parameters as well as how process is implemented within a computational model
% \item (1) already done (cf. ten years of research!)
% \item (2) is guided in two ways: \textit{top-down} (capturing language features of Quipper) and \textit{bottom-up} (capturing hardware requirements)
\item a common language synchronises the project across sites, implementation details (e.g. platform, language, etc.), and goals (optimisation, EC, simulation)
\item development focuses around simple, modular tools, mitigating \textbf{risk} and increasing \textbf{agility} of the project as a whole
\item
\end{itemize}
}
\REM{
The front-end is responsible for translating a high-level programming
language to the IR. We will adapt the existing \emph{Quipper}
compiler \cite{Alexander-S.-Green:2013fk} for this purpose. % We will
% develop static analysis techniques like abstract interpretation
% \cite{Perdrix2008} or implicit computational complexity
% \cite{DALLAGO2010377} to optimise various resources. Such
% optimisations may be performed at the high-level or passed to the IR
% as annotations.
The front-end will later be adapted to generate the
parametric IR (see \ref{task:betterboxes}.)
}
\REM{These modules will be used to implement sophisticated
quantum algorithms which will serve as robust benchmarks
for the other WPs.
idea of separating program compile time from circuit compile time
(following the {\em Quipper} and {\liquid} architecture).
other objectives. Some program parameters and control flow features
of the programming language will be translated into the \azx\
representation.
}
A core component in optimising quantum computers is identifying which resources are necessary for non-classical computing. The identification of this quantum speed-up is a live open problem. Drawing on the foundational expressiveness of the \zxcalculus and the expertise in the consortium, and existing automated theorem provers for the calculus, we will identify and express these resources in the \dzxc system.This will enable optimising for use of these resources, and the ability to say at compile time that a procedure is using non-classical processing.
Furthermore, the compiler stack and associated library set of post-classical resources will naturally become a software tool for benchmarking quantum devices, greatly enhancing the maturity of quantum computing technology.
The four major work packages of the project are structured into
various themes: the relation between \zx and other quantum computing representations (\ref{wp:frontend}); necessary theoretical developments of \zx (\ref{wp:representation}); optimisation strategies independent of implementations (\ref{wp:theory}); using annotated \zx to compile and optimise for specific quantum devices.(\ref{wp:usefulstuff}).
various themes: the relation between \zx and other quantum computing representations (\ref{wp:frontend}); necessary theoretical developments of \zx (\ref{wp:representation}) and the identification of quantum-unique resources; optimisation strategies independent of implementations (\ref{wp:theory}); using annotated \zx to compile and optimise for specific hardware.(\ref{wp:usefulstuff}).
