Systems and Methods for Unified Computing on Digital Computers and Quantum Computers

Abstract

A computer system and method are provided for compiling a computer program for execution on a quantum processor including multiple qubit qudits. A unified-level module of the compiler receives a program in a unified language, performs code refactoring on all or a portion of the program to form refactored code, and transforms the refactored code into a first code. A high-level module compiles the first code into a second code. The high-level module supports loops, subroutines, and flow control instructions in the first code. A low-level module receives the second code and transforms the second code into a third code including a sequence of quantum gate-level operations. A gate-level module compiles the third code into a fourth code expressed in a quantum gate-level language according to the instruction set and gate locality constraints of the target quantum processor.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Provisional Patent Application No. 62 / 945,434, filed on December 9, 2019, entitled "Systems and Methods for Unified Computing on Digital and Quantum Computers", which is hereby incorporated by reference in its entirety.

[0002] The present disclosure generally relates to systems and methods for providing a unified language that can be compiled and executed on either a classical processor or a quantum processor.

Background Art

[0003] Quantum computing requires considering the architecture of quantum computers, which is different from classical computers. What is needed in the art is a computing approach in which source code written in a unified computing language is compiled to be executed on a quantum computer and / or a conventional digital computer.

Summary of the Invention

[0004] The present disclosure addresses the above - mentioned drawbacks by introducing a quantum compiler that compiles source code written in a unified computing language so that it can be executed on a quantum computer and / or a conventional digital computer.

[0005] One aspect of the present disclosure provides a computer system for compiling a computer program executable on a target quantum computer, including a plurality of qubits and / or a digital computer. The computer system includes one or more processors, a memory, and one or more programs in the form of a compiler. The compiler includes a unified level module that obtains a computer program written in a unified language (e.g., carbon).

[0006] When configured to generate code executable on a digital computer rather than a target quantum computer, the unified level module converts the computer program written in the unified language into source code (e.g., in the form of Matlab, Octave C, C++, Fortran, etc.) that can be directly compiled or interpreted for a digital computer using conventional tools.

[0007] When configured to generate code executable on a quantum computer, the unified level module performs code refactoring on all or part of the computer program and converts the refactored code into a first code in a high-level quantum language (e.g., beryllium). In some embodiments, this is achieved by first replacing some combinations of loops and other programming structures in the refactored code with calls to special functions that produce the same output, which can be accelerated using some combinations of classical and quantum processing. Also, in some embodiments, operations on abstract data types in the unified level code are implemented using quantum data structures and quantum algorithms.

[0008] The first code in the high-level quantum language replaces the computer program written in the unified language. The high-level quantum language supports function, loop, recursion, pointer, data structure (structure), and object (class) definitions. Through the lowering of the compiler, these operations are decomposed into simpler operations until the code is composed of individual gate operations.

[0009] The compiler further includes a high-level module that receives the first code, either alone or together with additional source code in a high-level language, and the high-level module implements functions and data types used by the unified-level source code and generates a second code in a low-level quantum language (Helium) that enables loops, subroutines, and flow control instructions. The compiler further includes a low-level module that receives the second code, optionally optimizes the code to improve performance, and converts the second code into a series of gate-level operations, thereby forming a third code. The compiler further includes a gate-level module that compiles the third code into a fourth code and optionally implements error mitigation procedures and gate synthesis, and the fourth code is represented in a quantum gate-level language according to the constraints of the instruction set of the target quantum computer and the gate locality constraints.

[0010] Another aspect of the present disclosure provides a digital computer system for compiling a computer program of a target quantum processor that includes a plurality of qubits or a plurality of quantum dits. The computer system includes one or more digital processors, memory, and one or more programs in the form of a compiler. The compiler obtains a computer program written in a unified language (e.g., carbon), and performs code refactoring on all or a part of the computer program to form refactored code, and converts the refactored code into a first code (beryllium). The compiler further includes a high-level module that compiles the first code (beryllium) into a second code (helium). The high-level module supports loops, subroutines, and flow control instructions within the first code. The compiler further includes a low-level module that receives the second code (helium) and converts the second code into a third code (hydrogen) that includes a series of quantum gate-level operations. The compiler further includes a gate-level module that compiles the third code (hydrogen) into a fourth code represented in a quantum gate-level language according to the instruction set and gate locality constraints of the target quantum processor.

[0011] In some embodiments, the unified-level module performs code refactoring by replacing a source loop in a computer program written in a unified language with a plurality of loops that collectively perform the result of the source loop, and the complexity (e.g., the number of instructions) of each loop of the plurality of loops is less than the complexity of the source loop.

[0012] In some embodiments, the unified-level module performs code refactoring by replacing a source loop in a computer program written in a unified language with a plurality of loops that collectively perform the result of the source loop, and the complexity (e.g., the number of instructions) of each loop of the plurality of loops is less than the complexity of the source loop.

[0013] In some embodiments, the unified level module performs code refactoring by analytically resolving source loops within a computer program described in a unified language.

[0014] In some embodiments, the unified level module performs code refactoring by replacing loops among a plurality of loops with quantum data structures.

[0015] In some embodiments, the unified level module performs code refactoring by encoding a portion of a computer program described in a unified language and executing a quantum algorithm that executes the function of the portion of the computer program. In some such embodiments, the quantum algorithm is an amplitude amplification quantum algorithm.

[0016] In some embodiments, the high-level module provides utilization of quantum gate level commands specified in a first code and supports pointers, functions, unrollable loops, recursions, pointers, data structure definitions, and class object definitions located within the first code that are encoded with qubits among a plurality of qubits or with quantum dits among a plurality of quantum dits.

[0017] In some embodiments, the first code defines a quantum data structure. In some such embodiments, the quantum data structure is a graph set.

[0018] In some embodiments, the unified language is limited to digital instructions.

[0019] In some embodiments, the second code is described in a gate-level language extended with conditional statements, and the second code includes conditional statements. In some such embodiments, the conditional statement is an "if" condition or a "repeat" condition in which an action is repeated until a predetermined condition is met. In some such embodiments, the predetermined condition is the classical measurement result of one or more qubits or quantum dits defined by the second code.

[0020] In some embodiments, the gate-level language is extended with support for subroutines in which a portion of the second code is repeatedly called by another portion of the second code until a predetermined result is achieved. In some such embodiments, the subroutine is a measurement subroutine. In some such embodiments, the measurement subroutine uses ancillary qubits or quantum dits of a plurality of qubits or quantum dits to improve the measurement result. In some embodiments, the predetermined result is the measurement result of one or more qubits or quantum dits defined by the second code.

[0021] In some embodiments, the conditional statement is an increment loop.

[0022] In some embodiments, the low-level module at least partially converts the second code into a third code by optimizing the code within the conditional statement to form an optimized conditional statement, where the repetition of the code sequence specified by the optimized conditional statement has fewer instructions than the repetition of the code sequence specified by the conditional statement, unrolling the optimized conditional statement into a series of quantum gates, and incorporating the series of quantum gates into the third code.

[0023] In some embodiments, the low-level module converts at least partially the second code into a third code by optimizing a quantum operation that functions to execute a portion of the second code, thereby reducing the number of gates, qubits, or quantum dits in the third code that are required to execute the quantum operation.

[0024] In some embodiments, the second code defines qubits or quantum dits within a target quantum processor. In some embodiments, the second code defines a register of qubits or a register of quantum dits within a target quantum processor.

[0025] In some embodiments, the gate-level language supports qubit measurements or quantum dit measurements.

[0026] In some embodiments, the quantum gate-level language uses a plurality of different gates. In some embodiments, each gate within the plurality of different gates is defined in a different data structure that includes the name of each gate, the dimension of each gate in terms of the number of qubits or quantum dits, and a corresponding plurality of Kraus operators for each gate. In some such embodiments, the corresponding plurality of Kraus operators for each gate are specified by a function handle.

[0027] In some embodiments, the third code supports a general positive-operator-valued measurement of one or more qubits out of a plurality of qubits, or one or more quantum dits out of a plurality of quantum dits.

[0028] In some embodiments, the gate-level model compiles at least partially the third code into a fourth code by performing a gate synthesis that swaps a sequence of gates that implements at least a portion of the third code, which is different from the sequence of ideal gates, with a sequence of gates that, while different from the sequence of ideal gates, will perform the function of the sequence of ideal gates on the target quantum processor. In some such embodiments, the sequence of gates different from the sequence of ideal gates is identified by an evaluation of the stored hardware characteristics of the target quantum processor.

[0029] In some embodiments, the compiler further includes instructions for circuit embedding of the fourth code while respecting the locality constraints of the target quantum processor.

[0030] In some embodiments, the instructions for circuit embedding of the fourth code while respecting the locality constraints of the target quantum processor further include taking into account the determined quality of the target quantum processor when performing two-subsystem gates.

[0031] In some embodiments, the compiler further includes instructions for counting the number of gates, qubits, quantum dits, or total clock time required to implement a computer program on the target quantum processor.

[0032] In some embodiments, the compiler further includes instructions for implementing a first portion of a computer program on the target quantum processor and implementing a second portion of the computer program on a digital central processing unit or a graphics processing unit of a digital computer system.

[0033] In some embodiments, the compiler further includes instructions for simulating the quantum code generated by the compiler on a digital central processing unit or a graphics processing unit of a digital computer system.

[0034] Another aspect of the present disclosure provides a method of compiling a computer program executable on a target quantum processor including a plurality of qubits or a plurality of quantum dits, the method being performed in a digital computer system including one or more digital processors and a memory, the memory including non-transitory instructions configured to execute a procedure using the one or more digital processors, the procedure including obtaining, at a unified level module, a computer program described in a unified language; further including performing, at the unified level module, code refactoring on all or a portion of the computer program to form refactored code; further including converting the refactored code into a first code; further including compiling, at a high-level module, the first code into a second code, the high-level module supporting loops, subroutines, and flow control instructions within the first code; and further including converting, at a low-level module, the second code into a third code including a series of quantum gate level operations, and compiling, at a gate level module, the third code into a fourth code expressed in a quantum gate level language according to the instruction set of the target quantum processor and gate locality constraints.

[0035] Another aspect of the present disclosure provides a non-transitory computer-readable storage medium storing one or more programs. The one or more programs include instructions that, when executed by a digital computer system having one or more digital processors, cause the digital computer system to perform a procedure including obtaining a computer program described in a unified language with a unified level module. The procedure further includes performing code refactoring on all or a portion of the computer program with the unified level module to form refactored code. The procedure further includes converting the refactored code into a first code. The procedure further includes compiling the first code into a second code with a high-level module, the high-level module supporting loops, subroutines, and flow control instructions within the first code. The procedure further includes converting the second code into a third code including a series of quantum gate level operations with a low-level module. The procedure further includes compiling the third code into a fourth code expressed in a quantum gate level language in accordance with the instruction set of the target quantum processor and gate locality constraints with a gate level module.

Brief Description of the Drawings

[0036]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figures 32A - 32C

Figures 33A - 33B

Figure 34

Figure 35

Figure 36

Figures 37A - 37B

[0037] Throughout several of the drawings, like reference numerals refer to corresponding parts.

DETAILED DESCRIPTION OF THE INVENTION

[0038] A computer system and method for compiling a target quantum computer including a plurality of qubits or quantum dits, and / or a computer program executable on a digital computer are disclosed. A unified level module of the compiler obtains a program described in a unified language, performs code refactoring on all or a part of the computer program to form refactored code, and converts the refactored code into a first code. A high-level module of the compiler compiles the first code into a second code, and the second code enables loops, subroutines, and flow control instructions. A low-level module of the compiler receives the second code and converts the second code into a third code including a series of quantum gate level operations. A gate level module of the compiler compiles the third code into a fourth code represented in a quantum gate level language according to the instruction set of the target quantum computer and the gate locality constraint.

[0039] Here, embodiments will be referred to in detail, and examples of the embodiments are illustrated in the accompanying drawings. In the following detailed description, many specific details are set forth in order to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0040] The terms first, second, etc. may be used herein to describe various elements, but it will also be understood that these elements are not limited by these terms. These terms are only used to distinguish one element from another. For example, a first object may be referred to as a second object without departing from the scope of the present disclosure, and similarly, a second object may be referred to as a first object. The first object and the second object are both objects, but they are not the same object.

[0041] The terms used in this disclosure are for the purpose of describing particular embodiments only and are not intended to limit the invention. As used in the description of the present invention and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. As used herein, the terms "comprises" and / or "comprising" specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0042] As used herein, the term "when" can be interpreted to mean "when", "if", "in response to a determination", or "in response to a detection", depending on the context. Similarly, the phrases "when determined" or "when [stated state or event] is detected" can be interpreted to mean "when determining", "in response to a determination", "when detecting [stated state or event]", or "in response to detecting [stated state or event]", depending on the context.

[0043] FIG. 1 illustrates a computer system topology 48 that provides a unified language that can be compiled and executed on either a classical digital computer 60 or a quantum computer 64 that includes a plurality of qubits 102. Referring to FIG. 1, in an exemplary embodiment, the topology includes a compiler computer system 100 that communicates electronically with a quantum computer 64 that includes a plurality of qubits 102 and a digital computer 60. In some embodiments, the compiler computer system 100 and the digital computer 60 are the same computer or the same computer system. In some embodiments, the electronic communication between the compiler computer system 100 and the quantum computer 64 is via a communication network 106. In some embodiments, the compiler computer system 100 applies a suitable quantum code 62 to the quantum computer 64 when the suitable quantum code 62 is compiled.

[0044] For purposes of illustration in FIG. 1, the compiler computer system 100 and the digital computer system 60 are each represented as a respective single computer that includes all of the functionality of a classical computer system. However, the present disclosure is not so limited. The functionality of the compiler computer system 100 and / or the digital computer 60 may span any number of network computers and / or may reside on each of some network computers. Those skilled in the art will understand that a wide variety of different computer topologies are possible for the compiler computer system 100 and that all such topologies are within the scope of the present disclosure.

[0045] Keeping the foregoing in mind and turning to FIG. 2, compiler computer system 100 includes one or more processing units (CPUs) 74, a network or other communication interface 84, a user interface 78 (including, for example, a display 82 and a keyboard 80 or other forms of input devices), a memory 92 (e.g., random access memory), optionally one or more magnetic disk storage and / or persistent devices 90 accessed by one or more controllers 88, one or more communication buses 12 for interconnecting the foregoing components, and a power supply 76 for powering the foregoing components. Data within memory 92 can be seamlessly shared with non-volatile memory 90 using known computing techniques such as caching. Memory 92 and / or memory 90 can include mass storage located remotely from central processing unit(s) 74. In other words, some data stored in memory 92 and / or memory 90 may actually be external to analysis computer system 100 but can be electronically accessed by the analysis computer system via network interface 84 over the Internet, an intranet, or other forms of network, or a computer hosted on an electronic cable that can be accessed electronically.

[0046] The memory 92 of compiler computer system 100 includes · an operating system 8 including procedures for handling various basic system services, and · a computer program 10 described in a unified language, and · A compiler 12 for compiling a target quantum computer including a plurality of qubits or quantum dits, and / or a computer program executable on a digital computer, the compiler obtaining a computer program 10 described in a unified language, performing refactoring on all or a part of the computer program to form refactored code, and converting the refactored code into a first code (15); a unified-level module 14; a high-level module 102 that compiles the first code into a second code 104, the second code 104 enabling loops, subroutines, and flow control instructions; a low-level module 106 that receives the second code 104 and converts the second code 104 into a third code 108 including a series of quantum gate-level operations; and a gate-level module 110 that converts the third code 108 into a fourth code 112, the fourth code being represented in a quantum gate-level language according to the instruction set of the target quantum computer 64 and gate locality constraints. The compiler 12 is stored.

[0047] In some implementations, one or more of the above-identified data elements or modules of the compiler computer system 100 are stored in one or more of the previously disclosed memory devices and correspond to a set of instructions for performing the functions described above. The above-identified data, modules, or programs (e.g., instruction sets) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or otherwise rearranged in various implementations. In some implementations, the memory 92 and / or 90 optionally stores a subset of the modules and data structures identified above. Further, in some embodiments, the memory 92 and / or 90 stores additional modules and data structures not described above.

[0048] The number of people working on quantum algorithms is small, but the number of people who have GitHub accounts and can thus be considered traditional software engineers is large, on the order of 100 million. There have been many experiments on ways to popularize programming such as quantum computing. For example, efforts have been made by companies like IBM to release source development tools and encourage people to use the platform, with some expectation that this will lead to a boom in quantum computing algorithms. However, despite this, the number of people working on quantum algorithms has remained small.

[0049] From the perspective of quantum computing, most of what is implemented is a changing technology and all are essentially relatively similar. Basically, it is rare for new algorithms to emerge from a user community that has not previously existed in the quantum computing industry. While new algorithms will surely always emerge from people with a background in quantum computing, people coming from outside the field of quantum computing who work in other areas of computer science do not necessarily adopt quantum computing platforms and contribute to new applications for quantum computing. The systems and methods of the present disclosure are designed to address this shortcoming.

[0050] Referring to FIG. 31, the present disclosure provides a novel approach. To set the background of the approach, FIG. 22 provides exemplary milestones in the history of programming languages. Going back to the 1950s, things like microcode and assembly became available. As time went on, languages such as BASIC and C emerged with a higher level of abstraction. Therefore, writing programs using Matlab or Python does not require the programmer to worry about how the processor works. That is, since all such details are processed by the interpreter, the programmer does not need to process any of such details. On the other hand, C is a bit closer, and when reaching assembly, the programmer has to consider the individual registers of the processor when programming in such a language. The goal of the systems and methods of the present disclosure is to abstract to a high enough level so that both conventional computers and quantum computers can be programmed using the same language. This promotes the goal of expanding the use of quantum computers to computer scientists outside the traditional quantum computing community. By doing so, this makes quantum computers more accessible. Referring to FIG. 4, languages such as Matlab and Octave are already at a high enough level that the programmer can use these languages to represent what they want to perform algorithmically. Therefore, the code at this level of abstraction then serves as the basis for the code that is compiled to use quantum algorithm techniques to be executed on a quantum computer in order to gain the performance advantage that the same code is executed purely on a digital computer. Referring to FIG. 5, the basic step for accomplishing this according to the systems and methods of the present disclosure is to perform some abstract representation 504 of the initial code in some conventional source code 502 (e.g., described at a level of abstraction typical of programming languages such as Matlab or Octave). By doing so, in some embodiments, a syntax tree is constructed from the initial code.An attempt is made to construct a quantum algorithm 506 from an abstract representation, and then transform the quantum algorithm into some circuit representation 508, and then transform the circuit representation 508 into the native circuit 510 of a quantum computing device, and then finally transform the native operations into whatever is appropriate for this device. Thus, element 512 may mean outputting to a quantum programming language such as Quil (Smith et al., 2016), “A Practical Quantum Instruction Set Architecture,” arXiv:1608.03355 [quant-ph]) or cQASM (Bertels et al., 2018-05-24, “cQASM v1.0: Towards a Common Quantum Assembly Language,” arXiv:1805.09607v1 [quant-ph]), or element 512 may mean outputting a pulse sequence.

[0051] Figure 7 illustratively shows, in a broad sense, the way in which FIG. 6 is implemented. A compiler composed of four different levels is provided. At the base, there is a gate-level language (hydrogen, gate-level modules). Hydrogen (the third code) is gate-focused. Helium (the second code) can be regarded as Quantum BASIC. Helium still performs gate operations but also provides basic loop and conditional statement and subroutines. Beryllium (the first code) can be regarded as equivalent to Quantum C based on its ability to handle structures, functions, and classes. The highest level is a certain common subset of Matlab and Octave called Carbon. Carbon is a classical language that can be executed on a digital classical computer. Referring to FIG. 6 and looking at how the disclosed compiler operates, there are four levels. At the highest level, the classical code (Carbon) can be directly executed on a classical digital central processing unit or a graphics processing unit. As the compilation progresses to lower levels (the lower stack in FIG. 6), all the remaining languages are quantum with a decreasing level of abstraction. Beryllium is at a fairly high level and supports functions, classes, structures, and even pointers. Below Beryllium is Helium, which can be regarded as Quantum BASIC and supports subroutines and loops. Beryllium enables resource accounting, for example, estimating the resources for a specific algorithm, for post-quantum cryptography, and predicting which resource pockets will be used for a specific algorithm. Beryllium enables the programmer to encode a quantum program in a way that is specified at the gate level without the need to specify, yet still enables optimization of the code. Thus, using Beryllium, resource counting can be performed without the need to expand everything into a huge number of gates. Continuing to refer to FIG. 6, at the lowest level, there is a gate-level language (hydrogen) that simply literally specifies quantum gates by quantum gates, and what the quantum computing device has to do is to execute the algorithm specified by the higher-level language. Hydrogen interfaces directly with the quantum computing hardware.

[0052] To solve a computational problem using a quantum computer, not only is the quantum computer required, but software that can utilize the quantum computer to solve the problem is also necessary. Advantageously, the systems and methods of the present disclosure provide program tools that are for the quantum community as well as for conventional software engineers who have shown an interest in using quantum computers to solve computational problems.

[0053] Here, the layers of the quantum compiler illustrated in FIG. 6 are presented in the reverse order, starting from the hardware front, moving up to the gate level, then to the low-level and high-level quantum languages, and finally to the conversion of the quantum code to classical code.

[0054] Characteristics evaluation and compilation. This section, characteristics evaluation and compilation, targets the characteristics evaluation in step 30 of FIG. 31. A characteristics evaluation routine used to generate a profile of a quantum processor considered by various compiler levels of the systems and methods of the present disclosure is disclosed.

[0055] Referring to FIG. 23, which begins with hardware and characterization, the reason this is addressed by the systems and methods of the present disclosure is that the gates implemented in commercial quantum chips such as Regetti and IBM quantum chips are not perfect. These quantum chips exhibit noise and errors. Moreover, the noise is not of the simple kind that theorists like to consider. It is neither independent and identically distributed (i.i.d.) noise, nor depolarizing noise, nor amplitude damping noise. Therefore, in order to execute quantum codes well, it is useful to know what the quantum device is actually doing. For example, with regard to errors, various types of errors are introduced into the quantum system. Some of the gates applied to the quantum system are mis-calibrated by the quantum system. For example, a rotation implemented on the quantum system as part of a unitary gate can end up rotating at an angle different from what was assumed, but is still unitary. This is a situation where the characterization of the quantum system is immediately useful. It is not about what the gate is supposed to do, but about knowing what the gate does when implemented on a particular quantum chip. With this knowledge, better results can be compiled. Therefore, it is advantageous to track these characterizations and consider them during the quantum compilation process. Moreover, with regard to noise, in many cases, the noise is non-Markovian and can be canceled out in some way. For example, there can be various ways to separate the noise or to simply calibrate the quantum system slightly differently considering some of the spread observed in the spectrum. Therefore, the reason characterizations are performed according to some embodiments of the systems and methods of the present disclosure is that the characterizations can feed back to a lower level of the compiler, thereby allowing the quality of the gates to be considered when attempting to embed the circuit into a quantum processor. For example, not all CZ or CNOTs are created equal. Some are better than others, and when gate synthesis is performed, some operations are less expensive than others from the perspective of the overall error budget. Therefore, the characterizations performed according to the systems and methods of the present disclosure are designed to take this into account.Moreover, use the characteristic evaluation to consider unitary errors and generate the most optimal operations possible.

[0056] Figure 11 provides an example obtained from a 32-qubit Rigetti chip. When a Ramsey experiment is performed on this qubit, a good cosine curve that gradually decays is observed for most of the qubits, but there is one qubit (1102) that exhibits non-periodic behavior, in contrast to the other qubits grayed out in Figure 11. What is happening to qubit 1102 is unknown. Qubit 1102 can be considered a faulty qubit that has some problem and should not be used at all. However, upon investigation, it is found that qubit 1102 is actually very close to a pure state. Qubit 1102 is sufficiently initialized, and what is happening is that the operations being performed on the qubit itself do not start at the correct initial stage and the operations are incorrect. That is, a sequence of operations is being executed using the qubit, but since the operations are different from what was intended, a bad result occurs. However, if such information is known, it is possible to attempt to use the characteristic evaluation to take this into account.

[0057] FIG. 24 provides another example showing the results of actually reducing stray couplings within a quantum device. What is commonly found in superconducting processors is that individual qubits are essentially (e.g., via Ising interactions) coupled to each other in a way that they are not supposed to be present there. Therefore, the general effect of this is that when the interacting neighbors of each qubit are in the |0> state, the gap between the |0> and |1> states of each qubit has some specific value, but when the interacting neighbors are in the excited state (|1>), this gap has the effect of changing the operation level of each qubit. In other words, there is a change in the amount of energy required to change each qubit from the |0> state to the |1> state. Therefore, when the interacting neighbors and each qubit are each in their respective |1> states, one limit of the energy diagram is realized, and when the interacting neighbors and each qubit are each in their respective |0> states, a different limit of the energy diagram is realized. Moreover, it is possible to have two or more interacting neighbors, and FIG. 24 is only an example when there is only one interacting adjacent qubit. When a qubit is in some entangled state, spreading occurs and there is an undefined gap between |0> and |1>, presenting a problem. The reason this is a problem is that if a qubit is left in the |1> state, this qubit starts to accumulate phase depending on the state of the qubit's neighbors. In many cases, no matter what calibration process is performed, it is assumed that the neighbors are in |0>. Therefore, such calibration assumes that the adjacent qubits in the device are in |0>, and in that case, the x rotations performed or the y rotations performed each bring each qubit fairly well into near resonance from |0> to |1>, but as the state of the qubits adjacent to each qubit changes, an overlap occurs between the adjacent qubits and each qubit, resulting in decoherence. FIG. 12 is illustrative. FIG. 12 is an example of actual data obtained from the Regetti Q32 Aspen-7 chip. On the left side of FIG. 12, a coincident Ramsey experiment is illustrated.A single qubit is prepared in a superposition of |0> and |1>, and this qubit is allowed to process for a certain period of time before undergoing another rotation. After this, if no phase is accumulated, the qubit should be in the computational basis |0>. However, since each qubit has some intrinsic frequency, some hysteresis occurs. Moreover, for the graph illustrated in FIG. 12, a planar rotation is implemented such that a prominent curve is realized. Thus, one of the curves presented in each of the plots is for a particular adjacent qubit in |0>, and the other curve is for its neighbor in |1>. Therefore, the curves show how the frequency shifts when the adjacent qubits are compared when they are in |0> and when they are in |1>, which represents the change in the gap. For this reason, in some cases, this change in the gap is somewhat small, on the order of a few kilohertz. In other cases, this change increases on the Regetti chip to a coupling of about 35 kilohertz. Up to 150 kilohertz has been observed on the IBM chip. Moreover, these gaps can be mapped out for a given quantum processor as shown on the right side of FIG. 12. The right side of FIG. 12 illustrates the culmination of tests between different pairs of qubits on a single processor to construct a map of where the stray couplings are. As illustrated in the right panel of FIG. 12, often the stray couplings are between the nearest neighbors. The positions of the vertices in FIG. 12 (right side) are the locations physically on the chip. However, there are some strong couplings between neighbors that are not the nearest.

[0058] For hydrogen, there are commands wait(time)[addr1,...,addrk] and wait(time) that do not apply gates to the target quantum system, either on the specified subsystem (qubit or qutrit specified by addr1,...,addrk) or on all qubits for the specified period (time parameter in parentheses). As described in Figures 25 and 26 below, in a non-ideal quantum system, something actually happens to the quantum system during this waiting period. Therefore, "wait" does not act as intended. In the Rigetti and IBM systems, some small Z rotations occur on each qubit, and some small Ising (ZZ) interactions occur between some pairs of qubits (the thickness of the lines in the right part of Figure 12 and in the graph in Figure 28 indicates the strength of this unwanted coupling). It has been found that the plots in Figures 25 and 26 show the results of applying several relaxation strategies to approximate the equivalent of the hydrogen command wait(t)[q] for q = 0 and q = 33 (two different qubits in the Rigetti Aspen-7 processor), and similar behavior exists in most (non-photonic) quantum processors. For Figures 25 and 26, error mitigation techniques are used to ensure that nothing happens to the qubits for a period, but the same techniques disclosed for Figures 25 and 26 can be used during more interesting operations.

[0059] FIG. 25 illustrates an example of performing error reduction techniques in accordance with the systems and methods of the present disclosure. Curve 2502 is the original qubit, representing the probability of recovering a particular quantum state in microseconds as a function of time. A quantum state is prepared, allowed to elapse for a certain time, and then an attempt is made to recover the original quantum state. However, when this is done, all of the other qubits in the device become entangled. Thus, due to these stray couplings, the qubits dephase. The present disclosure provides various ways to handle this. First and most simply, it is to update the frame. As described above, when quantum devices are calibrated, these quantum devices are often calibrated under the assumption that adjacent qubits are in the |0> state. Therefore, the pulse duration of the gate is calibrated based on the assumption that adjacent qubits are in the |0> state. Thus, the difference between the |0> and |1> states when all neighbors are |0> is quite close to the pulses actually used. However, when adjacent qubits are placed in the |1> state, each qubit is in another extreme of the energy diagram, as described above in conjunction with FIG. 24, resulting in a large change in energy. A good strategy for dealing with this is to assume that all of the qubits on the quantum chip under consideration are part of the calculation, and that all of the qubits are probabilistically entangled with other qubits, and it is not known whether all of the qubits will be between |0> and |1>. In such a situation, since it is equally possible for that to be the case, or better yet, it can be assumed that all of the qubits are between |0> and |1>, the observed energy gap should not be assumed to be the extreme value achieved by measuring when adjacent qubits are in |0>. Rather, one should select the energy gap at the center of the observed range between when all adjacent qubits are in |0> and when all adjacent qubits are in |1>.

[0060] The curve 2504 (frame update) illustrates what happens when this energy gap at the center of the observed range is selected. In this method, wait(t)[q] is replaced with rz(w*t)[q]. This means adding a small time-dependent Z rotation to the qubit. This was done through the frame update of the pulse control software on the Rigetti system for the illustration of Figure 25, but instead, it can be done directly in the gate synthesis module (stage 25 of Figure 31) of the compiler 12.

[0061] The curve 2504 decays more slowly than the curve 2502 (original). For curve 2504, dephasing still occurs, but since the pulse sequence is set under the assumption that the energy gap of each qubit is at the center of the spread, what is happening is that some coherent rotation is not being picked up. In contrast, curve 2502 does not center as in the case of curve 2504, but instead, due to the fact that the pulse sequence of curve 2502 is calibrated at one extreme of the energy gap range, a coherent rotation effectively occurs on top of the dephasing, so it begins to sink slightly downward and return.

[0062] Alternatively, a spin echo approach can be taken where the qubit is allowed to evolve over a period of time, inverted, allowed to evolve again over the same period of time, and then the inversion is reversed. This separates any Ising interactions from the qubit and provides curve 2508 which exhibits slower decay. When this separation is done, curve 2506 occurs, but the interacting set of qubits is inverted. The interacting qubits are inverted to separate all qubits from every other qubit, not just one particular qubit from an adjacent qubit. If all qubits are inverted simultaneously, all of their couplings remain the same and they are separated from the environment but not from each other. Therefore, if they are divided into two groups and it is determined which one will be inverted based on which set they are included in, curve 2506 occurs. Thus, according to this second error mitigation technique, the qubits are inverted periodically by injecting an X gate at t / 2 and then a second X gate at t. This is a well-known technique called spin echo, but other separation pulses can also be used. This results in curves 2506 and 2508 of FIG. 25. Curve 2508 is when only qubit q is inverted according to the exemplary code illustrated in FIG. 36. This results in a far better performance of the target qubit, but the other qubits are not improved. A more complex procedure to improve all address selection wait(t)[addr1,...,addrk] is not only q, but to select a subset of qubits that are inverted at different times. Since the strongest unwanted couplings are between the even and odd numbered qubits, in the illustration of FIG. 25 only the odd numbered qubits are inverted, resulting in curve 2506. Each of the two versions of this error correction technique's hydrogen code is illustrated in FIGS. 36 (curve 2508, setup echo) and 37 (curve 2506, echo by parity), respectively. In some embodiments, any implementation of the error reduction techniques illustrated in FIG. 25 or its equivalents is automatically applied to the gate synthesis module of compiler 12 (stage 25 in FIG. 31) or is applied separately before the output to the target quantum system.

[0063] FIG. 25 illustrates qubit 0 on the Aspen-7 device when calibrated at a particular time. However, the qubit in FIG. 25 was not the qubit that showed the greatest differences across various calibration techniques.

[0064] FIG. 26 illustrates typical differences seen on the Aspen-7 device. FIG. 26 is an example of a qubit that does not perform well on the original device. Thus, in this case, curve 2602 is the original effect of preparing a qubit in the positive state, leaving this qubit idle for a certain period of time, then measuring this qubit again, effectively performing a Hadamard, and measuring this qubit. Curve 2602 sinks very quickly to less than 50%, but actually returns upward, which is due to acquiring a coherent Z rotation, which is the effect of the idling coupling to other qubits on the quantum computing chip, although this is not ideal.

[0065] Continuing to refer to FIG. 26, the frame update approach results in curve 2604, which already provides a significant improvement up to about 30 or 40 microseconds, at which time the separation at this time (curves 2606 and 2608) is much better here. Thus, curves 2606 and 2608 are far above either of curves 2602 and 2604. Considering the waiting time to reach a 70% probability of state recovery as a metric for comparison, there is a significant difference between what occurs when either the original strategy (curve 2602) or the separation strategy (echo by parity, curve 2606, FIG. 37, or with a set of echoes, curve 2608, FIG. 36) is adopted. Thus, different approaches significantly change the lifetime of qubits on the quantum computing chip.

[0066] In the above consideration, the term "ising" is meant to mean a CZ coupling. That is, no special mechanism for the coupling is intended. Since tomography between qubits of different amounts of time has been observed, it has been observed how each of the terms in the density matrix changes over time, and a significant amount of that is the ZZ term. And referring to FIG. 12, when qubit 14 is considered, there are contributions from qubits 1, 15, and 13. Thus, for example, when only qubits 15 and 14 are considered, there is a fairly strong ZZ coupling, but decoherence is also observed, and part of that decoherence is caused by the coupling to qubit 13, and part of that decoherence is caused by the coupling to qubit 1. When these entries are plotted over time, it can be seen that the decoherence falls more slowly than initially assumed and then gains speed because it is not of the non-Markov type. This indicates that the coupling between the qubits is coherent. There are relaxation and other errors that occur simultaneously, but the coupling is fairly significant. Therefore, the use of the separation approach illustrated in FIGS. 25 and 26 improves the lifetime of the qubits for performing quantum operations.

[0067] Referring to FIG. 26, another reason that the coupling is clearly ising is that when a simple spin echo is performed in which the qubit is inverted in the middle of a time sequence and then inverted again, the sequence does a very good job of canceling that coupling.

[0068] To further calibrate a quantum computing chip, it is interesting to measure where all the stray couplings are on the quantum computing device. While it would be desirable to isolate all the qubits on the device, the problem is that such an approach is not feasible. If the same separation sequence were executed for every qubit, they would not separate from each other, but rather these qubits would be separated from the environment. To separate qubits from each other, different sequences need to be performed for each qubit. However, the gates required to achieve this take a rather long time compared to the coherence time (T2). Therefore, what is needed is to separate the qubits without using too many gates. To accomplish this, it is useful to know which qubits are coupled to which other qubits. Performing identical Ramsey experiments between every pair of qubits seems to be very meaningful as an alternative. However, to obtain sufficient statistics on an actual device, the experiment would need to be run continuously for more than a day. The problem associated with this is that these parameters change and these parameters drift over time, so that the measured values become invalid by the end of the Ramsey experiment. Therefore, what is useful and needed is for the device to be able to perform all the measurements on the device within about 30 minutes, then update the parameters, update the frame of each qubit, and design the separation pulse sequence so that the device is implemented for several hours and then calibrated again. To do this, there is not enough time to perform measurements in qubit-pair units. Therefore, some embodiments of the systems and methods of the present disclosure are directed to a method of exciting all the qubits, exposing them to their respective Hamiltonians over various times, then measuring them, and then attempting to break the pair couplings between all the qubits. Thus, what would previously have been done thousands of times can be reduced to about 7 runs on a Rigetti Q32 Aspen-7 QPU, which is useful.At least for the Rigetti system, the side effect seems to be that it takes longer to execute on larger chips due to some compilations that occur just before it is executed. This effect is that the process is slower on larger chips that execute the same number of shots than on smaller chips or sub-lattices where it is executed. For this reason, there is a little noise in the coupling graph illustrated in FIG. 28. In FIG. 28, the couplings between unit cells are omitted for visibility, but FIG. 28 shows the observed couplings from the slowest chips where all couplings are mapped out to several shots using the systems and methods of the present disclosure.

[0069] Regarding stage 29 of FIG. 31, in some embodiments, the gates, quantum dits, and other resources required for the circuit are counted. In some embodiments, the real time is estimated based on the quantum processor specification.

[0070] Hydrogen (element 212 in FIG. 3). Moving from the hardware level, note the low-level programming used in stages 20 - 27 and 29 of FIG. 31. Referring to FIG. 8, the present disclosure provides a gate-level module that uses a low-level programming language called Hydrogen. Hydrogen is a gate-level language in which the quantum operation to be executed and optionally the hardware address on which the quantum operation is to be executed are specified. Quantum bits are dynamically allocated, and parameters are specified for, for example, an rz gate, which is then compiled into code that is compatible with the hardware. If a specific hardware address for a quantum operation is not specified, for example, to find an optimal allocation to minimize the number of swaps that have to be made within the calculation, the allocation of the quantum bits is changed.

[0071] Referring to the right panel of FIG. 9, which provides an example of a hydrogen code, the hydrogen programming language is structured. That is, this language is defined by a structured text file. The format is command_name(param1,...,paramN)[addr1,...,addrM], where "->" indicates that the command returns a value. Quantum bits are defined in terms of gates. For example, in some embodiments, each gate is defined in a separate text file that can be edited to add new operations by adding the Kraus operator for the gate.

[0072] For example, referring to FIG. 9, when defining the CNOT(a,b) gate used in the 7th line on the right side of FIG. 9, the CNOT gate is specified in the central panel of FIG. 9 in a data structure that provides the name of the gate "CNOT", the number of dimensions on the subset system, and the appropriate Kraus operator. Here, "dim_in:2 2" means that the first subsystem is of dimension 2 and the second subsystem is of dimension 2. To define how the CNOT gate interacts with, for example, qubits, the appropriate Kraus operator for the CNOT operation is specified as [1 0 0 0;0 1 0 0;0 0 0 1;0 0 1 0].

[0073] As another example, line 10 of the code on the right side of FIG. 9 calls h[a]. In some embodiments, h[a] is defined in a separate data structure as follows. h{ dim_in:2 dim_out:2 kraus:[0.7071067811865475 0.7071067811865475;0.7071067811865475 -0.7071067811865475] }

[0074] That is, the name of the data structure is given "h", the dimensions are specified ("dim_in:2", "dim_out2"), and the Kraus operator is defined for h[a].

[0075] Moving to the "Measurement" example on line 11 of the code on the right side of FIG. 9, the compiler 12 supports a general positive operator-valued measure (POVM). Thus, any set of Kraus operators corresponding to classical outputs can be specified. In the measurement example on line 11 of the right side of FIG. 9, the name of the gate ("Measurement"), the number of dimensions ("dim_in: 2 2", "dim_out: 2 2"), and the Kraus operators of the measurement gate ("Kraus: [1 0]->0", "Kraus [0 1]->1") are specified in a separate data structure illustrated in the central panel of FIG. 9.

[0076] Furthermore, referring to line 14 of the code on the right side of FIG. 9, the compiler 12 supports parameterized gates where the Kraus operators are given by function handles. This enables the generation of Kraus operators when the values of the parameters are passed, allowing the compiler 12 to implement any parameterized gate. Thus, the code rz(0.3927)[b] passes the parameter value 0.3927 to the rz gate defined in the central panel of FIG. 9. In some embodiments, the compiler 12 calls these function handles to immediately generate the Kraus operators for any parameters specified by the gate.

[0077] FIGS. 32A, 32B, and 32C illustrate the definition of an example of a gate set. To implement a desired gate as part of a quantum algorithm, any of the gates specified in FIGS. 32A, 32B, and 32C can be called by the hydrogen code. Furthermore, FIG. 32 illustrates a way in which new gates can be easily defined and added using a general format. Instruction { dim_in: subsysdim1 subsysdim2... subsysdimM dim_out: subsysdim1 subsysdim2... subsysdimM kraus: kraus1(->output1) ... kraus:krausN(-> output N) }

[0078] Referring to FIG. 10, one advantage of using function handles is that it makes it easier to accommodate changes between the quantum hardware instruction sets associated with different quantum devices. This is represented by element 25 in FIG. 31. Since each quantum device has a unique set of gates, this is useful. For example, ion traps with their Molmer Sorensen gates are different from the Knill-Laflamme-Milburn (KLM) gates in an optical system and different from the Kraus canonical gates in superconducting qubits. For illustration purposes, different language files can be defined for each instruction set of each quantum system that will be used by a quantum program (as illustrated, for example, in panel 902 of FIG. 9).

[0079] For example, panel 902 of FIG. 9 shows a subset of the standard set of gates found in Nielsen and Chuang, Quantum Computation and Quantum Information, 2010, Cambridge University Press, New York, which is incorporated herein by reference. These gates are, in most cases, defined in one embodiment of the present disclosure because these gates intuitively work together. Then, beyond the standard gates, additional gates associated with a particular target quantum device can be defined using hydrogen. Then, using the calibration techniques discussed in the calibration section above, the Kraus operators are filled for each operation available on the quantum device. Thus, instead of having the Kraus operators associated with the ideal operations at the physical level, some embodiments of the systems and methods of the present disclosure use the calibration techniques described above to elucidate what is physically happening within the target quantum device. In some cases, this results in one set of instructions that refer to an ideal gate such as the desired CNOT, while another set of instructions refers to the actual counterpart of this ideal gate that takes into account the characterization of the particular quantum system. Thus, when a quantum code calls a CNOT instruction for a target quantum processor, the actual quantum gate implemented on the target quantum processor may have different parameters than the corresponding one of the ideal CNOT gate, taking into account the characterization of the target quantum process. One advantage of these different sets of instructions, for example, the ability to specify different sets of instructions, is to enable the exploration of different types of quantum processors, not just qubits. Moreover, this approach supports the development of new gates, or gates specific to the hardware. Moreover, this approach enables the conversion of instruction sets using gate synthesis (e.g., conversion from one type of quantum device to another type of quantum device).

[0080] Thus, for hydrogen, there are ideal gates that a user wishes to execute, and for each of these ideal gates, there is a corresponding gate that a particular quantum processor will actually execute when the ideal gate is called. Hydrogen transforms a sequence of ideal gates into a corresponding sequence of gates specific to a particular quantum processor to achieve the same result, or a result with the highest possible fidelity, for the sequence of ideal gates. Thus, hydrogen provides the ability to support different gates and define these gates only within a single, structured text file, thus enabling it to operate with different instruction sets and convert between the two.

[0081] The following provides an example of a swapping gate set according to stage 25 of FIG. 31. Consider an exemplary program written in Helium code: #This is a comment qubit->1 qubit->2 h[1] cnot[1,2] rz(0.3)[1] measure[1]->1 measure[2]->2

[0082] Thus, this code functions as instruction 1002 of FIG. 10 that the Hydrogen level of compiler 12 compiles.

[0083] FIG. 34 illustrates gate synthesis where the target quantum system is a continuously variable quantum system. Thus, the code for element 1004 of FIG. 34 corresponds to element 1004 of FIG. 10 and provides the input gate set for definition 1004 based on the instruction 1002 provided above. The code for element 1006 of FIG. 34 corresponds to element 1006 of FIG. 10 and provides the output gate set for definition 1006 of the target continuously variable quantum system.

[0084] The code of element 1008 in FIG. 34 corresponds to element 1008 in FIG. 10 and provides a synthesis instruction 1008 for a target continuous variable quantum system based on the above-described intended instruction 1002 and the output gate set definition 1006 in FIG. 34.

[0085] FIG. 35 illustrates gate synthesis where the target quantum system is a separate variable quantum system. Thus, the code of element 1004 in FIG. 35 corresponds to element 1004 in FIG. 10 and provides an input gate set for definition 1004 based on the instruction 1002 provided above. The input gate set of definition 1004 in FIG. 35 is the same as the input gate set in FIG. 34 because the input gate set of definition 1004 does not consider gates that the target quantum system can process efficiently or natively support. The code of element 1006 in FIG. 35 corresponds to element 1006 in FIG. 10 and provides an output gate set for definition 1006 of the target discrete variable quantum system. The output gate set of definition 1006 in FIG. 35 for the target discrete variable quantum system is different with respect to certain gates or gate parameters compared to the output gate set of definition 1006 in FIG. 34 because it considers the evaluation of gates or gate characteristics that the target quantum system can natively support or process efficiently. The code of element 1008 in FIG. 35 corresponds to element 1008 in FIG. 10 and provides a synthesis instruction 1008 for the target discrete variable quantum system based on the above-described intended instruction 1002 and the output gate set definition 1006 in FIG. 35. Similar to the output gate set definition 1006, the synthesis instruction 1008 in FIG. 35 is different from that in FIG. 34 even though both implement the same intended instruction 1002. FIGS. 34 and 35 illustrate the ability of the gate-level module 110 to convert between gate sets when the target quantum system changes.

[0086] In gate synthesis (stage 25 in FIG. 31), the compiler 12 can automatically convert between one instruction set and another based on the description of individual operations. This can be used to address systematic errors in the target quantum system. For example, consider a circuit C represented using ideal (textbook) operations. Example:

[0087] qubit -> 1 qubit -> 2 h[1] cnot[1, 2]

[0088] When executed on ideal quantum hardware, this code should generate the maximally entangled state. However, this quantum hardware is not ideal. Therefore, if the quantum hardware is instructed to follow the exact input circuit, due to small errors in each operation, it will not generate the correct state accurately. What can be done is to characterize the target quantum hardware and obtain a description of the quantum channel applied to the quantum system when a specific command is sent. For example, when the command h[1] is sent to the target quantum system, it may be found that the target quantum system is actually applying some other operation h'. Since this operation is different for each qubit (unlike ideal gates), the actual operation applied is called h1 when the intended operation is the Hadamard (h) for the first qubit, and h2 when the intended operation is the Hadamard for the second qubit of the target quantum system. Similarly, cnot12 is called the actual (imperfect) operation applied when the cnot command is sent to the target quantum system between qubits 1 and 2, and rz1(theta) and rz2(theta) are the actual (imperfect) operations applied when the target quantum system is instructed to implement a Z rotation of angle theta on qubits 1 and 2 respectively. The goal is to approximate C as closely as possible using a sequence of the operations rz1, rz2, h1, h2, and cnot12. This is generally an optimization problem that can be solved.

[0089] Referring to stage 24 of FIG. 31, in some embodiments, the program representation is optionally processed to comply with the locality constraints of the quantum processor, taking into account the quality of two - subsystem (e.g., two - qubit) gates. In some cases, when qubits are routed around the target quantum chip according to the circuit embedding procedure 24 of FIG. 31, taking into account the quality of two - qubit gates, poor couplings can be minimized.

[0090] Stages 24, 25, and 26 of FIG. 31 can be reordered. Regarding stage 25 of FIG. 31, in some embodiments, there is a conversion between the instruction set used in the low - level language / internal representation that uses gate synthesis techniques and the instruction set used by the hardware. Referring to stage 26 of FIG. 31, in some embodiments, the code is scanned for opportunities to reduce the instruction count within the circuit fragment (or improve another user - specified metric).

[0091] Helium (element 210 of FIG. 3). Referring to FIG. 13 and stages 14 - 19 of FIG. 31, the next level - up of the compiler 12 uses a programming language herein denominated Helium. Helium is supported by the low - level module 106 of the compiler 12. Helium functions in the form of Quantum BASIC. The low - level module 106 parses the Helium source file (second code) to create a parse tree and extracts the abstract syntax tree.

[0092] As illustrated by the exemplary Helium code of FIG. 13, Helium can be used to create a new qubit or quantum dits, or a register with a fixed number of qubits or quantum dits, using the general form of qubit -> variable. Lines 1 - 3 of the exemplary Helium code of FIG. 13 provide this example.

[0093] As exemplified by the exemplary Helium code of FIG. 13, Helium has the same instructions as the gate-level language, but these instructions are extended with conditional propositions. For example, referring to lines 5-7 of the exemplary Helium code in FIG. 13, Helium supports an "if" loop. The "if" loop can place control on qubits using an "if" statement. Using a stylistically similar syntax, conditions can also be applied to classical variables. In the case of classical control, the control hardware must either support this functionality or allow custom control code. Another example of the "if" loop supported by Helium is as follows. if[a] cnot[b,c] end

[0094] As exemplified by lines 9-11 of the Helium code in FIG. 13, Helium supports a repetition where an action is repeated until a given condition (e.g., a classical measurement result) is achieved. Thus, lines 9-11 of the code in FIG. 13 are a repeat loop that is effectively monitored by a measurement result where one loop continues to execute until the condition defined by obtaining a specific measurement result is met. This results in a program that cannot be compiled into a circuit and requires implementing control flow logic on classical hardware that controls quantum computing (e.g., FPGA sequencing pulses and processing reads). The repeat until a loop monitored by a measurement result has a general form is repeat operation until[measurement result]

[0095] Another example of this form of repeat loop is repeat h[b] rz(u)[c] h[c] until[a]

[0096] As exemplified by lines 13 - 18 of the exemplary helium code in FIG. 13, helium also supports subroutines. A subroutine is defined separately as a self - contained block of code and can then be called from the main program. The general form of a subroutine definition is sub SubName operation 1 operation 2 endsub

[0097] As exemplified by 10 lines of the exemplary helium code in FIG. 13, to call a subroutine from the main program, the syntax gosub SubName is used. Lines 9 - 11 of the code in FIG. 13 repeatedly call the subroutine defined by lines 13 - 18 of the exemplary helium code until the measurement result [a] is achieved.

[0098] Helium also supports a form of simple loop, herein referred to as an "increment loop", based on variables being incremented from "one" to some specific integer value, as exemplified by the code "increment k to 8" in FIG. 13 where there is an increment of K to 8. At the first time through the loop starting at line 14 of the code, K has the value 1. The next time through loop K has the values 2, then 3, then 4, up to 8. This command increments beyond the value of the classical variable and executes gates that depend on this variable each time through the loop. The general form of this loop has the following syntax. increment k to LoopSize gate1(k)[target qubit] gate2(parameter)[k] ... next

[0099] Another example of an increment loop in helium is increment k to 12 h[k] cnot[k,6] t[k] rz(k)[k] next

[0100] Helium also supports readout. For example, the measurement of a single quantum system / qubit at a time can be performed via a command having a general form. measure[qubit name]->variable

[0101] An example of this is measure[a]->v.

[0102] FIG. 33A illustrates another exemplary Helium program in which qubits a, b, and c are defined and then an increment loop that executes a series of gates is called. Finally, the qubits are measured. FIG. 33B illustrates another exemplary Helium program in which qubits a, b, and c are defined. Then, variable u is set to 9. Then, an increment loop is executed with gate h[k]. Then, qubit a is measured and the result of this measurement is placed in variable v. Next, the subroutine test is executed, and then the subroutine test 2 is executed. Each of these subroutines executes the specified gates. The exemplary programs of FIGS. 33A and 33B illustrate support for comments using the # symbol. Comments are not parsed by the compiler. What is characteristic regarding helium is that this is completely focused on the quantum processor and the control hardware of the quantum processor. This is not the case for digital computers. Helium is different from IBM Qiskit where loops are executed in Python to build circuits. Rather, helium is focused on what should happen on the quantum processor. Loops are not executed on the quantum processor and loops are unrolled before being executed on the quantum processor. The reason for structuring in this way is to enable optimization within the loop. For example, if there is a loop that will be called many times, call an optimization subroutine so that it doesn't have to be done as many times when the loop is unrolled, and execute it on the current program along with the loop to try to optimize what is going on within the loop. For example, check whether a particular action within the loop can be done only once rather than every time the loop is incremented. This brings advantages. For example, if a quantum program has many gates and the optimization identifies a particular action within the loop that only needs to be executed first through the loop, there is no need to unroll the entire loop to result in a large circuit. Therefore, the low-level module of the compiler that supports Helium code looks only within conditional blocks, only within repeat loops, and only within these increment loops and optimizes within them to reduce the complexity of the unrolled circuit before unrolling. This is an example of optimizing the code within a conditional statement to form an optimized conditional statement, and the iteration of the code sequence specified by the optimized conditional statement has fewer instructions than the iteration of the code sequence specified by the conditional statement before unrolling the optimized conditional statement into a series of quantum gates.

[0103] The repeat until command is not supported by currently publicly available systems. In principle, this feature of helium enables quantum programs with infinite execution time. For example, these quantum programs do not necessarily end after a set number of gates (e.g., 27 gates), and these quantum programs can execute longer depending on the measurement results.

[0104] FIG. 14 provides an example of some of the optimization subroutines operating within a low-level module that supports helium source code. FIG. 14 implements a quantum Fourier transform (QFT) 1402 of a total of 53 gates, an incrementer 1404, and then an inverse QFT 1406. When this is encoded in helium and compiled by the low-level module of the compiler of the present disclosure, as a result of the circuit optimization subroutine 1408 of the low-level module, the 53 quantum gates are reduced to only 3 quantum gates 1410.

[0105] Referring to FIG. 29, another thing supported by helium and the low-level modules related to helium is the definition of subroutines. For example, it is useful to define a measurement subroutine. For example, in the case of a single qubit experiment or a two-qubit experiment, on many target quantum chips, whether these target quantum chips are superconducting chips, ion traps, or something else, there are often many extra qubits. If this is the case, the measurement subroutine can be made more accurate by using these extra unused qubits in the measurement subroutine. For example, these qubits can be used as an aid when making measurements. Therefore, instead of measuring a single target qubit, fan out from the qubit with CNOTs onto several auxiliary qubits and measure those auxiliary qubits together with the single target qubit. Then, error correction can be applied to check whether these qubits all give the same result, or alternatively, error correction can be used to take a majority vote. The top panel of FIG. 29 compares the performance using no aids (uncoded), one aid, and two aids on one of the old Regetti chips, Aspen-4. The specific qubits used have an uncoded error rate of 9%, which is a reasonably high measurement error. CNOT also has high errors, but some of the errors that occur are in the form of dephasing errors on control qubits that, for example, do not affect the measurement result because that dephasing is ultimately commutable with the measured value of that qubit and thus does not affect the measurement result. Therefore, it is ultimately possible to fan out several times. Therefore, one pseudo-copy was created on the Regetti device and the results were compared. If zero-zero or 1-1 is obtained, this is a comparison of what state that qubit was actually in. In this way, it can be seen that when using one aid, an improvement from an average of 9% to an average of 3% for post-selection is achieved, and when using two aids, an improvement to an average of 2% for post-selection is achieved.Therefore, this form of measurement subroutine supported by helium is beneficial to have. This enables more robust measurements to be made each time an experiment is run without having to consider how to implement fanout each time. Rather, the measurement subroutine takes care of these details.

[0106] Similarly, referring to the lower part of FIG. 29, the same was tried on IBM QX4. The particular qubit on the particular day when this was tried had an unencoded error rate of 19 percent. Using two ancillas and majority vote error correction, there was no result discard and no post-selection, and as a result, the performance was improved from 19 percent to 12 percent. Using four ancillas, the performance was improved to 10%. This suggests that when not enough CNOTs are executed, ultimately the error rate is not suppressed but pushed up, resulting in a decrease in return. However, in line with FIG. 29, at least two factors contributing to performance gain are presented by most of these quantum systems, and in some cases more.

[0107] Referring to stage 18 of FIG. 31, at this point, the program described in helium, when executed on hardware based on the measurement results obtained during the calculation, is converted into a set of quantum circuit fragments (representable in hydrogen), along with a classical control flow (not generally representable as a quantum circuit) indicating how these circuit fragments are joined together. Such a representation, while there are many cases where this will simply correspond to a single quantum circuit, is useful for general quantum computing. The final output of the compiler is a finite state machine that controls the behavior of the control system that determines the signals sent to the hardware. However, there are many cases where classical control logic is avoided and a suitable instruction set is simply output for the quantum circuit or pulse sequence (although a full finite state machine is required for the most general form of computation). Referring to stage 19 of FIG. 31, at this point, the code can optionally be scanned for opportunities to reduce the instruction count within the circuit fragment (or improve another user-specified metric). Referring to stage 28 of FIG. 31, the output of the low-level module 108 can be executed on a simulator rather than on a quantum processor.

[0108] Beryllium (element 208 of FIG. 3). Referring to steps 8-13 of FIGS. 15 and 31, attention is now drawn to high-level module 102 and the Beryllium language supported by this component of compiler 12. High-level module 102 parses a Beryllium source file (first code) to create a parse tree and extracts an abstract syntax tree. Beryllium utilizes gate-level commands, but Beryllium also supports function and structure definitions and enables breakable loops that cannot be unrolled. An example of a breakable loop is a "for" loop that has a break when some condition is met. In this case, it is not possible for the compiler to know in advance how many times the loop needs to be executed before the break is called. A sample use case for this is that it is desirable to break coherently from a loop that traverses a loop several times, exits that loop, enters another loop several times, exits that loop, and finally performs a measurement. In this case, the total execution time is known, but what is not known is the number of times each loop has been traversed. As long as the total execution time is fixed, there are different possible overlays of the number of times through each loop.

[0109] Beryllium supports pointers. FIG. 16 provides one example where this is useful. Referring to FIG. 16, instead of passing parameters specific to a gate, classical parameters such as, for example, an angle, an address range, or a set of addresses can be passed. From this, the code will examine the values stored in that address range and implement the gate based on it. For example, if the parameter is an angle, the angle can be passed to the gate as an address range. The angle is read from the address range, and the gate is implemented with the rotation specified by the address range. Thus, FIG. 16 illustrates a line of Beryllium code that specifies the angle of the Z rotation (RZ gate) that qubits A and B are to perform on qubit C. This requires many gates for setup and implementation. It is difficult to do. This operation is an important component of the HHL algorithm (Harrow et al. 2009, “Quantum algorithm for solving linear systems of equations,” Phys. Rev. Lett. 15, 150502), and it is extremely difficult to implement because it is difficult to set up the gate sequence. With Beryllium, this can be done immediately for any gate. For example, given a Matlab function that specifies the Kraus operators for a particular unitary gate, the range of parameters it should accept, and the number of qubits to be read out (as a set of addresses), the high-level module 102 can automatically generate a circuit that implements its controlled rotation.

[0110] Referring to FIG. 30, another reason for having a high-level programming language Beryllium is to initiate the implementation of quantum data structures. In other words, use quantum states to implement data types in a way that can store data types or quantum algorithms, manipulate the data types, and obtain better trade-offs than can be achieved classically. While the quantum community places significant emphasis on algorithms, less emphasis is placed on the implementation of quantum data structures and quantum data types. However, it can be seen that different data types using quantum mechanics can, in many cases, be more performant than equivalent classical (digital) implementations of such data types. Thus, Beryllium allows for a higher degree of freedom in choosing how data is structured. Thus, instead of more complex algorithms, specific quantum data structures can be defined using instructions added to the quantum data structures that simply apply specific operations on the quantum data structures. As another example, a quantum data structure can be defined that always stores results for all possible outputs of interest for a particular quantum computation and simplifies the output.

[0111] However, there is a dichotomy and the two different things may not necessarily be fast. By way of illustration, FIG. 30 is an example of a situation where the simplest possible data structure for storing a graph is implemented. The simplest data structure stores the vector as a state vector that is the basis of the HHL-type algorithm. In the HHL algorithm, a real-valued vector must be manipulated by a quantum computer. That is, this vector must be loaded into a computational register where the elements of the vector are encoded as amplitudes of quantum states. When the quantum state is normalized, these amplitudes become the elements of the vector scaled by the norm of the vector. See Dervovic et al., arXiv:1802.08227v1 [quant-ph] Feb. 22, 2018, which is incorporated herein by reference.

[0112] More complex quantum data structures are structures that store graphs as graph sets. Such a data type enables one to directly perform local edge complementation, as illustrated in the upper left of Figure 30, where for a particular vertex a, if there is no edge between neighbors, an edge is drawn, and if there is an edge, it is removed. Using this data structure, this operation can be performed around individual vertices in O(1). Storing graphs as graph sets also enables performing edge complementation within the set. When a subset of vertices is selected, all edges between them can be complemented in linear time. In contrast, for most common classical graph representations, this would require quadratic time. However, a quantum data structure can be constructed that enables this to be done in O(1).

[0113] Cross-edge complementation can also be performed. Given two different sets in a graph, all edges between these sets can be complemented in linear time using the quantum data structure. Also, graph comparison can be performed to compare two graphs in linear time using the quantum data structure with a constant success probability independent of the graph size. Vertex comparison in O(1) can also be performed using the quantum data structure.

[0114] The self - isomorphism test can also be performed when several specific operations are tested to check whether it is an automorphism on the graph. This can be executed with a certain probability of success in the time taken to implement the automorphism. Given these 2n copies, these copies can be classically read out to output the graph. It only requires O(n), where n is the number of vertices that are qubits to be stored. Therefore, it requires fewer qubits than needed to store the adjacency matrix, which is a linear number of copies required to obtain the recovery. There is no classical data structure that can match its performance for a specific pair of operations, for example, vertex comparison in O(1) and local edge complementation in O(1). A certain classical data structure allows either one of these to occur in O(1), but there is no classical data structure that allows both to be done in O(1). In fact, the average is linear. In any case, when averaging the complexity of vertex comparison and the complexity of local edge complementation, the best that can be done classically is O(n). Therefore, this provides motivation for beryllium to support structures and classes such that a variety of quantum data types that use quantum mechanics rather than classical mechanics are used. This is directly related to the carbon of this disclosure, which is a high - level language.

[0115] Referring to stage 13 of FIG. 31, at this point in the compiler workflow, the code can optionally be scanned for an opportunity to reduce the instruction count (or improve another user - specified metric) by making local changes within the program.

[0116] Carbon (elements 202 - 206 of FIG. 3). Refer to FIG. 17 and Stages 1 - 7 of FIG. 31, and here, pay attention to the Unified Level Module 14 and the Carbon language supported by this component of the compiler 12. In some embodiments, the Unified Level Module 14 parses a Carbon source file to create a parse tree and extracts an abstract syntax tree. In some embodiments, Carbon provides a subset of Matlab and Octave functionality. The left panel of FIG. 17 provides a sample of Carbon code. Carbon enables a user to write classical code in the form of a script written in the Carbon language to solve quantum problems. In some embodiments, the compiler 12 compiles the Carbon code into a high-level quantum language (Beryllium), and then into a lower level (Helium, Hydrogen, or a sequence of gates). In some embodiments, the compiler 12 compiles directly to a lower level (Helium, Hydrogen, or a sequence of gates). The component of the compiler 12 illustrated by Stage 12 of FIG. 31 processes such transformations.

[0117] The goal of the compiler 12 is to take this classical code and ultimately use the Unified Level Module 14, the High-Level Module 102, the Low-Level Module, and the Gate-Level Module 110 of the compiler 14 to transform the classical code into a set of quantum gates that perform the quantum task with fewer operations than would be specified by a conventional quantum computing process.

[0118] FIG. 18 illustrates the approach taken to generate this set of quantum gates that perform the task with fewer operations. There are two elements that slow down quantum code, namely, explicit complexity and implicit complexity. The compiler 14 provides a set of tools to address these two forms of complexity in order to generate a set of quantum gates that perform the task with fewer operations.

[0119] Explicit complexity refers to steps that are necessarily hard-coded into slow code by the programmer. An example of this is specifying to repeat a loop many times. Since the programmer is instructing the computer to execute the loop many times, the loop in such a situation will be repeated many times. Another example of explicit complexity is the situation where a recursive algorithm calls a function within a function within a function. This recursion will occur until this recursion ends, no matter how many levels of recursion there are. In both of these examples, the programmer is creating a large number of instructions from a relatively small amount of code.

[0120] Another thing that creates complexity is, for example, the implicit cost of operations like multiplying matrices by each other. To multiply matrices by each other, a single line of code can be written in a program like Matlab or C, but the resulting complexity of the matrix multiplication effectively scales with the cube of the size of the matrices. Most ways in which such operations are implemented are simply cubic time, or close to cubic time, because in most cases there is a large pre-factor for a better complexity scan.

[0121] The approach taken by compiler 12 is, if possible, to refactor the code that causes explicit complexity in a way that eliminates the explicit complexity, pushing the explicit complexity into implicit complexity, and then handling the implicit complexity by using better implementations of data types. For example, by using quantum algorithms, some of the functions resulting from pushing explicit complexity into implicit complexity are handled. FIG. 19 illustrates an example of this approach. FIG. 19 is exemplary Matlab code. Lines 1-7 of the code recursively define a particular matrix. Thus, in lines 3-7, each entry from i to j of the matrix is defined. Lines 9-11 of the code define and set some constants. Next, lines 13-19 of the code define a loop to find the hottest position within the heatmap matrix defined by lines 1-7 of the code. Finally, lines 24-28 of the code define another loop that moves along the diagonal within the array until the value on the diagonal exceeds 5, at which point the process control breaks the loop.

[0122] When the code illustrated in FIG. 19 is compiled by compiler 12, the compiler tries to simplify these loops by breaking them apart. FIG. 20 illustrates this. Compiler 12 decomposes complex loops into simpler loops. Thus, instead of the complex loop defined by lines 13-19 of the code in FIG. 19, there are here two simpler loops, lines 13-15 and 17-22 of FIG. 20. This is the exact opposite of what happens when building an optimizing compiler for classical computing. Classical compilers typically want to join small loops together so that there are fewer branch conditions, thereby reducing the probability of making an incorrect branch prediction.

[0123] Returning to FIG. 20, in addition to the rearrangement of complex loops into simpler loops, there are also some rearrangements of comparisons and statements. Next, the compiler 12 classifies the loops. Thus, referring to FIG. 21, loop 2102, which is the first loop, recursively defines the i-jth entry of the matrix. When possible, it is desirable to use HHL (Harrow et al. 2009, “Quantum algorithm for solving linear systems of equations,” Phys. Rev. Lett. 15, 150502), so the matrix is stored not with an explicit memory of each of the matrix values, but with an oracle that returns the i-jth element when i-j is given. That is, instead of having loop 2102, a function is provided that gives the i-jth entry of the heatmap for a given i-j. This can be accomplished without going through the previous “for” loop. By recognizing that there is a closed-form way to solve this, a closed-form formula can be found to calculate the i-jth entry of the heatmap without going through recursion.

[0124] Next, referring to element 2104 in FIG. 21, again, there is a relationship that can be found for the second loop, and this relationship is only incidentally of the type of loop that can be solved analytically because it is solved analytically.

[0125] Loop 2106 in FIG. 21 can be coded as a quantum maximum search. This loop is finding extreme values, which occur frequently in the code.

[0126] The loop 2108 in FIG. 21 is a sequential search. Therefore, none of these are immediately Grover searches, but the maximum value search 2106 and the sequential search 2108 can be constructed using amplitude amplification, which is a form of quantum computing. The loop that is analytically solved (element 2104) uses the data type as a matrix, so it is much faster to execute. Instead of taking the square of 9998 because the loop 2104 is classically executed twice, it takes logarithmic time. Thus, when implemented by the compiler 12, the solution is executed with the logarithm of 9998. When implemented by the compiler 12, the two searches 2106 and 2108 provide a quadratic speedup. The net result is that the compiler 12 generates a quantum algorithm and a quantum circuit that effectively have 300,000 times fewer operations at the algorithm level (assuming, for example, that the quantum system is noise-free and all allowable overheads are not considered). This shows that the compiler 12, which can go from classical code to a quantum algorithm, can perform computing problems with fewer operations. In cases where the quantum algorithm does not speed up the code because there is a sufficient or better solution, the compiler 12 compiles for a classical processor instead of a quantum process. For example, if the source code is a priority calculation, there is already a really good classical algorithm for calculating the priority, and there is currently no better quantum algorithm. This is an example where a quantum algorithm or quantum data structure cannot speed up the program, and as a result, the priority calculation is inferior to a classical processor target.

[0127] The processing of the looped complex defined by lines 13 - 19 of the code in Figure 19 is an example of loop processing which is stage 5 of compiler 12. The loops are refactored, simplified, classified, and replaced. The loops are processed to identify independent instructions and separated into collections of simpler loops. These simpler loops are then classified based on the effects of these loops, i.e., when certain conditions are met these loops have an effect, when these loops are recursive definitions, etc. The loops are then replaced by different procedures that achieve the same result more efficiently. There are a variety of such loop classes. Some (maximum value search, recursive array / matrix definition, sequential search) are replaced by quantum procedures while others are accelerated using pure classical processing.

[0128] The processing of the code in Figure 19 also highlights the function of recursive processing which is stage 6 of compiler 12. Recursive functions are refactored, simplified, classified, and replaced. Similar processing is applied to recursive functions and function calls, refactoring them into a sequence of simpler function calls and then classifying each and replacing (where possible) with a more efficient procedure that achieves the same final result.

[0129] The processing of the code in Figure 19 also highlights the functions, quantum data structures, and low - level algorithms of stage 7 of compiler 12. Where possible, data types are implemented using quantum processing. Data types such as vectors, arrays, matrices, graphs, queues, etc. are implemented using quantum states and quantum algorithms for processing, providing a better performance trade - off for computations than what is classically possible.

[0130] Stages 5 - 7 of compiler 12 operate in any order for constructing a quantum algorithm. Any one or more of loop processing (stage 5), recursive processing (stage 6), and data structures (stage 7) are used to construct such a quantum algorithm, and these basic techniques (loop processing, recursive processing, and data structures) are used in any order to generate such a quantum algorithm. As used herein, a quantum algorithm is any algorithm that specifies one or more gate sequences to be executed on a target quantum processor.

[0131] Compiler 12 of the present disclosure utilizes Carbon as a high - level language, but the present disclosure is not so limited. As described above, compiler 12 analyzes loops, recursion, and data types. Thus, in some embodiments, compiler 12 can be used to simulate code written in any classical programming language that uses loops, recursion, or data types (e.g., C, C++, Python, Ruby) using a quantum simulator, or compile it into code that can be directly executed on a target quantum processor.

[0132] Referring again to FIG. 19, if the classical code was written more efficiently, it is very likely that the problems addressed by the code in FIG. 19 could be classically processed in a more efficient way. However, the point of comparison is actual code against actual code. When input code is given in Carbon, compiler 12 determines whether this input code can be converted into quantum code that takes significantly less time to execute than if the same code were compiled and executed on a classical computer.

[0133] There are situations where quantum codes do not provide dramatic speedups. Moreover, the full tolerance, the overhead from the full tolerance, can cause the loss of algorithmic-level speedups. Additionally, whether there is a quantum speedup ultimately depends on the nature of the quantum target processor on which the code will be executed. For example, there are some operations that the closest-neighbor quantum architecture cannot execute as fast as a fully connected quantum architecture. Moreover, there are limitations to quantum architectures that are meant to be fully connected, such as ion traps. At some point, it is simply that a connection graph beyond a certain size does not necessarily have to be more straightforward. In particular, for quantum systems such as optical quantum systems. In such quantum systems, any qubit can interact with only a fixed number of other qubits, but the qubits used for quantum operations in such a system can be at any physical address of the system. Therefore, the interaction graph can be derived for such a system that is much more suitable for long-distance communication while still having a certain degree in terms of, for example, the number of neighbors of each qubit.

[0134] Different quantum processors have different performance when dealing with quantum RAM (qRAM). qRAM is described in Dervovic et al., arXiv:1802.08227v1 [quant-ph] February 22, 2018, which is incorporated herein by reference. For example, one of the things that goes on in the background when performing HHL-type operations on a matrix data structure, or a tensor data structure, is the use of qRAM. However, some quantum processors do not have qRAM. In such cases, in order to execute a quantum algorithm that typically requires qRAM to execute on a quantum processor that does not natively support qRAM, the compiler 12 determines whether a performance gain over classical computing is still achieved if qRAM is synthesized from instructions available on the quantum device. For example, to synthesize qRAM on a quantum processor that does not natively support qRAM, an address register and a return register can be constructed from gates within the quantum device, so that a set of qubits can be assigned to be pointer registers that point to addresses in memory, and another set of qubits can be assigned to be its return, and then a sequence from a series of Fredkin gates (Fredkin and Toffoli, 1982, “Conservative Logic,” International Journal of Theoretical Physics. 21(3-4), pp. 219-253, which is incorporated herein by reference) or an analog that performs the function of qRAM can be constructed. However, the noise from such a complex set of gates is likely to degrade performance more than the digital equivalent. Also, such a process results in a linear overhead because it is a linear chain. On the other hand, when the code calls an operation that is not a linear chain like a square lattice, in fact, in some embodiments, the compiler 12 speeds up the quantum implementation over the classical implementation. The speedup may not necessarily be the exponential speedup achieved with the HHL-type algorithm.In some embodiments, the speedup for quantum implementation over classical implementation by compiler 12 is square root speedup due to overhead. For example, in some embodiments, the speedup for quantum implementation over classical implementation by compiler 12 is square root speedup for QRAM type queries, which is neither O(n) nor logarithmic time. The square root is not as much of a speedup, but the square root events are still smaller than the linear speed that would be required in the classical system for some operations. Moreover, in the case of a three-dimensional array, the quantum implementation by compiler 12 is, in some embodiments, a cube root event or equivalent, depending on the connectivity between qubits that depends on the quantum device.

[0135] There will be some classical algorithms that compiler 12 cannot speed up. In some such embodiments, compiler 12 will obtain the described code, send algorithms or instructions that can be efficiently executed on a classical machine to the classical processor, and then send algorithms or instructions that can be speeded up by encoding in a quantum data structure or quantum algorithm to the quantum processor.

[0136] In some embodiments, compiler 12 compiles on a per-function basis if possible, constructs a tree of elements that depend on each other, and within that tree, determines what levels should be placed on what quantum processors. If several different quantum processors are available to compiler 12, the compiler determines how to split the task between the quantum processors, which pieces of the tree of elements are most suitable for which quantum processors, and which pieces of the tree of elements are not quantum-mechanically speedable and should only be done classically, and within those, which should be directed to the graphics processing unit while which should be done on the digital central processing unit. Moreover, parallelization is also considered. For example, the elements within the tree of elements can be parallelized, and multiple target processors are used, if there are 10 classical target processors to use.

[0137] Compiler 12 provides different languages at each level of the compiler to handle different use cases. A gate-level language, Hydrogen, is provided because a gate-level language is required. Instead of using a generally available gate-level language such as Quill, cQASM, or Q# , Compiler 12 has its own gate-level language for which it has complete control over its extensions, because less consistent results are achieved during compilation when using a lower-level language of the convention. Helium and Hydrogen are the most used in the quantum computing community. For example, for quantum experiments where a circuit has been developed and there is a desire to try different circuits and quantum processors and for the programmer to experiment at a low level where they specify gates. At the next level up, the low-level module (Helium) provides interesting use cases that allow for appropriate optimizations. Helium allows the programmer to define subroutines and related constructs. Thus, for this type of low-level programming, Helium is a more powerful language than Hydrogen. This is useful when performing characterization-type experiments on a device and trying simple quantum algorithms, variational algorithms, etc. at an advanced gate level. Helium is a language that quantum researchers would use, like Hydrogen. Thus, the gate level of the hardware-level features of Compiler 12 is more targeted at specific hardware characterization and related topics. Therefore, using the hardware-level Hydrogen and the characterization subroutines provided by the systems and methods of the present disclosure is particularly useful for hardware companies.

[0138] Beryllium, a higher-level language, is particularly useful for quantum algorithm researchers who deal with quantum algorithms or quantum data structures. Such workers can use Beryllium to implement quantum algorithms, verify the performance of these quantum algorithms, and determine the resources required for these quantum algorithms. Moreover, such workers can use Beryllium to execute quantum algorithms in simulation. This is particularly advantageous. For example, it is difficult to actually implement a quantum algorithm in a language such as Quill or cQASM from a published quantum algorithm (e.g., during literature citation). One example is HHL. Implementing an HHL-based one is difficult in a conventional gate-level language because it requires implementing complex arithmetic and performing controlled rotations based on values stored in several qubits and needs to perform round-robin queries. Beryllium replaces all of this complex operation with just a few lines of code by providing support such as pointers to automatically handle this cumbersome implementation. There are published quantum computing papers that state that, although the most appropriate explanation can be given in detail and such operations can be performed in a certain kind of linear time, it is actually very cumbersome to come up with a way to implement them. To address this problem, Beryllium focuses on providing tools for defining non-trivial quantum data structures. This is very advantageous because it places a considerable emphasis on quantum algorithms but very little emphasis on non-trivial quantum data structures. However, there are many classical data structures, and these classical data structures are most of classical algorithms. Beryllium will make it possible to further explore quantum data structures by much reducing the effort of setting up on a target quantum processor.

[0139] Beryllium enables users to define new data structures and new data types rather by classes, which allows them to be called from higher-level (Carbon) source code. Therefore, for example, if a user wants to add a graph data type instead of standard Matlab, a new type of object is created and described in a lower-level language, because it is necessary to implement the graph data type in some kind of quantum way to utilize the quantum performance gain over classical. Therefore, when some kind of new technology is needed, a lower level is required to extend the above language using quantum definitions. Therefore, Beryllium aims to be able to write libraries that can be programmed using classical constructs. Beryllium places more emphasis on the quantum algorithm level, while Carbon places emphasis on the non-quantum level. Carbon and Beryllium are useful for people who are not experts in quantum computing, people who may want to evaluate quantum computing for future planning, and people who do not work in that field.

[0140] The point of Beryllium is to build software tools so that quantum computers can be more easily and usefully programmed, enabling a wider audience to perform useful quantum computing programming. Due to the support provided by Beryllium and the general language of compiler 12, users will be able to build more complex software. That is the point of Beryllium and Carbon to make quantum computing much more accessible by completely abstracting the quantum mechanics of aspects of quantum computing. Therefore, traditional software engineers can write quantum code that is actually useful.

[0141] Conclusions and References All references cited in this specification are hereby incorporated by reference in their entirety for all purposes to the same extent as if each individual publication or patent or patent application was specifically and individually indicated to be incorporated by reference in its entirety for all purposes.

[0142] The present invention can be implemented as a computer program product including a computer program mechanism incorporated in a non-transitory computer-readable storage medium. For example, the computer program product can include program modules shown in any combination of FIGS. 1 or 2, or described in FIG. 3. These program modules can be stored on a CD-ROM, DVD, magnetic disk storage product, USB key, or any other non-transitory computer-readable data or program storage product.

[0143] The foregoing description has been presented for purposes of illustration with respect to specific implementations. However, the above exemplary considerations are not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The implementations described herein have been chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling those skilled in the art to best utilize the invention and various implementations with various modifications as are suited to the particular use contemplated.

Claims

1. A digital computer system for compiling a computer program for a target quantum processor comprising a plurality of qubits or a plurality of quantum dits, comprising: one or more digital processors; a memory; one or more programs in the form of a compiler, wherein the compiler: (A) obtains a computer program written in a unified language and performs code refactoring on all or a part of the computer program to form a refactoring code, and converts the refactoring code into a first code, a unified level module; (B) a high-level module that compiles the first code into a second code, wherein the high-level module provides for the use of quantum gate level commands specified by the first code, and in the first code, in qubits within the plurality of qubits, or in quantum dits within the plurality of quantum dits, pointers, functions, non-unrollable loops, recursions, pointers, data structure definitions, and class object definitions, subroutines, and flow control instructions encoded, a high-level module; (C) a low-level module that receives the second code and converts the second code into a third code including a series of quantum gate level operations; a computer system comprising a program including (D) a gate level module that compiles the third code into a fourth code represented in a quantum gate level language according to the instruction set and gate locality constraints of the target quantum processor.

2. The computer system according to claim 1, wherein the unified level module performs code refactoring at least in part by replacing a source loop in the computer program written in the unified language with a plurality of loops that perform the result of the source loop in its entirety, and the complexity of each loop in the plurality of loops is smaller than the complexity of the source loop.

3. The computer system according to claim 1 or 2, wherein the unified level module performs at least partial code refactoring by replacing a source loop in the computer program described in the unified language with a plurality of loops that collectively perform the result of the source loop, and the complexity of each loop in the plurality of loops is less than the complexity of the source loop.

4. The computer system according to claim 3, wherein the unified level module performs at least partial code refactoring by analytically resolving a source loop in the computer program described in the unified language.

5. The computer system according to claim 3, wherein the unified level module performs at least partial code refactoring by replacing loops in the plurality of loops with quantum data structures.

6. The computer system according to claim 3, wherein the unified level module performs code refactoring by encoding a portion of the computer program described in the unified language and executing a quantum algorithm that performs the function of the portion of the computer program.

7. The computer system according to claim 6, wherein the quantum algorithm is an amplitude amplification quantum algorithm.

8. The computer system according to claim 5, wherein the first code defines a quantum data structure.

9. The computer system according to claim 8, wherein the quantum data structure is a set of graphs.

10. The computer system according to claim 1, wherein the unified language is limited to digital instructions.

11. The computer system according to claim 1, wherein the second code is described in a gate-level language extended with conditional statements, and the second code includes conditional statements.

12. The computer system according to claim 11, wherein the conditional statement is an if condition or a repeat condition in which an action is repeated until a predetermined condition is met.

13. The computer system according to claim 12, wherein the predetermined condition is a classical measurement result of one or more qubits or quantum dits defined by the second code.

14. The computer system according to claim 12, wherein the gate-level language is extended with support for subroutines in which a portion of the second code is repeatedly called by another portion of the second code until a predetermined result is achieved.

15. The computer system according to claim 14, wherein the subroutine is a measurement subroutine.

16. The computer system according to claim 15, wherein the measurement subroutine uses ancillary qubits or ancillary qudits within the plurality of qubits or qudits to improve measurement results.

17. The computer system according to claim 14, wherein the predetermined result is a measurement result of one or more qubits or qudits defined by the second code.

18. The computer system according to claim 11, wherein the conditional statement is an increment loop.

19. The low-level module optimizes the code within the conditional statement to form an optimized conditional statement, wherein an iteration of the code sequence specified by the optimized conditional statement has fewer instructions than an iteration of the code sequence specified by the conditional statement, and unrolls the optimized conditional statement into a series of quantum gates, and incorporates the series of quantum gates into the third code, thereby at least partially converting the second code into the third code. The computer system according to claim 11.

20. The low-level module at least partially converts the second code into the third code by optimizing a quantum operation that functions to execute a portion of the second code, thereby reducing the number of gates, qubits, or qudits in the third code required to execute the quantum operation. The computer system according to claim 11.

21. The computer system according to claim 20, wherein the second code defines qubits or qudits within the target quantum processor.

22. The computer system according to claim 20, wherein the second code defines a register of qubits or a register of qudits within the target quantum processor.

23. The computer system according to claim 22, wherein the gate-level language supports quantum bit measurement or quantum dits measurement.

24. The computer system according to claim 23, wherein the quantum gate-level language uses a plurality of different gates, and each gate in the plurality of different gates includes the name of the respective gate, the dimension of the respective gate in terms of the number of quantum bits or quantum dits, and a corresponding plurality of Kraus operators for the respective gate, and is defined in different data structures.

25. The computer system according to claim 24, wherein the corresponding plurality of Kraus operators for each gate are specified by a function handle.

26. The computer system according to claim 20, wherein the third code supports a general positive operator-valued measurement of one or more quantum bits among the plurality of quantum bits, or one or more quantum dits among the plurality of quantum dits.

27. The computer system according to claim 26, wherein a sequence of gates that implements at least a part of the third code and is different from the sequence of ideal gates is swapped with a gate synthesis that executes a sequence of gates that is different from the sequence of ideal gates but that will execute the function of the sequence of ideal gates on the target quantum processor, thereby at least partially compiling the third code into the fourth code.

28. The computer system according to claim 27, wherein the sequence of gates that is different from the sequence of ideal gates is identified by an evaluation of the stored hardware characteristics of the target quantum processor.

29. The computer system according to claim 1, wherein the compiler further includes instructions for circuit embedding of the fourth code while observing the locality constraints of the target quantum processor.

30. The computer system according to claim 29, wherein the instructions for circuit embedding of the fourth code while observing the locality constraints of the target quantum processor further include considering the determined quality of the target quantum processor when executing two subsystem gates.

31. The computer system according to claim 1, wherein the compiler further includes instructions for counting the number of gates, the number of qubits, the number of quantum dits, or the total clock time required to implement the computer program on the target quantum processor.

32. The computer system according to claim 1, wherein the compiler further includes instructions for implementing a first portion of the computer program on the target quantum processor and implementing a second portion of the computer program on a digital central processing unit or a graphics processing unit of a digital computer system.

33. The computer system according to claim 32, wherein the compiler further includes instructions for simulating the quantum code generated by the compiler on a digital central processing unit or a graphics processing unit of a digital computer system.

34. A method for compiling a computer program executable on a target quantum processor including a plurality of qubits or a plurality of quantum dits, comprising: A digital computer system including one or more digital processors and a memory, the memory including non-transitory instructions configured to execute a procedure using the one or more digital processors, the procedure comprising: (A) obtaining, by a unified level module, a computer program described in a unified language; (B) performing code refactoring on all or a part of the computer program by the unified level module to form refactored code; (C) converting the refactored code into a first code; (D) compiling, by a high-level module, the first code into a second code, the high-level module providing utilization of quantum gate level commands specified by the first code, and supporting pointers, functions, non-unrollable loops, recursions, pointers, data structure definitions, and class object definitions, subroutines, and flow control instructions encoded by qubits within the plurality of qubits or by quantum dits within the plurality of quantum dits in the first code. (E) A low-level module that converts the second code into a third code including a series of quantum gate level operations; (F) A gate-level module that compiles the third code into a fourth code represented in a quantum gate-level language according to the instruction set of the target quantum processor and gate locality constraints, the method including a digital computer system. **Claim 35** A non-transitory computer-readable storage medium storing one or more programs, the one or more programs including instructions that, when executed by a digital computer system having one or more digital processors, cause the digital computer system to (A) A unified-level module that obtains a computer program described in a unified language, the computer program being executable on a target quantum processor and including a plurality of qubits or a plurality of quantum dits; (B) The unified-level module performs code refactoring on all or a part of the computer program to form refactored code; (C) Converting the refactored code into a first code; (D) A high-level module that compiles the first code into a second code, the high-level module providing the use of quantum gate level commands specified in the first code, and supporting pointers, functions, unrollable loops, recursions, pointers, data structure definitions, and class object definitions, subroutines, and flow control instructions encoded with qubits in the plurality of qubits or with quantum dits in the plurality of quantum dits within the first code; (E) A low-level module that converts the second code into a third code including a series of quantum gate level operations; (F) A gate-level module that compiles the third code into a fourth code represented in a quantum gate-level language according to the instruction set of the target quantum processor and gate locality constraints, a non-transitory computer-readable storage medium.

Images