ProjectQ: An Open Source Software Frameworkfor Quantum ComputingDamian S. Steiger, Thomas Häner, and Matthias Troyer

Institute for Theoretical Physics, ETH Zurich, 8093 Zurich, SwitzerlandJanuary 31, 2018

We introduce ProjectQ, an open sourcesoftware effort for quantum computing.The first release features a compilerframework capable of targeting varioustypes of hardware, a high-performancesimulator with emulation capabilities,and compiler plug-ins for circuit draw-ing and resource estimation. We in-troduce our Python-embedded domain-specific language, present the features,and provide example implementations forquantum algorithms. The frameworkallows testing of quantum algorithmsthrough simulation and enables runningthem on actual quantum hardware usinga back-end connecting to the IBM Quan-tum Experience cloud service. Throughextension mechanisms, users can provideback-ends to further quantum hardware,and scientists working on quantum compi-lation can provide plug-ins for additionalcompilation, optimization, gate synthesis,and layout strategies.

1 Introduction

Quantum computers are a promising candidatefor a technology which is capable of reachingbeyond exascale performance. There has beentremendous progress in recent years and we soonexpect to see quantum computing test beds withtens and hopefully soon hundreds or even thou-sands of qubits. As these test devices get larger,a full software stack for quantum computing isrequired in order to accelerate the developmentof quantum software and hardware, and to liftthe programming of quantum computers fromspecifying individual quantum gates to describ-ing quantum algorithms at higher levels of ab-straction.

The open source effort ProjectQ aims to im-prove the development of practical quantum com-puting in three key areas. First, the develop-ment of new quantum algorithms is acceleratedby allowing to implement them in a high-levellanguage prior to testing them on efficient high-performance simulators and emulators. Second,the modular and extensible design encouragesthe development of improved compilation, opti-mization, gate synthesis and layout modules byquantum computer scientists, since these indi-vidual components can easily be integrated intoProjectQ’s full stack framework, which providestools for testing, debugging, and running quan-tum algorithms. Finally, the back-ends to actualquantum hardware – either open cloud serviceslike the IBM Quantum Experience [1] or propri-etary hardware – allow the execution of quantumalgorithms on changing quantum computer testbeds and prototypes. Compiling high-level quan-tum algorithms to quantum hardware will facili-tate hardware-software co-design by giving feed-back on the performance of algorithms: theoristscan adapt their algorithms to perform better onquantum hardware and experimentalists can tunetheir next generation devices to better supportcommon quantum algorithmic primitives.

We propose to use a device independent high-level language with an intuitive syntax and amodular compiler design, as discussed in Ref. [2].The quantum compiler then transforms the high-level language to hardware instructions, optimiz-ing over all the different intermediate represen-tations of the quantum program, as depicted inFig. 1. Programming quantum algorithms at ahigher level of abstraction results in faster de-velopment thereof, while automatic compilationto low-level instruction sets allows users to com-pile their algorithms to any available back-endby merely changing one line of code. This in-

Accepted in Quantum 2018-01-21, click title to verify 1

arX

iv:1

612.

0809

1v2

[qu

ant-

ph]

29

Jan

2018

qureg = eng.allocate_qureg(3)Entangle | quregMeasure | qureg

!

! !

!

!

"#$%&'()$&*+&,-./(+

0(123$4$3&*+#.%5'.*(+#

!6%)16%$&*+#.%5'.*(+#

!*7/23$4$3'(89*36.*(+

0(123$4$3'(89*36.*(+

Figure 1: High-level picture of what a compiler does: Ittransforms the high-level user code to gate sequencessatisfying the constraints dictated by the targethardware (supported gate set, connectivity, ...) whileoptimizing the circuit. The resulting low-levelinstructions are then translated to, e.g., pulsesequences.

cludes not only the different hardware platforms,but also simulators, emulators, and resource es-timators, which can be used for testing, debug-ging, and benchmarking algorithms. Moreover,our modular compiler approach allows fast adap-tation to new hardware specifications in order tosupport all qubit technologies currently being de-veloped.

Our high-level quantum language is imple-mented as a domain-specific language embeddedin Python; see the following code for an example:

def AddConstant (eng , quint , c):with Compute (eng):

QFT | quint

# addition in the phases :phi_add (quint , c)

Uncompute (eng)

To enable fast prototyping and future exten-sions, the compiler is also implemented in Pythonand makes use of the novel meta functions intro-duced in Ref. [2] in order to produce more efficientcode. Having the entire compiler implementedin Python is sufficient and preferred for currentand near-term quantum test beds, as Python iswidely used and allows for fast prototyping. If

certain compiler components prove to be bottle-necks, they can be moved to a compiled languagesuch as C++ using, e.g., pybind [3]. Thus, Pro-jectQ is able to support both near-term testbedsand future large-scale quantum computers.

As a back-end, ProjectQ integrates a quantumemulator, as first introduced in Ref. [4], allowingto simulate quantum algorithms by taking clas-sical shortcuts and hence obtaining speedups ofseveral orders of magnitude. For the simulationat a low level, we include a new simulator whichoutperforms all other available simulators, includ-ing its predecessor in Ref. [4]. Furthermore, ourcompiler has been tested with actual hardwareand one of our back-ends allows to run quantumalgorithms on the IBM Quantum Experience.

Related work. Several quantum programminglanguages, simulators, and compilers have beenproposed and implemented in various languages.Yet, only a few of them are freely available:Quipper [5], a quantum program compiler im-plemented in Haskell, the ScaffCC compiler [6]based on the LLVM framework, and the LIQUi |〉simulator, which is implemented in F# [7] andonly available as a binary. While all of thesetools are important for the development of quan-tum computing in their own right, they have not(yet) been developed to a complete and unifiedsoftware stack such as ProjectQ, containing themeans to compile, simulate, emulate, and, ulti-mately, run quantum algorithms on actual hard-ware.

Outline. After introducing the ProjectQ frame-work in Sec. 2, we motivate the methodology be-hind it in Sec. 3 using Shor’s algorithm for factor-ing as an example. We then introduce the mainfeatures of our framework, including the high-level language, the compiler, and various back-ends in Sec. 4. Finally, we provide the road mapfor future extensions of the ProjectQ frameworkin Sec. 5, which includes quantum chemistry andmath libraries, support for further hardware andsoftware back-ends, and additional compiler com-ponents.

2 The ProjectQ Framework

ProjectQ is an extensible open source softwareframework for quantum computing, providingclean interfaces for extending and improving itscomponents. ProjectQ is built on four core prin-

Accepted in Quantum 2018-01-21, click title to verify 2

ciples: open & free, simple learning curve, easilyextensible, and high code quality.

Open & free: To encourage wide use, ProjectQis being released as an open source software un-der the Apache 2 license. This is one of the mostpermissive license models and allows, for exam-ple, free commercial use.

Simple learning curve: ProjectQ is imple-mented in Python (supporting both versions 2and 3) because of its simple learning curve.Python is already widely used in the quantumcommunity and easier to learn than C++ or func-tional programming languages. We make use ofhigh-performance code written in C++ for some ofthe computational high performance kernels, buthide them behind a Python interface.

Easily extensible: ProjectQ is easily extensibledue to the modular implementation of both com-piler and back-ends. This allows users to easilyadapt the compiler to support new gates or en-tirely different gate sets as will be shown in a latersection.

High code quality: ProjectQ’s code base fol-lows high industry standards, including manda-tory code-reviews, continuous integration testing(currently 99% line coverage using unit tests inaddition to functional tests), and an extensivecode documentation.

The initial release of ProjectQ, which is de-scribed in this paper, implements powerful corefunctionalities, and we will continue to add newfeatures on a regular basis. We encourage con-tributions to the ProjectQ framework from any-one: Implementations of quantum algorithms,new compiler engines, and interfaces to actualquantum hardware back-ends are welcome. Formore information about contributing see Ref. [8].

3 Quantum Programs and Compila-tion

We motivate the methodology behind ProjectQby presenting an implementation of Shor’s factor-ing algorithm [9] in a high-level language. Then,we show how, using only local optimization andrewriting rules, the automatically generated low-level code can be as efficient as the manually op-timized one in [10], although all subroutines wereimplemented as stand-alone components.

QFT Φadd QFT† QFT Φadd QFT†

Figure 2: Circuit for carrying out two controlled Fouriertransform additions in sequence: An optimizer canidentify the QFT with its inverse, allowing to cancelthose two operations. This identification is muchharder or even impossible after decomposing operationsand synthesizing rotation gates. Furthermore, sinceQFT†QFT = 1, the quantum Fourier transform doesnot need to be controlled, which can be achieved usingour Compute/Uncompute meta-instructions (seeSec. 4.1.3).

At the heart of Shor’s algorithm for fac-toring [9] lies modular exponentiation (of aclassically-known constant by a quantum me-chanical value) which is well-known to be imple-mentable using constant-adders. Given a classicalconstant c, they transform a quantum register |x〉representing the integer x as

|x〉 7→ |x + c〉 .

Out of several implementations [11, 12, 13], wefocus on Draper’s addition in Fourier space [13],due to the large potential for optimization whenexecuting several additions in sequence, whichhappens when using the construction in [10] toachieve modular addition. This constant-adderworks as follows:

1. Apply a quantum Fourier transform (QFT) to|x〉.

2. Apply phase-shift gates to the qubits of |x〉,depending on the bit-representation of theconstant c to add (i.e., the addition is carriedout in the phases).

3. Apply an inverse QFT.

Modular exponentiation can be implemented us-ing repeated modular multiplication and shift,which themselves can be built using controlledmodular adders. Thus, at a lower level, (double-or single-) controlled constant-adders are per-formed. When executing two such controlled ad-ditions in sequence, the resulting circuit can beoptimized significantly. As shown in Fig. 2, the(final) inverse QFT of one addition and the initialQFT of the next one can be canceled. Further-more, some of the (controlled) phase-shift gatesinside Φadd may be merged (depending on thetwo constants to add).

Accepted in Quantum 2018-01-21, click title to verify 3

MainEngine

Optimizer Translator Optimizer . . . MapperBack-endinterface

QuantumProgram

Simulator

Emulator

Hardware

Circuit drawer

Resource est.

Compiler Back-endseDSL in Python

Figure 3: ProjectQ’s full stack software framework. Users write their quantum programs in a high-leveldomain-specific language embedded in Python. The quantum program is then sent to the MainEngine, which isthe front end of the modular compiler. The compiler consists of individual compiler engines which transform thecode to the low-level instruction sets supported by the various back-ends, such as interfaces to quantum hardware,a high-performance quantum simulator and emulator, as well as a circuit drawer and a resource counter.

While the potential for these cancellations andoptimizations is easy to see at this level of ab-straction, carrying out such a cancellation is com-putationally very expensive once all gates havebeen translated to a low-level gate set, and maybe impossible to do after translating into a dis-crete gate set (which introduces approximationerrors). In our compilation framework, we thusdefine several intermediate gate sets. At everysuch intermediate level, inexpensive local opti-mization algorithms can be employed prior to fur-ther translation into the next lower-level repre-sentation.

The ProjectQ compiler is modular and allowsnew compilers to be built by combining existingand new components, as shown in Fig. 3. Thisdesign allows to customize intermediate gate setsto improve optimization for specific algorithmicprimitives. It also allows to adapt the compila-tion process to different quantum hardware ar-chitectures by replacing just some of the com-piler engines (including hardware-specific map-pers), which maximizes the re-use of individualcompiler components.

4 Features

In this section we will introduce the main featuresof ProjectQ, starting with a minimal example:

1 from projectq import MainEngine2 from projectq .ops import H, Measure3

4 eng = MainEngine ()5 qubit1 = eng. allocate_qubit ()6 H | qubit17 Measure | qubit18 print (int( qubit1 ))

This minimal code example allocates one qubit

in state |0〉 and applies a Hadamard gate be-fore measuring it in the computational basis andprinting the outcome. While this is a valid quan-tum program implementing a random numbergenerator, a more pythonic and better designedversion is shown in code example 1.Line 1 imports the MainEngine class, which isthe front end of the quantum compiler as shownin Fig. 3. Every quantum program needs to cre-ate one MainEngine, which contains all compilercomponents (engines) as well as the back-end (seeline 4). In section 4.2 we show how to select com-piler engines and the back-ends. If a MainEngineis created without any arguments as done here,the default compiler engines are used with a sim-ulator back-end.

Every quantum algorithm operates onqubits, which are obtained by calling theallocate_qubit function of the MainEngine.To apply a Hadamard gate and then measure,we first need to import these gates in line 2 andapply them to the qubit in lines 6 and 7. Thesyntax for applying a quantum gate to a qubitmimics an operator notation. For example,

Rx(0.5) | qubit 〉 , (1)

might indicate a rotation around the x-axis ap-plied to a qubit. In ProjectQ, this is coded as:

Rx (0.5) | qubit

The symbol | separates the gate operation withoptional classical arguments (e.g., rotation an-gles) on the left from its quantum arguments onthe right (the qubits to which the gate is beingapplied).

Finally, on line 8, qubit1 is converted to anint. This conversion operation returns the mea-surement result from line 7 which is then printed.

Accepted in Quantum 2018-01-21, click title to verify 4

1 import projectq . setups . default ← # explicitly import defaultdecompositions

2 from projectq import MainEngine ← # import the main compiler engine3 from projectq .ops import H, Measure ← # import the required operations4

5 def my_rng (eng): ← # Python function definition6 qubit1 = eng. allocate_qubit () ← # allocate qubit17 H | qubit1 ← # apply a Hadamard gate to qubit18 Measure | qubit1 ← # measure qubit19 eng.flush () ← # force - execute all gates

10 return int( qubit1 ) ← # access measurement result (conversion to int)

11

12 if __name__ == " __main__ ": ← # only executes if this is main13 eng = MainEngine () ← # create a main compiler engine14 print(" Result : {}". format ( my_rng (eng))) ← # call my_rng (eng) and print the

result

Code Example 1: Code example for implementing a quantum random number generator in ourPython-embedded domain-specific language.

4.1 High level quantum language

4.1.1 The basic (quantum) types

The fundamental types of our high level quan-tum language are logical qubits from whichmore complex types can built: quantum integers(quint), quantum fixed point numbers (qufixed)and quantum floats (qufloat). Similar to theirclassical counterparts, these types are just differ-ent interpretations of the contents of an underly-ing list of quantum bits, i.e., a quantum registeror qureg.

To acquire an instance of an n-qubit quantumregister, the function allocate_qureg(n) of theMainEngine has to be invoked with the numberof qubits as a parameter, as in the following codesnippet:

...eng = MainEngine ()...qureg = eng. allocate_qureg (n)

The function allocate_qubit() returns a quan-tum register of length one, which is a single qubit.Qubits can be allocated at any point in the pro-gram, which keeps the user from having to specifya-priori the maximum number of qubits needed inany part of the code.

ProjectQ’s compiler takes care of automaticdeallocation of qubits by exploiting Python’sgarbage collection, thus allowing qubit re-use.While not necessary, the user can still force deal-

location by invoking Python’s del statement. Inaddition to removing the burden of resource man-agement from the user, letting the compiler han-dle the life-time of qubits allows automatic par-allelization for back-ends featuring more qubitsthan the minimal circuit width. The simulatorcan be used as a debugging tool to validate un-compute sections since it throws an exceptionwhenever a qubit in superposition is being deal-located. Thus, qubits have to be either measuredor uncomputed prior to deallocation.

Certain subroutines such as the multi-controlled NOT construction by Barenco etal. [14] or the constant-addition circuit by Häneret al. [12] do not require clean ancilla qubits ina defined computational basis state (such as |0〉)but work with borrowed qubits in an unknownarbitrary quantum state. They guarantee thatafter completion of the circuit, these so-calleddirty ancilla qubits have returned to their startingstate. Our compiler can thus optimize the alloca-tion of such ancilla qubits by simply providing aqubit which is currently unused, independent ofits state:

qubit = eng. allocate_qubit (dirty=True)

4.1.2 Quantum gates and functions

Operations on quantum data types can be imple-mented either as normal Python functions or asProjectQ gates. A Python function implement-

Accepted in Quantum 2018-01-21, click title to verify 5

ing such an operation applies other gates or func-tions, as shown in this example of an addition bya constant:

def add_constant (quint , c):QFT | quint

# addition in the phases :phi_add (quint , c)

get_inverse (QFT) | quint

which can then be called as

add_constant (my_quint , 11)

The second approach is to define a custom Pro-jectQ gate representing the entire operation andthen registering a decomposition rule, i.e., pro-viding one possible function which can be usedto replace the newly defined gate:

class AddConstant ( BasicGate ):def __init__ (self , c):

self.c = c # store constant to add

# provide one possible decomposition :register_decomposition ( AddConstant ,

add_constant_decomposition1 )

This enables the usual syntax for quantum gates,namely:

AddConstant (11) | my_quint

where the constant to add (11 in this case) isstored within the AddConstant gate object.

While defining a custom gate involves morecode, it is superior to a function-based implemen-tation and results in cleaner user code. The gate-based approach allows optimizations at a higherlevel of abstraction since the function call exe-cutes the individual operations right away, thusremoving the potential of optimizing at the high-est level. In our example, defining the constant-adder as a gate allows merging two consecutiveAddConstant gates by adding the respective con-stants. This is much harder in the function-basedimplementation, where the highest level of ab-straction which the compiler receives is at thelevel of QFT and phase-shift gates.

Another advantage of implementing a newquantum operation, such as AddConstant, as anew ProjectQ gate is that different specializeddecomposition rules can be defined from which

the compiler can then choose the best one forthe target back-end by evaluating a user-definedcost function. Furthermore, if the back-end na-tively supports certain gate operations, such asa many-qubit Mølmer-Sørensen gate [15] on iontrap quantum computers, the decomposition stepmay be skipped altogether. The AddConstantgate is also natively supported in our quantumemulator, which allows faster execution by ordersof magnitude compared to simulating the individ-ual gates of its implementation [4].

Most generally, the quantum input to anygate is a tuple of quantum types (qubit, qureg,quint,...), which allows the following intuitivesyntax for a Multiply instruction:

Multiply | (quint_a , quint_b , res)

4.1.3 Meta-instructions

At an even higher level of abstraction, complexgate operations can be modified using so-calledmeta-instructions. These facilitate optimizationprocesses in the compiler while allowing the userto write more concise code.

All of these meta-instructions are implementedusing the Python context-handler syntax, i.e.,

with MetaInstructionObject :......

where MetaInstructionObject is one of the fol-lowing:

• Control(eng, control_qubits): Condi-tion an entire code block on one or severalqubits being in state |1〉.

• Compute(eng)/CustomUncompute(eng):Annotate compute / uncompute sections asdepicted in Fig. 4. This allows to optimizethe conditional execution of such sectionsas discussed in Ref. [2]. For an automaticuncompute, simply run the Uncompute(eng)function.

• Dagger(eng): Invert an entire unitary codeblock (hence the name: U †U = 1).

Accepted in Quantum 2018-01-21, click title to verify 6

U V U†

︸ ︷︷ ︸compute

︸ ︷︷ ︸action

︸ ︷︷ ︸uncompute

Figure 4: A compute/action/uncompute section. SinceU†U = 1, the U and U† gate can be executedunconditionally when control qubits are added to anoperation of this form. These sections can beannotated using our Compute, Uncompute, andCustomUncompute meta-instructions, see Sec. 4.1.3.

• Loop(eng, num_iterations): Run a codeblock num_iterations times. Back-ends na-tively supporting loop instructions will re-ceive the loop body only once, whereas theloop is unrolled otherwise. Some hardwareplatforms exploit this by re-using the gener-ated waveforms.

For an example employing some of these meta-instructions to arrive at the performance-level ofhand-optimized code, see our implementation ofShor’s algorithm for factoring in the Appendix.

Any quantum program implemented in oureDSL concludes with the statement

eng.flush ()

which makes sure that the entire circuit haspassed through all compiler engines and is re-ceived by the back-end.

4.2 Compiler and compiler engines

Our compiler is not a monolithic block, but has amodular design, allowing fast adaptation to newhardware while optimally re-using existing com-ponents. The compiler MainEngine serves as thefront-end of the quantum compiler and consistsof a chain of compiler engines, each carrying outone specific task. This chain can be customizedby the user. The most trivial compiler consistsof one translation engine called AutoReplacer,which decomposes a quantum circuit into the na-tive gate set of the back-end using the registereddecomposition rules (see section 4.1). Such acompiler can be instantiated as follows:

eng = MainEngine ( engine_list =[AutoReplacer ()])

Yet, as discussed in the previous section, op-timizing at different levels of abstraction allowsfor more efficient code. Introducing multiple in-termediate levels can be achieved using severaltranslators, optimizers, and instruction filter en-gines, which define the set of supported gates ateach level:

eng = MainEngine ( engine_list =[AutoReplacer (),InstructionFilter (intermediate_gate_set ),LocalOptimizer (),AutoReplacer (),LocalOptimizer ()])

As quantum operations propagate through thiscompilation chain, the AutoReplacer engines de-compose all instructions into the gate set de-fined by the next engine, which is, e.g., anInstructionFilter. The last engine is alwaysthe back-end, which defines the gate set at thelowest level. For example, an intermediate gateset supporting high-level QFT gates allows theoptimization mentioned in Sec. 3 easily: consec-utive (controlled) additions in Fourier space canbe executed more efficiently by canceling a QFTwith its inverse.

Once suitable compiler engines and decompo-sition rules have been determined for a specificback-end, those can be saved as a setup for fu-ture use.

Unlike other quantum compiler designs, ourcompiler does not store the entire quantum cir-cuit which, given the vast number of logical gatesrequired for some quantum algorithms, wouldnot be feasible due to memory requirements.Instead, every compiler engine can define howmany gates it stores. While, for example, anAutoReplacer works on only one gate at a time,a LocalOptimizer saves a short sequence of gatesbefore trying to optimize them. This locality ofcompilation allows to parallelize the compilationprocess in a straight-forward manner.

4.3 Back-endsOur compiler supports a wide range of back-endsto

• run circuits on quantum hardware,

• simulate the individual gates of a quantumcircuit

• emulate the action of a quantum circuit byemploying high-level shortcuts

Accepted in Quantum 2018-01-21, click title to verify 7

• estimate the required resources

• draw a quantum circuit

The default simulation back-end can be changedby specifying the backend-parameter. To targetthe IBM Quantum Experience back-end instead,one simply writes

eng = MainEngine ( backend = IBMBackend ())

4.3.1 Hardware back-end: IBM quantum experi-ence

ProjectQ comes with a hardware backend for theIBM Quantum Experience device [1]. As an ex-ample program, consider entangling 3 qubits byfirst allocating 3 qubits in a quantum register,then applying the Entangle-operation to them,and finally measuring the quantum register:

qureg = eng. allocate_qureg (3)Entangle | quregMeasure | quregeng.flush ()

The compiler replaces the Entangle gate by aHadamard gate on the first qubit, followed byCNOT gates on all others conditioned on the firstqubit (see Fig. 5 a)). The compiler then automat-ically flips CNOT gates where necessary (using 4Hadamard gates), to make the code compatiblewith the connectivity of the IBM quantum chip(see Fig. 5 b)). In Fig. 5 c), the circuit is opti-mized before the final mapping to physical qubitsis performed in Fig. 5 d). Running this circuityields the outcomes with their respective proba-bilities in Fig. 6.

4.3.2 Simulation of quantum circuits

Simulating quantum programs at the level of in-dividual gates can be achieved using our high-performance quantum simulator. The concretegate set to be used can be specified by the user.The current version of the simulator in ProjectQsupports AVX instructions and OpenMP threads.Our simulator is substantially faster than the onewe recently presented in Ref. [4], which alreadyoutperfomed all other existing quantum simula-tors, see Fig. 7.

The simulation of quantum circuits at the levelof gates is especially useful to simulate the ef-

fects of noise. We are working on the imple-mentation of stochastic noise models and a high-performance density matrix simulator.

4.3.3 Emulation of quantum circuits

For efficient testing of quantum algorithms at ahigh level of abstraction, our simulator providesquantum emulation features as well: By speci-fying the level of abstraction at which to emu-late (using, e.g., an InstructionFilter and anAutoReplacer, see Sec. 4.2), these features canbe enabled or disabled. As an example, con-sider our AddConstant gate from Sec. 4.1: With asmall modification to the gate definition, the ad-dition can be carried out directly, without hav-ing to decompose it into QFT and phase-shiftgates (and then further into 1- and 2-qubit gatesonly). Gates which execute classical mathemat-ical functions on a superposition of values canderive from BasicMathGate and then provide aPython function mimicking this behavior in the__init__ function of the AddConstant gate, i.e.,

BasicMathGate . __init__ (self ,lambda x: return x + c)

Such shortcuts allow faster execution by ordersof magnitude, especially if potential low-level im-plementations require many ancilla qubits to per-form the computation. These extra qubits donot need to be simulated when using this kindof shortcut, which allows to factor the number

4, 028, 033 = 2, 003 · 2, 011

on a regular laptop in less than 3 minutes.The emulation of quantum circuits is very use-

ful for determining mesh-sizes, time steps/slices,and other high-level parameters for, e.g., quan-tum chemistry applications [16], which requiremany mathematical functions such as arcsin(x),exp(x), 1√

x, etc., to be evaluated on a superpo-

sition of values. The ProjectQ emulation featurethen allows to perform numerical studies usingthe same code that was used to obtain resourceestimates; and this can be achieved by merelychanging one line of code.

4.3.4 Resource estimation

The ResourceCounter back-end can be insertedat any point in the compiler chain. There, it

Accepted in Quantum 2018-01-21, click title to verify 8

|0〉

|0〉

|0〉

H

(a) After decomposing.

−→

|0〉

|0〉

|0〉

H H

H H

H H

H H

H

(b) After CNOT mapping.

−→

|0〉

|0〉

|0〉

H

H H

H

H

(c) After optimization.

−→

|0〉

|0〉

|0〉

H

H H

H

H

(d) After mapping to hardware.

Figure 5: Individual stages of compiling an entangling operation for the IBM back-end. The high-level Entangle-gateis decomposed into its definition (Hadamard gate on the first qubit, followed by a sequence of controlled NOT gateson all other qubits). Then, the CNOT gates are remapped to satisfy the logical constraint that controlled NOTgates are allowed to act on one qubit only, followed by optimizing and mapping the circuit to the actual hardware.

0

0.1

0.2

0.3

0.4

0.5

000 001 010 011 100 101 110 111

Prob

abili

ty

Measurement outcome

IBM QE chipIBM QE Simulator

Figure 6: Measurement outcomes with their respectiveprobabilities when running an entangle operation onthree qubits of the IBM Quantum Experience chip andsimulator. The entangle operation corresponds toapplying a Hadamard gate to the first qubit, followedby CNOT gates on all other qubits conditioned on thefirst qubit. The perfect outcome would be 50%all-zeros and 50% all-ones, as it is the case for the(noise-less) simulation.

keeps track of all gates it encounters and mea-sures the maximal circuit width at that level aswell. In order to get resource estimates for verylarge circuits, caching must be introduced at ev-ery intermediate layer / gate set. This featurewill be added in the near future.

4.3.5 Circuit drawing back-end

Last but not least, all quantum programs canbe drawn as circuit diagrams for publication in,e.g., an algorithmic paper. The CircuitDrawerback-end saves the circuit and, upon invocation ofthe get_latex() member function, returns TikZ-LATEXcode ready to be published. See Fig. 8 foran example output depicting quantum telepor-tation (including the initial creation of a Bell-pair). Just like the simulator or resource counter,this back-end can also be used as an intermedi-

0.001

0.01

0.1

1

15 16 17 18 19 20 21 22

Tim

epe

rru

n[s

]

Number of qubits

3

4

5

15 16 17 18 19 20 21 22

Speedup

Simulator in [4]ProjectQ simulator

Figure 7: Runtime comparison of the simulator from [4]to the simulator in ProjectQ. The timed circuit consistsa Hadamard-transform, a chain of controlledz-rotations, and a final Hadamard transform. The lazyevaluation of gates in combination with intrinsicsinstructions allows the ProjectQ simulator to executethis circuit between 3 and 5 times faster. Bothsimulators were run on both cores of an Intel R© CoreTM

i7-5600U CPU.

ate compiler engine in order to draw the circuitat various levels of abstraction (which was doneto create Fig. 5). This back-end will also be ex-tended with further features in future versions ofProjectQ, giving the user yet more power over themapping & drawing process.

5 Road mapIn order to widen the scope of available tools,we will be extending ProjectQ on a regular basiswith libraries, additional compiler engines, andmore hardware back-ends.

5.1 Librariesfermilib. Solving problems involving strongly in-teracting fermions is one of the most promis-ing applications for near-term quantum devices.

Accepted in Quantum 2018-01-21, click title to verify 9

|ψ〉

|0〉A H

|0〉B

H

Z |ψ〉

Figure 8: Quantum circuit for quantum teleportation.This circuit was automatically generated (modulorenaming of the qubits).

With external collaborators we are implementingfermilib [17], a library for designing quantumsimulation algorithms to treat fermionic systems.fermilib will include integration with opensource electronic structure packages to enable thecomputation of arbitrary molecular Hamiltoni-ans. A well-engineered Python interface will al-low for efficient manipulation of fermionic datastructures with routines enabling normal order-ing, fast orbital transformations, mapping qubitalgebras, and more. In addition, it will providetools to study fermionic systems beyond chem-istry, including models for superconductivity suchas the Hubbard model.

mathlib. While our emulator can use classicalshortcuts to mimic the application of generalmathematical functions, manually-tuned high-performance implementations of those functionsat the level of, e.g., Toffoli gates are still requiredin order to get resource estimates or, at a laterpoint in time, run those algorithms on real quan-tum hardware. We will thus further extend the(small) existing math library in ProjectQ withadditional high-level quantum types (as discussedin Sec. 4.1) and corresponding operations.

5.2 Back-ends

We are working on adding support for furtherhardware back-ends. Among others, we aim tohave an interface to J. Home’s ion trap devices[18] in the near future. More hardware back-endswill follow soon. Hardware groups interested ininterfacing to ProjectQ are highly encouraged tocontact us [8].

Also, we will keep extending and improving ourclassical back-ends. We are currently working onincluding our distributed massively parallel quan-tum simulator [19], which allows to simulate upto 45 qubits on one of the world’s largest super-

computers.

5.3 Compiler extensions

New compiler engines will be added, allowingto deal with more advanced layouting, whichis required to employ quantum error-correctionschemes. This is crucial not only to run largecircuits on future hardware, but also to gain in-formation about resource usage before large-scalequantum computers are available.

AcknowledgmentsSpecial thanks go to the researchers from IBM,Lev S. Bishop, Fran Cabrera, Jorge Carballo,Jerry M. Chow, Andrew W. Cross, Ismael Faro,Stefan Filipp, Jay M. Gambetta, Paco Martin,Nikolaj Moll, Mark Ritter, and John Smolin fortheir help with interfacing to the IBM QuantumExperience chip.

We thank Jonathan Home, Matteo Marinelli,and Vlad Negnevitsky for working with us on aninterface to their ion trap quantum computer.

Furthermore, we want to thank the follow-ing people for enlightening discussions: JanaDarulová, Michele Dolfi, Dominik Gresch, An-dreas Hehn, Mario Könz, Natalie Pearson, Don-jan Rodic, Slava Savenko, Andreas Wallraff,and Camillo Zapata Ocampo from ETH Zurich;Matthew Neeley, Daniel Sank, and HartmutNeven from Google Quantum AI; Alan Geller,Martin Roetteler, Krysta Svore, Dave Wecker,and Nathan Wiebe from Microsoft Research; andAnne Matsuura and Mikhail Smelyanskiy fromIntel.

We would also like to thank Ryan Babbush,Jarrod McClean, and Ian D. Kivlichan for collab-orating with us on fermilib.

We acknowledge support by the Swiss NationalScience Foundation and the Swiss National Com-petence Center for Research, QSIT.

References[1] IBM Quantum Experience. http://

research.ibm.com/quantum/.[2] Thomas Häner, Damian S. Steiger, Krysta

Svore, and Matthias Troyer. A softwaremethodology for compiling quantum pro-grams. Quantum Science and Technology,

Accepted in Quantum 2018-01-21, click title to verify 10

2018. DOI: https://doi.org/10.1088/2058-9565/aaa5cc.

[3] pybind. https://github.com/pybind.[4] Thomas Häner, Damian S. Steiger, Mikhail

Smelyanskiy, and Matthias Troyer. Highperformance emulation of quantum circuits.In Proceedings of the International Con-ference for High Performance Computing,Networking, Storage and Analysis, SC ’16,pages 74:1–74:9, Piscataway, NJ, USA, 2016.IEEE Press. ISBN 978-1-4673-8815-3. DOI:10.1109/SC.2016.73.

[5] Alexander S. Green, Peter LeFanu Lums-daine, Neil J. Ross, Peter Selinger, andBenoît Valiron. Quipper: a scalable quan-tum programming language. In ACM SIG-PLAN Notices, volume 48, pages 333–342.ACM, 2013. DOI: 10.1145/2499370.2462177.

[6] Ali JavadiAbhari, Shruti Patil, DanielKudrow, Jeff Heckey, Alexey Lvov, Fred-eric T. Chong, and Margaret Martonosi.Scaffcc: a framework for compilation andanalysis of quantum computing programs. InProceedings of the 11th ACM Conference onComputing Frontiers, page 1. ACM, 2014.DOI: 10.1145/2597917.2597939.

[7] Dave Wecker and Krysta M. Svore. LIQUi |〉:A software design architecture and domain-specific language for quantum computing.arXiv preprint arXiv:1402.4467, 2014.

[8] ProjectQ website. www.projectq.ch.[9] Peter W. Shor. Algorithms for quantum

computation: Discrete logarithms and fac-toring. In Foundations of Computer Sci-ence, 1994 Proceedings., 35th Annual Sym-posium on, pages 124–134. IEEE, 1994. DOI:10.1109/SFCS.1994.365700.

[10] Stephane Beauregard. Circuit for shor’s al-gorithm using 2n+ 3 qubits. Quantum In-formation and Computation, 3(2):175–185,2003.

[11] Yasuhiro Takahashi, Seiichiro Tani, andNoboru Kunihiro. Quantum addition cir-cuits and unbounded fan-out. QuantumInformation and Computation, 10(9&10):0872–0890, 2010.

[12] Thomas Häner, Martin Roetteler, andKrysta M. Svore. Factoring using 2n+2qubits with Toffoli based modular multipli-cation. Quantum Information and Com-

putation, 17(7&8):0673–0684, 2017. DOI:10.26421/QIC17.7-8.

[13] Thomas G. Draper. Addition on a quantumcomputer. arXiv preprint quant-ph/0008033,2000.

[14] Adriano Barenco, Charles H. Bennett,Richard Cleve, David P. DiVincenzo, Nor-man Margolus, Peter Shor, Tycho Sleator,John A. Smolin, and Harald Weinfurter. El-ementary gates for quantum computation.Physical Review A, 52(5):3457, 1995. DOI:10.1103/PhysRevA.52.3457.

[15] Anders Sørensen and Klaus Mølmer. Quan-tum computation with ions in thermal mo-tion. Physical Review Letters, 82(9):1971,1999. DOI: 10.1103/PhysRevLett.82.1971.

[16] Ryan Babbush, Dominic W. Berry, Ian D.Kivlichan, Annie Y. Wei, Peter J. Love,and Alán Aspuru-Guzik. Exponentiallymore precise quantum simulation of fermionsin second quantization. New Journalof Physics, 18(3):033032, 2016. DOI:10.1088/1367-2630/18/3/033032.

[17] Fermilib. https://github.com/projectq-framework/fermilib.

[18] Ludwig E. de Clercq, Hsiang-Yu Lo, Mat-teo Marinelli, David Nadlinger, Robin Os-wald, Vlad Negnevitsky, Daniel Kienzler,Ben Keitch, and Jonathan P. Home. Par-allel transport quantum logic gates withtrapped ions. Physical Review Letters,116(8):080502, 2016. DOI: 10.1103/Phys-RevLett.116.080502.

[19] Thomas Häner and Damian S. Steiger. 0.5petabyte simulation of a 45-qubit quantumcircuit. In Proceedings of the InternationalConference for High Performance Comput-ing, Networking, Storage and Analysis, SC’17, pages 33:1–33:10, New York, NY, USA,2017. ACM. ISBN 978-1-4503-5114-0. DOI:10.1145/3126908.3126947.

[20] Lov K. Grover. A fast quantum me-chanical algorithm for database search.In Proceedings of the twenty-eighth annualACM Symposium on Theory of Comput-ing, pages 212–219. ACM, 1996. DOI:10.1145/237814.237866.

Accepted in Quantum 2018-01-21, click title to verify 11

A Examples

In this section, we will discuss complete exam-ples, which are also included with the ProjectQsources.

A.1 Quantum Teleportation

Quantum teleportation can be implemented asfollows:

# allocate 2 qubits and turn them intoa Bell -pair ( entangle them)

b1 = eng. allocate_qubit ()b2 = eng. allocate_qubit ()H | b1CNOT | (b1 , b2)

# Alice creates a nice state to sendpsi = eng. allocate_qubit ()create_state (psi)

# entangle it with Alice ’s b1CNOT | (psi , b1)

# measure two values (once in Hadamardbasis) and send the bits to Bob

H | psiMeasure | (psi , b1)print (" Message : {}". format ([ int(psi),

int(b1)])

# Bob may have to apply up to twooperation depending on the messagesent by Alice:

with Control (eng , b1):X | b2

with Control (eng , psi):Z | b2

# done.

When using the CircuitDrawer back-end, i.e.,

eng = MainEngine ( CircuitDrawer ())

the quantum circuit depicted in Fig. 8 is gener-ated.

A.2 Grover search

Grover’s search algorithm [20] achieves aquadratic speedup for finding an element e, givena function

f(x) ={

1, x = e0, x 6= e

It requires two quantum oracles to be imple-mented; one is Uf , which marks the element e

by adding a phase of −1 to the quantum state:

Uf |x〉 = |x〉 , x 6= e

Uf |e〉 = − |e〉

and the other oracle is a reflection across the uni-form superposition. These two operators are thenapplied iteratively π

√N

4 times, where N is thenumber of potential inputs to the function.

An example implementation of this algorithmwith e = 1010...1012 (the binary representationof the solution is alternating) is available in theexamples folder of the ProjectQ framework. Theloop performing the two reflections looks as fol-lows:

# run num_it iterationswith Loop(eng , num_it ):

# adds a (-1)-phase to the solutionoracle (eng , x, oracle_out )

# reflection across uniformsuperposition :

# map uniform superposition to all -ones

with Compute (eng):All(H) | xAll(X) | x

# phase -flip for all -ones:with Control (eng , x[0: -1]):

Z | x[-1]# undo mappingUncompute (eng)

Where the Loop meta-instruction does not unrollthe loop if the underlying hardware or furthercompiler engines support the execution or opti-mization of loops.

Accepted in Quantum 2018-01-21, click title to verify 12

A.3 Shor’s algorithm for factoringOur eDSL allows the user to implement morecomplex functions nicely while keeping the ef-ficiency of the resulting code at the level of ahand-optimized implementation. As an example,consider the modular adder proposed by Beaure-gard [10], which can be implemented using ourpowerful meta-instructions:

def add_constant_modN (eng , c, N, quint):

assert (c < N and c >= 0)

AddConstant (c) | quint

with Compute (eng):SubConstant (N) | quintancilla = eng. allocate_qubit ()CNOT | (quint [-1], ancilla )with Control (eng , ancilla ):

AddConstant (N) | quint

SubConstant (c) | quint

with CustomUncompute (eng):X | quint [-1]CNOT | (quint [-1], ancilla )X | quint [-1]del ancilla

AddConstant (c) | quint

A complete implementation of Shor’s algorithmis also available in the examples folder of Pro-jectQ. Using the quantum math library, an im-plementation of this algorithm takes only a fewlines. The iterative modular multiplication andshift, which is used to implement the modularexponentiation of a by a 2n bit quantum numberx in a uniform superposition looks as follows:

# do each of the bits of x separately ,employing the semi - classicalinverse QFT

ctrl_qubit = eng. allocate_qubit ()

# loop over all 2n bitsfor k in range (2 * n):

# shift the a we multiply bycurrent_a = pow(a, 1 << (2 * n - 1 -

k), N)

# x is in uniform superposition :H | ctrl_qubit

# apply controlled modularmultiplication

with Control (eng , ctrl_qubit ):MultiplyByConstantModN (current_a , N

) | x

# perform inverse QFT -> Rotationsconditioned on previous outcomes

for i in range (k):if measurements [i]:

R(-math.pi /(1 << (k - i))) |ctrl_qubit

# final Hadamard of the inverse QFTH | ctrl_qubit

# and measureMeasure | ctrl_qubiteng.flush ()

# store the measurement resultmeasurements [k] = int( ctrl_qubit )

# and reset the qubit for the nextiteration

if measurements [k]:X | ctrl_qubit

Accepted in Quantum 2018-01-21, click title to verify 13