Quantum Programming Languages–A Survey–

Roland Rudigerr.ruediger@fh-wolfenbuettel.de

Seminar talks given at Institut fur Mathematische Physik , TU Braunschweig

February 26/27, 2003

Outline

– Simulation of Quantum Computers

– “Classical” Programming Languages—Concepts and Terminology

– QPLs: Design Considerations

– QPLs: Detailed Examples

Simulation of Quantum Computers

. review of quantum computer simulators by J. Wallace [home page]

. 37 “simulators” (Jan. 2002) covering a wide range of QM

. some features:

– implementation languages: Pascal, C++, Java, . . . , Haskell,

Mathematica, . . . , Perl, . . . ; also: implementation on a parallel

machine

– simulation of single algorithms vs generic simulator

– visualization of quantum physical processes / algorithms

– new language vs library support for implementing algorithms

in conventional languages

– specific new data structures (entanglement of variables)

– different computing models: quantum Turing machine vs quan-

tum circuit model

“Classical” Programming Languages—Concepts and Ter-

minology

. remark on terminology: “programming”

. pragmatic vs theoretical approach

. programming in the small vs programming in the large

. classes of programming languages:

– imperative programming languages

Computation is seen as a sequence of state transitions on a set

of state variables.

language elements: e. g. assignment statement

refined classification (based on programming methodology):

∗ structured (e. g. Pascal)

∗ modular (e. g. Modula-2)

∗ object-oriented (e. g. C++, Java, Eiffel, . . . )

∗ also: mixtures modular / object-oriented (e. g. Oberon)

– functional programming languages

program describes computation of a function:

no variables, no assignment statements (in a purely functional

language)

formal basis: λ-calculus (Church)

examples: Lisp, ML, Scheme, Haskell, . . .

– logic programming languages

also: declarative programming languages, rule-based

example: Prolog

. syntax: context free grammar

Context free means: non-terminal symbols can be substituted in-

dependently of their context (lhs of production rule: exactly one

non-terminal symbol)

. semantics (adopted from [Mey90, ch. 4]):

– translational semantics

meaning of a language is expressed by a translational schema:

program in this language is translated into a program in an-

other (known) language

– operational semantics

semantics of a language is defined by an interpreting automa-

ton: a formal device capable of formally executing a program

– denotational semantics

meaning of a program is a mathematical object, a function

(whereas in translational semantics it’s another program)

– axiomatic semantics

basis: program formulae

{P} a {Q}

P , Q are assertions, specifically:

∗ a precondition, P

∗ a postcondition, Q

∗ a: instruction

meaning of a program formula:

If a is executed in a state in which assertion P is satis-

fied, then it will result in a state in which assertion Q is

satisfied. [Mey90, p. 111]

. abstraction / abstract datatypes (ADTs)

– good examples include:

∗ First-In-First-Out (FIFO) queue

∗ Stack

∗ Priority Queue

– data and operations acting on these data are combined to form

“objects”

– implementation details remain invisible

– excessively large example based on the idea of abstraction:

Java library (API) (Application Programming Interface)

(estimate of 20.000 - 30.000 names (methods, attributes))

First-In-First-Out (FIFO) queue (ADT formalized):

SPECIFICATION ...

LIBRARY Boolean, Integer ENDLIB (* library types *)

...

TYPE fifo IS

...

OPNS (* operations *)

( 1) empty: -> fifo

( 2) put: int, fifo -> fifo

( 3) head: fifo -> int

( 4) tail: fifo -> fifo

( 5) isempty: fifo -> bool

... ... continued ...

... ...

EQNS (* equations or axioms *)

FORALL f: fifo, d1, d2: int

OFSORT bool (* boolean equations *)

( 6) isempty (empty) = true ;

( 7) isempty (put (d1, f)) = false ;

OFSORT fifo (* fifo equations *)

( 8) tail (empty) = empty ;

( 9) tail (put (d1, empty)) = empty ;

(10) tail (put (d1, put (d2, f))) = put (d1, tail (put (d2, f))) ;

OFSORT int (* integer equations *)

(11) head (put (d1, put (d2, f))) = head (put (d2, f)) ;

(12) head (put (d1, empty)) = d1 ;

(13) head (empty) = 0 ;

ENDTYPE

ENDSPEC

QPLs: Design Considerations

. talking about and specifying QPLs?? answers for questions (never)

to come?

. What can (or cannot) be expected? (pros and cons)

– new fundamental insights into the “oddities” of quantum the-

ory??

QPLs might serve as a “catalyst” for asking new questions

– helpful in finding new algorithms??

cf learning Pascal and re-inventing heapsort

– but: exact notations of algorithms require some sort of pro-

gramming language notation

one goal could be: formalized description of algorithms by

means of a universal language

– fresh look at quantum systems

(What can physics learn from classical concepts of computer

science?)

– feasibility of computer science concepts (of classical origin)

(What can computer science learn from physics?)

– What can be formulated using existing language concepts?

example modularization: composing a larger system from its

parts

allocated memory is additive

– QPL-design isn’t merely numerics of matrix operations |ψ′〉 =

U |ψ〉main difference: program structure

– “operational view” to quantum systems

one important aspect of programming languages: handling of

a system / machine by non-specialists

– didactical aspects

. hardware model:

QRAM model (Knill [Kni96], Bettelli et al. [BCS01])

� -

-

�

device

quantum quantum

devicedriver

bytecode

measure

Classical Computer

(Master) (Slave)

Quantum Processor

basic idea [BCS01, p. 15]: What is really needed is a mechanism

for generating the whole circuital description before the quan-

tum device is even fired up, applying algebraic simplifications

once for all.

. alternatives

– pragmatic vs theoretical approach

– new language vs conventional language with library extension

historical analogy: transputer

. one way of designing an ADT based “high level” language:

6 6 6 66

QFT ... ... ...

QPL based on basic functions ...

Reset MeasureU(α, β, γ, δ)CNotCreate

Niels Bohr:

However far the quantum phenomena transcend the

scope of classical physical explanation, the account of

all evidence must be expressed in classical terms. The

argument is simply that by the word ‘experiment’ we re-

fer to a situation where we can tell others what we have

done and what we have learned and that, therefore, the

account of the experimental arrangement and the results

of the observations must be expressed in unambiguous

language with suitable application of the terminology of

classical physics.

QPLs: Detailed Examples

Survey

QCL Q language qGCL (Block-)QPL

new language × × ×standard lang. / library ×imperative language × × ×functional language ×simulator available × ×pragmatic approach × ×theoretical approach × ×formal semantics × ×universal language × × × ×

QCL (Quant. Computation Language) B. Omer

Q language S. Bettelli, T. Calarco,L. Serafini

qGCL (Quant. Guarded Command Lang.) J.W. Sanders, P. Zuliani

QPL (Quant. Programming Language) P. Selinger

Q-gol (G. Baker)

Greg Baker’s Thesis on Q-gol

Additional remarks in thesis-points

general comments:

• Q-gol: one of the first attempts of designing and implementing a

quantum progamming language

• graphical tool for building and simulation of quantum circuits; uses

the gate formalism

• is not a concise programming language

• not able to implement and simulate all known quantum algorithms

QCL (B. Omer)

General properties

The relevant papers on QCL:

. Classical Concepts in Quantum Programming, 2002 [Om02] abs

. Quantum Programming in QCL, 2000 [Om00] (B. Omer’s master

thesis in computing science)

. A Procedural Formalism for Quantum Computing, 1998 [Om98]

(B. Omer’s master thesis in theoretical physics)

general comments:

• first actual quantum programming language

• (rudimentary) procedural language, classical sublanguage

• not on top of a standard classical language

• automatic scratch space management

• syntactic reversibility of user-defined quantum operations

• syntax like C / Pascal

• universal language: can implement and simulate all known quan-

tum algorithms

• no program refinement (no refinement calculus)

• no (formal) semantics

• non-trivial unitary operations are functions (function call syntax)

QCL as a classical language

// program example: recursive// and non-recursive function call:

int factorialR(int x) {// recursive implementation// precondition x >= 0if x == 0 {

return 1;}return

x*factorialR(x-1);}

int x = 5;print x, "! = ", factorialR(x);

//-------------------------------

int factorialNR(int x) {// iterative implementation// precondition x >= 0int k;int y = x;

if (y == 0) or (y == 1) {return 1;

}else { // "else" for better readability

// here: y >= 2k = y;while y >= 3 {

y = y - 1;k = k*y;

}return k;

}}

x = 7;print x, "! = ", factorialNR(x);

print "The End.";

/* result:: 5 ! = 120: 7 ! = 5040: The End.

*/

quantum memory management

/*

QCL, p 53*/

// start QCL with 16 qubits

qureg a[4]; // allocate a 4-qubit register

qureg b[3]; // allocate another 3-qubit register

print "a: ", a, " b: ", b; // show actual qubit mappings

/*

: a: |............3210> b: |.........210....>

*/

/*

QCL, p. 53

*/

qureg a[3]; // allocate 3 qubits

procedure test() {

qureg b[2];

print a, b;}

test(); // local register b gets allocated

qureg c[3]; // allocate another 3 qubits

print a, c; // qubits from b have been reclaimed

/*

: |.............210> |...........10...>

: |.............210> |..........210...>

*/

/*

QCL, p. 54

*/

qureg q[4];Mix(q);

print "dump q: ";

dump;

/*

: dump q:

: STATE: 4 / 6 qubits allocated, 2 / 6 qubits free

0.25 |000000> + 0.25 |001000> + 0.25 |000100> + 0.25 |001100> + 0.25 |000010>

+ 0.25 |001010> + 0.25 |000110> + 0.25 |001110> + 0.25 |000001> + 0.25 |001001>

+ 0.25 |000101> + 0.25 |001101> + 0.25 |000011> + 0.25 |001011> + 0.25 |000111>

+ 0.25 |001111>

*/

quantum variables

see [Om02, p. 6]:

type restriction

qureg none

quconst invariant to all sub-operators

quvoid has to be empty when the un-inverted operator is called

quscratch has to be empty before and after the call

but: proper type checking is a problem: the knowledge of the quantum

device state is required

quantum expressions [Om00, p. 57]

Expression Description Register

a reference 〈a0, a1, . . . , an〉a[i] qubit 〈ai〉a[i:j] substring 〈ai, ai+1, . . . , aj〉a[i\l] substring 〈ai, ai+1, . . . , ai+l−1〉a & b concatenation 〈a0, a1, . . . , an, b0, b1, . . . , bm〉

non-unitary operations

reset

measure q, m

// example: initialize a qureg

qureg a[6];

qufunct inc(qureg p) { // QCL, 2002, p. 7

int i;

for i=#p-1 to 1 step -1 {

CNot(p[i], p[0:i-1]);

}

Not(p[0]);

}

procedure setto(qureg p, int x) { // initialize p with int val x

int i;

for i = 0 to x-1 {

inc(p);

}

}

reset; dump a;

setto(a, 19); dump a;

/*

result:

: SPECTRUM a: |543210>

1 |000000>

: SPECTRUM a: |543210>

1 |010011>*/

typical evaluation loop:

// QCL, p. 58

{

reset;

myoperator(q);

measure q, m;

} until ok(m);

subroutines [Om00, p. 59]

allowed side-effects:

routine type program state machine state recursion

procedure classical all all yes

operator quantum none unitary no

qufunct quantum none pseudo-classic no

functions classical none none yes

general operators

// QCL operator inversion, p. 60

qureg a[1];dump;

Mix(a);dump;

!Mix(a);dump;

/* result:: STATE: 1 / 4 qubits allocated, 3 / 4 qubits free1 |0000>: STATE: 1 / 4 qubits allocated, 3 / 4 qubits free0.707107 |0000> + 0.707107 |0001>: STATE: 1 / 4 qubits allocated, 3 / 4 qubits free1 |0000>

*/

// example: statistical experiment

int m;int count0;int count1;const total = 30000;qureg q[4];count0 = 0;count1 = 0;{

reset;Mix(q);measure q[0], m;if m == 0 {

count0 = count0 + 1;} else {

count1 = count1 + 1;}

} until count0 + count1 >= total;

print "prob0: ", (count0+0.0)/(count0+count1);print "prob1: ", (count1+0.0)/(count0+count1);

/* result is:: prob0: 0.503367: prob1: 0.496633

*/

unitary gates

• unitary matrices: e. g.

extern operator Matrix2x2(complex u00, complex u10,

complex u10, complex u11,

qureg q);

• qubit rotation:

extern operator Rot(real theta, qureg q);

• Hadamard gate:

extern operator Mix(qureg q);

• conditional phase gate:

extern operator CPhase(real phi, qureg q);

quantum functions

F : |x〉x|0〉y → |x〉x|f (x)〉y with f : Bn → Bm, n,m ∈ N

scratch space management:

Bennet-style “un-computation” [NC00, p. 158]|x, 0, 0, y〉↓ reversible computation of f (x): circuit C

|x, f (x), g(x), y〉↓ apply CNots

|x, f (x), g(x), y ⊕ f (x)〉↓ apply C−1: no effect on 4th register

|x, 0, 0, y ⊕ f (x)〉

pseudo-classic gates

• base permutation: e .g.

extern qufunct Perm2(int p0, int p1, qureg q);

• fanout:

extern qufunc Fanout(quconst a, quvoid b);

• swap:

extern qufunct Swap(qureg a, qureg b);

• not, controlled not:

– extern qufunct Not(qureg q);

– extern qufunct CNot(qureg q, quconst c);

example: teleportation

/*Alice:a[0] --------- ...a[1] --------- ...

Bob:b[0] --------- ...

Nielsen / Chuang, p. 27:teleportation a[0] -> b[0]

*/const i = (0,1); int m0; int m1;qureg a[2]; // Alice’s 2-qubits registerqureg b[1]; // Bob’s 1-qubit registerreal x; // random values, 0 <= x < 1.0

procedure prepare(real x, qureg p){// prepare some example statecomplex u00 = cos(2*pi*x) + i*0;complex u01 = -sin(2*pi*x) + i*0;complex u10 = sin(2*pi*x) + i*0;complex u11 = cos(2*pi*x) + i*0;Matrix2x2(u00, u01, u10, u11, p);// unitary operation

}

operator entangle(qureg p, qureg q){// entangle qubits p and qMix(p);CNot(q, p);

}reset;x = random();prepare(x, a[0]);

print "prepared state: ";dump a[0];

entangle(a[1], b[0]);

!entangle(a[0], a[1]);

measure a[0], m0;measure a[1], m1;

/* Alice to Bob:-----+

//+-----> continued ...

*/

if m1 == 1 {Matrix2x2((0,0), (1,0),

(1,0), (0,0), b[0]); //sigma_x};if m0 == 1 {

Matrix2x2((1,0), (0,0),(0,0), (-1,0), b[0]);//sigma_z

};print "teleported state: ";

dump b[0];

/* result:: prepared state:: SPECTRUM a[0]: |..0>0.370046 |0> + 0.629954 |1>: teleported state:: SPECTRUM b[0]: |0..>0.370046 |0> + 0.629954 |1>

*/

Shor’s algorithm (quantum kernel) [Om00, p. 99]

...{

{ // generate random basex=floor(random() * (number-3)) + 2;

} until gcd(x,number)==1;print "chosen random x =",x;//--------------------------------------------------Mix(reg1); // Hadamard transformexpn(x, number, reg1, reg2); // modular exponentiationmeasure reg2; // measure 2nd registerdft(reg1); // Fourier transformmeasure reg1, m; // measure 1st registerreset; // clear local registers//--------------------------------------------------if m==0 { // failed if measured 0

print "measured zero in 1st register. trying again ...";} else {

...;}...;

}...

Q language (S. Bettelli, L. Serafini, T. Calarco)

General properties

Relevant papers:

• Q language library

• S. Bettelli, L. Serafini, T. Calarco: Toward an architecture for

quantum programming, 2001 [cs.PL.0103009.ps.gz]

general comments:

• Q language: library extension of C++

• quantum operators as objects:

• can be constructed and manipulated at run-time

• run-time optimizations are possible

“Desiderata” for a quantum programming language

. completeness: it must be possible to code every quantum algo-

rithm

. classical extension: the (quantum) language must include a

high level “classical computing paradigm”

. separability: keep classical and quantum programming sepa-

rated

. expressivity: language must provide high level constructs

. hardware independence

Language primitives

• Register handling

1. Register allocation, e. g. Qreg a_register(5);

2. Register addressing and concatenation,

e. g. Qreg a_qubit = a_register[3]

3. Register resizing

4. Register deallocation

• Quantum Operators and their manipulation

1. Identity operator, e. g. Qop my_op;

2. Fixed arity quantum operators,

e. g. Qop my_op = QHadamard(7);

3. Macro quantum operators, e. g. Qop my_op = QFourier(7);

4. Qubit line reordering, e. g. Qop a_swap = QSwap(5);

5. Controlled operators, e. g. Qop a_controlled_op(U, 5);

6. Operators for classical functions,

e. g. Qop an_oracle = Qop(f, 3, 5);

7. Operator composition,

e. g. Qop composed = part_1 & part_2;

8. Operator conjunction, e. g. Qop adj_operator = !an_op;

9. Operator permutations,

e. g. Qop split = an_op(2, 3, SPLIT);

10. Application of an operator, e. g. an_operator(a_register);

• Low level primitives

1. Register initialization and assignment,

e. g. Qreg a_register(5, 3); a_register = 7;

2. Register measurement,

e. g. int val = a_register.measure();

3. Low level unitary gates, cf [NC00]

qGCL (J.W. Sanders and P. Zuliani)

General properties

Relevant papers:

. [SZ00]: Quantum programming

. see also: Paolo Zuliani’s dissertation: Quantum Programming

general comments:

• extension of Edsger Dijkstra’s guarded command language, GCL

• qGCL: expressed in terms of pGCL (probabilistic guarded com-

mand language)

• qGCL: imperative language

• suitable as a specification language (high level mathematical nota-

tion)

• mechanism for stepwise refinement for program derivation and ver-

ification (correctness proof)

• formal (operational) semantics:

pre- and post-conditions are extended to pre- and post-expectations

• includes three high level quantum primitives: state preparation,

evolution, observation

• is universal language

QPL, Block QPL (P. Selinger)

General properties

Relevant paper: see P. Selinger’s home page

[Sel]: Towards a Quantum Programming Language

general comments:

. slogan: “quantum data, classical control”:

. no “quantum branching”

. language is functional

. statically typed: program free of run-time errors

. two alternative representations of quantum programs:

– graphical, flow charts

– textual

. language admits a denotational semantics by assigning a superop-

erator to each program fragment:

. semantics of a quantum flow chart is given as a function from mixed

states to mixed states

. not addressed in the paper: quantum communication

Some additional references related to quantum programming

. [Bla00] (Quantum Computers and Quantum Computer Lan-

guages. Quantum Assembly and Quantum C )

. [Fra02] (Quantum software)

. [Sam02] (Practical State-charts in C/C++)

References

[Bak96a] G. Baker. “Qgol”. A system for simulating quantum computations: Theory, Imple-mentations and Insights. PhD thesis, Macquarie University, 1996. www.

[Bak96b] Greg Baker. Points from my hounors thesis, 1996. www.

[BCS01] S. Bettelli, T. Calarco, and L. Serafini. Toward an architecture for quantum program-ming, 2001. abs.

[Bla00] S. Blaha. Cosmos and Consciousness. 1stBooks Library, Bloomington, IN, 2000. ex-cerpt: Quantum Computers and Quantum Computer Languages. Quantum Assemblyand Quantum C. www.

[Di 00] David P. Di Vincenzo. The physical implementation of quantum computation.Fortschritte der Physik, 48:771–783, 2000. abs.

[EWZ] Matthias Eck, Pawel Wocjan, and Robert Michael Zeier. Quasi. User Documentation.www.

[Fra02] Jaroslaw Francik. Quantum software. Studia Informatica, 23(2A(48)), 2002. www.

[KN01] E.H. Knill and M.A. Nielsen. Theory of quantum computation. Supplement III, Ency-clopaedia of Mathematics, 2001. abs.

[Kni96] Emanuel H. Knill. Conventions for quantum pseudocode, 1996. www.

[Mey90] B. Meyer. Introduction to the Theory of Programming Languages. Prentice-Hall, 1990.

[NC00] Michael A. Nielsen and Isaac L Chuang. Quantum Computation and Quantum Infor-mation. Cambridge University Press, 2000.

[Om98] B. Omer. A procedural formalism for quantum computing. Master’s thesis, TU Wien,1998. www.

[Om00] B. Omer. Quantum programming in QCL. Master’s thesis, TU Wien, 2000. www.

[Om02] B. Omer. Classical concepts in quantum programming, 2002. arXiv: abs.

[Sam02] M. Samek. Practical Statecharts in C/C++. CMPBooks, Lawrence, Kansas, 2002.www.

[Sel] Peter Selinger. Towards a quantum programming language. www.

[Sma] Eric Smalley. Programming goes quantum. www.

[SZ00] J.W. Sanders and P. Zuliani. Quantum programming. In Mathematics of ProgramConstruction, volume 1837 of LNCS, pages 80–99. Springer Verlag, 2000. also: TechnicalReport TR-5-99.

[Wal99] J. Wallace. Quantum computer simulators – a review (version 2.1), 1999. www.

[Zul00] P. Zuliani. Logical reversibility. Technical report, Univ. of Oxford, 2000. TechnicalReport TR-11-00.

[Zul01a] P. Zuliani. Formal reasoning for quantum mechanical nonlocality. Technical report,Univ. of Oxford, 2001. Research Report RR-01-05.

[Zul01b] P. Zuliani. Quantum Programming. PhD thesis, University of Oxford, 2001. www.

—END OF TALK—and thank you for your interest