The trusted computing base for Qwire is quite small. Besides for the core of Coq itself, we include a few axioms from the Coq standard library. Our matrices are really functions which requires us to use the functional extensionality axiom from Coq’s standard library to prove that two matrices are equal:
Axiom functional_extensionality_dep : ∀ {A} {B : A → Type},
∀ (f g : ∀ x : A, B x), (∀ x, f x = g x) → f = g.
Furthermore, as noted in Section 5.4.1, Coq’s real numbers are axiomatized: 0 and 1 are simply given as parameters and the rules about addition, multiplication and other operations are given in terms of axioms. Fortunately, these axioms are very well studied and known to be consistent.
The Qwire development itself adds three additional axioms. The first two are well established facts about linear algebra. asserts that the right inverse
File Lemmas Theorems Facts Propositions Examples Prelim.v 32 0 0 0 0 Monad.v 3 0 0 1 0 Monoid.v 18 0 0 0 10 Complex.v 84 0 0 0 0 Matrix.v 91 5 0 1 1 Quantum.v 84 0 0 2 2 Contexts.v 72 0 0 0 0 HOASCircuits.v 2 0 0 0 0 TypeChecking.v 4 0 0 0 1 DBCircuits.v 17 0 0 1 0 Denotation.v 113 2 2 19 0 HOASLib.v 22 0 0 0 0 SemanticLib.v 14 0 0 0 0 HOASExamples.v 38 0 0 4 1 Composition.v 1 1 2 0 0 Ancilla.v 8 0 2 2 0 Symmetric.v 45 3 18 1 0 Oracles.v 35 1 2 3 1 Deutsch.v 5 0 0 0 1 Equations.v 26 0 0 3 0 HOASProofs.v 22 0 0 8 2 Arithmetic.v 38 0 0 1 32 QASM.v 0 0 0 0 1 QASMPrinter.v 0 0 0 0 0 QASMExamples.v 0 0 0 0 2 Totals 774 12 26 46 54
of a square matrix is also its left inverse and kron_assoc says that the Kronecker product is associative. Proving these lemmas requires a substantial amount of linear algebra that we haven’t yet formalized. Similarly, we have axiomatized the operator sum decomposition theorem,
Axiom operator_sum_decomposition : ∀ {m n} (l : list (Matrix m n)), outer_sum l = 'I_n ↔ WF_Superoperator (operator_sum l).
whose proof requires more concepts from linear algebra than we were able to provide. See Section 6.1.4 for details.
Beyond these, we have a number statements beginning with Fact, to emphasize that these were admitted. All of these are used exclusively in the files on reversibil- ity, plus Deutsch.v which depends on compositionality axioms and isn’t discussed in this dissertation. We refer the reader to Table 8.1 for an synopsis of the admitted statements.
Finally, we include a number of conjectures, which begin withProposition2, and correspond to aborted claims that we would like to prove in the future.
We give a summary of the claims in Qwire in Table 10.2. A complete list of theorems, lemmas, and facts in the Qwire development is provided in Appendix C.
Chapter 11
Open Wires and Loose Ends
The arguably grandiose title of this dissertation is “Formally Verified Quantum Pro- gramming”. Despite substantial recent interest, this area of research is in its infancy. In Chapter 1, we made an bold claim: Quantum programming demands formal verifi- cation, and therefore quantum programming languages must have well-defined seman- tics and support for verification. This thesis, along with the broader Qwire project and the work that inspired it, only begins to tackle this issue. In this chapter, we will discuss the issuesQwire still needs to address in order to serve both as a real-world quantum programming language and a robust, user-friendly verification tool.
This chapter will also seek to address a more interesting question, and hopefully one that excites the reader. What else canQwire do? To be precise, what challenges does quantum computing face, in both the short term and the long term, and how can Qwire help address those challenges? In this thesis, we have depicted quantum computing as an exciting new technology that lies somewhere along the horizon. But as John Preskill pointed out in a recent survey (Preskill, 2018), we should be looking at multiple horizons, the first of which (Noisy Intermediate-Scale Quantum Computing, or NISQ) is years, not decades, away. We will try to address howQwire and formal verification can help us run the quantum programs of tomorrow, not just those of the far future.
11.1
Computing in
Qwire
In the “future work” section of our 2017 QPL paper (Rand et al., 2017), we promised to move Qwire to a more efficient backend, specifically referencing Qwire’s lin- ear algebra library. Aside from the linear algebra, we wanted to move away from our Coquelicot-based (Boldo et al., 2015) representation of complex numbers, which
Qwirestill uses. Here we address the limitations of these libraries and the challenges of migrating away from them.
The Coquelicot complex number library, which we have modified and included in the Qwire development, is based on the Coq standard library’s real numbers. Co-
quelicot’sC is simply a pair of CoqRs. Coq’s real numbers, in turn, areaxiomatized: 0,1,+,−,∗, ∖ and < are simply declared as Coq parameters; they have no computa- tional content. Likewise, the associativity, commutativity, and distributivity of+and ∗ are declared as axioms, as are the remaining field laws.
From a computational standpoint, this is awful. It is never possible to reduce real number expressions using call-by-value or call-by-name reduction rules, because no definitions exist to reduce. In Coq’s defense, this limitation is inherent to the real numbers:e+π cannot normalize to anything bute+π. The exact nature of our proofs prohibit using floating point numbers instead of reals, though once we account for error terms (see the next section), we may be able to loosen this restriction.
How can we improve Qwire’s real number library to allow for computation? Potentially, we could restrict ourselves to the algebraic numbers. Right now, only one of our unitary gates, the Rθ =(1 00eiθ) gate, allows us to multiply our states by non-
algebraic numbers, and we typically instantiate θ with π/n for an integer n, yielding
n
√
−1. We could then compute by grouping like terms. It’s not clear how difficult this would be to implement, and we are not aware of a library that does this.
The other bottleneck is our matrix library. which is quite slow. In fact, we have trouble accounting for quite how slow it is, struggling to multiply even 16×16 di- mensional matrices. In our QPL paper, we suggested adopting the Mathematical Components library’s matrices (Mahboubi et al., 2016) for proofs, while reflecting into the Coq Effective Algebra library (Cano et al., 2016) for efficient computation. This ultimately raised several obstacles.
The Mathematical Components library, written in the SSReflect proof language and used in the formally verified proofs of the Four Color Theorem (Gonthier, 2008) and Feit-Thompson Theorem (Gonthier et al., 2013), uses dependently typed ma- trices. On the face of it, this is an excellent use-case for dependent types. Matrix multiplication is only defined on two matrices of dimensions m×n and n×o, respec- tively, and dependent types can enforce this property. Unfortunately, the Kronecker product, which is integral to quantum computation, multiplies the dimensions of its argument matrices. As soon as we start dealing with matrices of dimensions 2m and
2n, where neither m nor n is concrete, convincing the Coq typechecker that we are
indeed multiplying compatible matrices becomes exceedingly difficult. This motivated our decision to usephantom types (Leijen and Meijer, 1999), lightweight types meant to guide development that are not enforced by the typechecker, in our matrices. We discussed this design choice in detail at the Fourth International Workshop on Coq for Programming Languages (Rand et al., 2018b).
CoqEAL has a number of advantages in terms of efficiently computing with large matrices, including an implementation of Strassen’s Algorithm (Strassen, 1969) for efficient multiplication, but a number of drawbacks as well. For one, it is not designed for proofs, but rather, for computation. That means we would have to convert some other matrix representation to CoqEAL matrices and only use them in the final stages of certain proofs involving concrete matrices. The current version of CoqEAL
also does not work with the Coq real numbers library and, hence, will not work with our complex numbers. These challenges could probably be overcome, but doing so would have limited payoff in the absence of the mathematical components library and computational complex numbers.