Systems and methods for unified computing on digital and quantum computers

Abstract

Computer systems and methods are provided for compiling computer programs for execution on a quantum processor comprising a plurality of qubit quaternions. A unified level module obtains a program in a unified language and performs code restructuring on all or a portion of the program to form restructured code and converts the restructured code to a first code. A high level module compiles the first code to a second code. The high level module supports loops, subroutines, and flow control instructions within the first code. A low level module receives the second code and converts the second code to a third code comprising a series of quantum gate level operations. A gate level module compiles the third code to a fourth code expressed in a quantum gate level language according to an instruction set and gate placement constraints of a target quantum processor.

Description

[0001] Cross-reference of related applications

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 945,434, filed December 9, 2019, entitled "Systems and Methods for Unified Computing on Digital and Quantum Computers," the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to systems and methods for providing a unified language that can be compiled and run on conventional or quantum processors. Background Technology

[0004] Quantum computing requires consideration of an architecture different from that of traditional computers. This technology necessitates a method for compiling source code written in a unified computing language into computational methods that run on quantum computers and / or conventional digital computers. Summary of the Invention

[0005] This disclosure addresses the aforementioned drawbacks by introducing a quantum compiler that compiles source code written in a unified computing language, enabling it to run on quantum computers and / or conventional digital computers.

[0006] One aspect of this disclosure provides a computer system for compiling computer programs that can run on a target quantum computer and / or digital computer comprising multiple qubits. The computer system includes one or more processors, memory, and one or more programs in the form of a compiler. The compiler includes a uniform-level module that yields computer programs written in a uniform language (e.g., Carbon).

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

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

[0009] The first code replacement for high-level quantum languages ​​is a computer program written in a unified language. High-level quantum languages ​​provide support for the definition of functions, loops, recursion, pointers, and data structures (structs) and objects (kinds). The lower levels of the compiler break these operations down into simpler ones until the code consists of individual gate operations.

[0010] 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 implementing functions and data types used by the unified-level source code, and produces second code in a low-level quantum language (helium) that allows loops, subroutines, and flow control instructions. The compiler further includes a low-level module that receives the second code, optionally optimized for performance improvements, and translates it into a series of gate-level operations, thereby forming third code. The compiler further includes a gate-level module that compiles the third code into a fourth code that optionally implements error mitigation procedures and gate synthesis, wherein the fourth code is expressed in a quantum gate-level language according to the constraints of the instruction set and the gate positioning constraints of the target quantum computer.

[0011] Another aspect of this disclosure provides a digital computer system for compiling computer programs for a target quantum processor comprising multiple qubits or multiple quantum quaternions. The computer system includes one or more digital processors, memory, and one or more programs in the form of a compiler. The compiler includes a uniform-level module that receives the computer program written in a uniform language (e.g., carbon) and performs code refactoring on all or part of the computer program to form refactored code and converts the refactored code into first code (beryllium). The compiler further includes a high-level module that compiles the first code (beryllium) into 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 third code (hydrogen) comprising a series of quantum gate-level operations. The compiler further includes a gate-level module that compiles the third code (hydrogen) into fourth code expressed in a quantum gate-level language according to the instruction set and the gate positioning constraints of the target quantum processor.

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

[0013] In some embodiments, a unified-level module performs code refactoring by replacing a source loop with multiple loops that commonly implement the results of source loops in a computer program written in a unified language, wherein the complexity (e.g., the number of instructions) of each of the multiple loops is less than the complexity of the source loop.

[0014] In some embodiments, the unified-level module performs code refactoring by analyzing and solving source loops in a computer program written in a unified language.

[0015] In some embodiments, the unified-level module performs code refactoring by replacing loops in the plurality of loops with quantum data structures.

[0016] In some embodiments, the unified-level module performs code refactoring by encoding a portion of a computer program written in a unified language to execute a quantum algorithm, which performs the functionality of said portion of the computer program. In some such embodiments, the quantum algorithm is a power-amplifying quantum algorithm.

[0017] In some embodiments, the high-level module provides access to quantum gate-level commands specified in the first code and supports pointers, functions, non-expandable loops, recursions, pointers, data structure definitions, and class object definitions encoded on qubits of the plurality of qubits or on quantum quaternions of the plurality of quantum quaternions in the first code.

[0018] In some embodiments, the first code defines the quantum data structure. In some such embodiments, the quantum data structure is a set of curves.

[0019] In some embodiments, the unified language is limited to numeric instructions.

[0020] In some embodiments, a second code is written in a gate-level language amplified with conditional statements, and the second code contains 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 a conventional measurement result for one or more qubits or quantum quaternions defined by the second code.

[0021] In some embodiments, an augmented gate-level language is used to support subroutines, wherein 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 utilizes auxiliary qubits or quantum quaternions among the plurality of qubits or quantum quaternions to improve the measurement result. In some embodiments, the predetermined result is a measurement result for one or more qubits or quantum quaternions defined by the second code.

[0022] In some embodiments, the conditional statement is an increasing loop.

[0023] In some embodiments, the low-level module converts the second code into the third code at least in part by: optimizing the code within the conditional statement to form an optimized conditional statement, wherein 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; expanding the optimized conditional statement into a series of quantum gates; and incorporating the series of quantum gates into the third code.

[0024] In some embodiments, the low-level module converts the second code into the third code at least in part by optimizing the quantum operations used to perform a portion of the second code, thereby reducing the number of gates, qubits, or quantum quaternions required to perform the quantum operations in the third code.

[0025] In some embodiments, the second code defines a qubit or a quantum quaternion within the target quantum processor. In some embodiments, the second code defines a register of qubits or a register of quantum quaternions within the target quantum processor.

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

[0027] In some embodiments, the quantum gate-level language uses multiple distinct gates. In some embodiments, each of these multiple distinct gates is defined in a different data structure, which includes the name of the respective gate, the size of the respective gate according to the number of qubits or quantum quaternions, and a corresponding plurality of Kraus operators for the respective gate. In some such embodiments, the corresponding plurality of Kraus operators for the respective gate are specified by function handles.

[0028] In some embodiments, the third code supports a general positive operator value metric for one or more of the plurality of qubits or one or more of the plurality of quantum quaternions.

[0029] In some embodiments, the gate-level model compiles the third code into the fourth code at least in part by performing gate synthesis, in which a sequence of ideal gates implementing at least a portion of the third code is interchanged with a sequence of gates that are different from the ideal gate sequence, but the functionality of the ideal gate sequence will be executed on the target quantum processor. In some such embodiments, the sequence of gates that are different from the ideal gate sequence is identified by the stored hardware representation of the target quantum processor.

[0030] In some embodiments, the compiler further includes instructions for loop embedding of the fourth code while adhering to the positioning constraints of the target quantum processor.

[0031] In some embodiments, the instructions for loop embedding of the fourth code while complying with the positioning constraints of the target quantum processor further include taking into account the determined quality of the target quantum processor when executing the 2-subsystem gate.

[0032] In some embodiments, the compiler further includes instructions for counting the number of gates, qubits, quantum quaternions, or all clock times required to implement a computer program on the target quantum processor.

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

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

[0035] Another aspect of this disclosure provides a method for compiling a computer program that can run on a target quantum processor comprising multiple qubits or multiple quantum quaternions, comprising: at a digital computer system comprising one or more digital processors and a memory, the memory including non-transitory instructions configured to execute a program using the one or more digital processors, the program comprising a computer program written in a unified language obtained at a unified-level module. The program further comprises performing code refactoring on all or part of the computer program at the unified-level module to form refactored code. The program further comprises converting the refactored code into first code. The program further comprises compiling the first code into second code at a high-level module, wherein the high-level module supports loops, subroutines, and flow control instructions within the first code. The program further comprises converting the second code into third code comprising a series of quantum gate-level operations at a low-level module, and compiling the third code into fourth code expressed in a quantum gate-level language according to the instruction set and gate location constraints of the target quantum processor at the gate-level module.

[0036] Another aspect of this disclosure provides a non-transitory computer-readable storage medium for 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 execute the program. The program includes a computer program written in a unified language obtained through unified-level modules. The program further includes performing code refactoring on all or part of the computer program through unified-level modules to form refactored code. The program further includes converting the refactored code into first code. The program further includes compiling the first code into second code through high-level modules, wherein the high-level modules support loops, subroutines, and flow control instructions within the first code. The program further includes converting the second code into third code comprising a series of quantum gate-level operations through low-level modules. The program further includes compiling the third code into fourth code expressed in a quantum gate-level language according to the instruction set and gate location constraints of the target quantum processor through gate-level modules. Attached Figure Description

[0037] Figure 1 This is a schematic diagram illustrating aspects of an example system comprising both a conventional computer system and a quantum computer according to an embodiment of the present disclosure.

[0038] Figure 2 This is a schematic diagram of a conventional computer system for compiling Unified Computing Language code into code that can run on quantum computers and / or conventional computers, according to an embodiment of the present disclosure.

[0039] Figure 3 This is a flowchart illustrating an embodiment of the present disclosure of compiling Unified Computing Language code into code that runs on a quantum computer and / or a traditional computer.

[0040] Figure 4 This illustration shows the stages of a compiler architecture for compiling Unified Computing Language code into code that can run on quantum computers and / or traditional computers, according to an embodiment of the present disclosure.

[0041] Figure 5 This illustrates a stage in a quantum compiler architecture for compiling Unified Computing Language code into code that can run on a quantum computer, according to an embodiment of the present disclosure.

[0042] Figure 6 This illustration shows the stages of a quantum compiler architecture comprising unified level, high-level, low-level, and gate-level components for compiling Unified Computing Language code into code that can run on a quantum computer, according to an embodiment of the present disclosure.

[0043] Figure 7 The illustration shows the features of each level of a quantum compiler architecture according to an embodiment of the present disclosure for compiling Unified Computing Language code into code that can run on quantum computers and / or conventional computers.

[0044] Figure 8 This illustration shows the gate-level features of a quantum compiler architecture for compiling Unified Computing Language code into code that can run on quantum computers and / or conventional computers, according to an embodiment of the present disclosure.

[0045] Figure 9 Further illustrating a gate-level feature of a quantum compiler architecture for compiling Unified Computing Language code into code that can run on quantum computers and / or conventional computers, according to an embodiment of the present disclosure.

[0046] Figure 10 Further illustrating a gate-level feature of a quantum compiler architecture for compiling Unified Computing Language code into code that can run on quantum computers and / or conventional computers, according to an embodiment of the present disclosure.

[0047] Figure 11 This illustrates how a qubit that may be considered defective according to various metrics, such as random benchmarking, can contain correctable errors that can be mitigated by gate synthesis in a gate-level module, according to one embodiment of the present disclosure.

[0048] Figure 12 The calibration and gate synthesis of an identification (non-operational) gate are illustrated according to an embodiment of the present disclosure.

[0049] Figure 13This illustration shows low-level features of a quantum compiler architecture for compiling Unified Computing Language code into code that can run on quantum computers and / or conventional computers, according to an embodiment of the present disclosure.

[0050] Figure 14 The following is further illustrated as a low-level feature of a compiler architecture for compiling Unified Computing Language code into code that can run on quantum computers and / or traditional computers, according to an embodiment of the present disclosure.

[0051] Figure 15 This invention illustrates advanced features of a quantum compiler architecture for compiling Unified Computing Language code into code that can run on quantum computers and / or conventional computers, according to an embodiment of the present disclosure.

[0052] Figure 16 This illustration demonstrates support for pointers in a quantum compiler architecture for compiling Unified Computing Language code into code that can run on quantum computers and / or traditional computers, according to an embodiment of this disclosure.

[0053] Figure 17 This illustration shows the characteristics of a unified level of a quantum compiler architecture for compiling Unified Computing Language code into code that can run on quantum computers and / or conventional computers, according to an embodiment of the present disclosure.

[0054] Figure 18 This illustrates the sources of complexity generated in Unified Computing Language code according to an embodiment of this disclosure, and how they are handled by the compiler.

[0055] Figure 19 The present disclosure shows source code that can be reconstructed using a quantum compiler architecture according to an embodiment of the present disclosure.

[0056] Figure 20 This illustrates an embodiment of the present disclosure using the disclosed compiler architecture to... Figure 19 The source code is split into discrete fragments.

[0057] Figure 21 A reconstruction according to an embodiment of the present disclosure is shown. Figure 20 The code is intended for use in quantum computing using the publicly disclosed compiler architecture.

[0058] Figure 22 illustrates the evolution of language based on existing technology.

[0059] Figure 23 A characterization of a quantum system according to an embodiment of the present disclosure is shown.

[0060] Figure 24This illustrates how the energy change between the |0〉 and |1〉 states of a particular qubit, which is a function in a quantum computing device according to an embodiment of the present disclosure, is affected by the fundamental state of the qubit in the quantum computing device coupled to the particular qubit.

[0061] Figure 25 Examples of various error mitigation techniques for a particular qubit are shown according to an embodiment of the present disclosure.

[0062] Figure 26 Examples of various error mitigation techniques for another qubit are shown according to an embodiment of the present disclosure.

[0063] Figure 27 Examples of various error mitigation techniques according to an embodiment of the present disclosure are shown.

[0064] Figure 28 This illustrates the mapping of all couplings in a quantum computing chip according to an embodiment of the present disclosure.

[0065] Figure 29 An embodiment of the present disclosure is shown to improve measurement errors in two different quantum computing chips by utilizing an auxiliary method.

[0066] Figure 30 An embodiment of the present disclosure is shown implementing a quantum data structure, such as a curve structure.

[0067] Figure 31 This invention illustrates a quantum compiler architecture according to an embodiment of the present disclosure for compiling Unified Computing Language code into code that can run on quantum computers and / or conventional computers.

[0068] Figure 32A , 32B Figures 32C and 32C illustrate the definition of a gate according to an embodiment of the present disclosure.

[0069] Figure 33A and 33B An example helium program according to an embodiment of the present disclosure is shown.

[0070] Figure 34 Gate synthesis according to an embodiment of the present disclosure is illustrated, wherein the target quantum system is a continuous-variable quantum system.

[0071] Figure 35 Gate synthesis according to an embodiment of the present disclosure is illustrated, wherein the target quantum system is a discrete-variable quantum system.

[0072] Figure 36 This illustrates a spin echo error mitigation strategy implemented according to embodiments of the present disclosure.

[0073] Figure 37A and37B This illustrates a parity-based echo error mitigation strategy implemented according to embodiments of the present disclosure.

[0074] Throughout the various views of the drawing, the same reference numerals refer to the corresponding parts. Detailed Implementation

[0075] Disclosed are computer systems and methods for compiling computer programs that can run on target quantum computers and / or digital computers comprising multiple qubits or quantum quaternions. A unified-level module of the compiler receives the computer program written in a unified language and performs code refactoring on all or part of the computer program to form refactored code, converting the refactored code into first code. A high-level module of the compiler compiles the first code into second code, wherein the second code allows loops, subroutines, and flow control instructions. A low-level module of the compiler receives the second code and converts it into third code comprising a series of quantum gate-level operations. A gate-level module of the compiler compiles the third code into fourth code expressed in a quantum gate-level language according to the instruction set and the gate positioning constraints of the target quantum processor.

[0076] Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of this disclosure. However, those skilled in the art will understand that this 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.

[0077] It should be understood that although the terms first, second, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, without departing from the scope of this disclosure, a first subject may be referred to as a second subject, and similarly, a second subject may be referred to as a first subject. Both the first subject and the second subject are subjects, but they are not the same subject.

[0078] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in the description of the invention and the appended claims, the singular forms “a” and “described” are also intended to include the plural forms, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. It will be further understood that the term “comprising”, when used in this specification, specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0079] As used herein, depending on the context, the term “if” can be interpreted as meaning “when” or “upon” or “in response to determination” or “in response to detection.” Similarly, depending on the context, the phrase “if determination” or “if detection [the stated condition or event]” can be interpreted as meaning “after determination” or “in response to determination” or “after detection [the stated condition or event]” or “in response to detection [the stated condition or event].”

[0080] Figure 1 A computer system topology 48 for providing a unified language is shown, which can be compiled and run on a conventional digital computer 60 or a quantum computer 64 including multiple qubits 102. See also Figure 1 In a typical embodiment, the topology includes a compiler computer system 100 that electronically communicates with a quantum computer 64 and a digital computer 60, both comprising a plurality of qubits 102. 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, electronic communication between the compiler computer system 100 and the quantum computer 64 is conducted via a communication network 106. In some embodiments, once compiled, the compiler computer system 100 applies appropriate quantum code 62 to the quantum computer 64.

[0081] Out of Figure 1 For the purposes of the illustrations, compiler computer system 100 and digital computer system 60 are each represented as a single corresponding computer encompassing all the functionalities of a conventional computer system. However, this disclosure is not limited thereto. The functionality of compiler computer system 100 and / or digital computer 60 can be distributed across any number of networked computers and / or reside on each of several networked computers. Those skilled in the art will appreciate that various different computer topologies of compiler computer system 100 are possible, and all such topologies are within the scope of this disclosure.

[0082] Remember the above turning point Figure 2The compiler computer system 100 includes one or more processing units (CPUs) 74, a network or other communication interface 84, a user interface 78 (e.g., including a display 82 and a keyboard 80 or other forms of input devices), a memory 92 (e.g., random access memory), one or more disk storage devices and / or persistent devices 90 optionally accessed by one or more controllers 88, one or more communication buses 12 for interconnecting the aforementioned components, and a power supply 76 for powering the aforementioned components. Data in the memory 92 can be seamlessly shared with the non-volatile memory 90 using known computing techniques such as caching. The memory 92 and / or memory 90 may contain large-capacity storage devices remotely located relative to the central processing unit 74. In other words, some data stored in the memory 92 and / or memory 90 may be effectively hosted on a computer external to the analysis computer system 100 but electronically accessible by the analysis computer system via the Internet, intranet, or other forms of network or electronic cable using the network interface 84.

[0083] The compiler computer system 100's memory 92 stores:

[0084] Operating System 8, which contains programs for handling various basic system services;

[0085] Computer programs written in Unified Language 10;

[0086] • Compiler 12, which is used to compile a computer program that can run on a target quantum computer and / or digital computer including multiple qubits or quantum quaternions, the compiler comprising: a unified-level module 14, which takes a computer program 10 written in a unified language and performs a refactoring of all or part of the computer program to form refactored code and converts the refactored code into first code (15); a high-level module 102, which compiles the first code into second code 104, wherein the second code 104 allows loops, subroutines and flow control instructions; a low-level module 106, which receives the second code 104 and converts the second code 104 into third code 108 including a series of quantum gate-level operations; and a gate-level module 110, which compiles the third code 108 into fourth code 112, wherein the fourth code is expressed in a quantum gate-level language according to the instruction set and the gate positioning constraints of the target quantum computer 64.

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

[0088] While the number of people dedicated to quantum algorithms is relatively small, the number of people with GitHub accounts and thus considered regular software engineers is vast—approximately one hundred million. Furthermore, there has been considerable experimentation regarding how to democratize programming and similar work in quantum computing. For example, companies like IBM have been working on open-source development tools and attempting to incentivize the use of their platforms, partly in the hope that this will lead to a flourishing of quantum computing algorithms. Nevertheless, the number of people currently dedicated to quantum algorithms remains small.

[0089] In the realm of quantum computing, much of it has been implemented as variational techniques—they are all relatively similar in nature. Substantially new algorithms rarely emerge from groups not yet in the quantum computing industry. While there are always truly new algorithms from people with a quantum computing background, it's not necessarily true that people working in other areas of computer science outside of quantum computing have already adopted quantum computing platforms and are contributing to new applications of quantum computing. The systems and methods disclosed herein are designed to address this shortcoming.

[0090] refer to Figure 31 This disclosure provides a novel approach. To set the background for the approach, Figure 22 provides illustrative milestones in the history of programming languages. Fifty years ago, languages ​​such as microcode and assembly became available. Over time, languages ​​with increasingly higher levels of abstraction, such as BASIC and C, emerged. Thus, programmers using Matlab or Python did not care how the processor worked. That is, programmers did not need to pay attention to any of these details, as this was always handled by the interpreter. However, C is slightly closer, and once dealing with assembly, programmers must consider the individual registers of the processor when programming in that language. The goal of the system and method of this disclosure is to abstract to a sufficiently high level that one can program both conventional and quantum computers using the same language. This brings us a step closer to the goal of broadening the access of computer scientists outside the traditional quantum computing community to quantum computers. In doing so, this makes quantum computers more accessible. Reference Figure 4 Languages ​​like Matlab and Octave are already at a high enough level to express what programmers want to implement algorithmically. Therefore, code at this level of abstraction serves as the foundation for code subsequently compiled to utilize quantum algorithm techniques running on quantum computers, achieving the performance advantages of the same code running on a purely digital computer. See also... Figure 5 The basic steps for achieving this objective according to the systems and methods of this disclosure are to create an abstract representation 504 of the initial code using some conventional source code 502 (e.g., written at a level of abstraction typical of programming languages ​​such as Matlab or Octave). In some embodiments, the syntax tree is constructed from the initial code when doing so. Based on the abstract representation, an attempt is made to construct a quantum algorithm 506, which is then transformed into a loop representation 508, the loop representation 508 is transformed into a local loop 510 for the quantum computing device, and finally, into whatever local operation is available for the device. Thus, element 512 could represent the output as 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: For a Common Quantum Assembly Language”, arXiv: 1805.09607v1 [quant-ph]), or possibly represent the output as a sequence of pulses.

[0091] Figure 7 Broadly speaking, it shows Figure 6 The implementation method. A compiler consisting of four different levels is provided. At the base level, there is a gate-level language (hydrogen, gate-level modules). hydrogen (third code) is gate-focused. helium (second code) can be considered quantum BASIC. helium still performs gate operations, but also provides basic loops, conditional statements, and subroutines. Based on its ability to execute structs and functions of various kinds, beryllium (first code) can be considered equivalent to quantum C. The highest level is a common subset of Matlab and Octave called carbon. carbon is a traditional language that can run on traditional digital computers. See also Figure 6 Observing how the publicly disclosed compiler works, there are four levels. At the highest level, the traditional code (carbon) can run directly on a traditional digital central processing unit or graphics processing unit. As compilation progresses to lower levels (along...), ... Figure 6(The stack), the remaining languages ​​are all quantum at decreasing levels of abstraction. beryllium is a fairly high level and supports functions, classes, structs, and pointers. Below beryllium exists helium, which can be viewed as quantum BASIC and supports subroutines and loops. beryllium allows resource capture, such as estimating resources for a particular algorithm, post-quantum cryptography, and predicting which resource bags will be used for a particular algorithm. beryllium allows programmers to encode quantum programs without specifying instructions at the gate level, while still allowing code optimization. In this way, beryllium can be used to perform resource counting without having to extend everything to a large number of gates. Continue to refer to Figure 6 At the lowest level, there exists a gate-level language (hydrogen), which literally specifies, on a quantum-gate-by-quantum basis, what operations the quantum computing device will perform to execute the algorithm specified by the higher-level language. Hydrogen directly interfaces with the quantum computing hardware.

[0092] To solve computational problems using a quantum computer, not only a quantum computer is needed, but also software capable of using it to solve the problems. Advantageously, the systems and methods disclosed herein provide programming tools not only for the quantum community but also for conventional software engineers interested in using quantum computers to solve computational problems.

[0093] Now presented in reverse order Figure 6 The quantum compiler shown in the diagram starts from the front of the hardware, moves up to the gate level, then to the low-level and high-level quantum languages, and finally converts traditional code into quantum code.

[0094] Characterization and compilation.

[0095] This chapter represents and compiles [the following]. Figure 31 Phase 30, Characterization. Characterization routines are disclosed for generating profiles of various quantum processors considered at the compiler level by the systems and methods of this disclosure.

[0096] See Figure 23The reason why the systems and methods of this disclosure address the issue, starting with hardware and characterization, is that gates implemented in commercially available quantum chips (such as the Regetti and IBM quantum chips) are not perfect. They exhibit noise and errors. Furthermore, this noise is not the simple kind that theorists like to consider. It is not independent identically distributed (iID) noise, depolarization noise, or amplitude-damped noise. Thus, it is helpful to know what the quantum device is actually doing in order for the quantum code to function well. For example, there are various errors introduced in the quantum system relative to the error. Some gates applied to the quantum system are miscalibrated by the quantum system. For example, a rotation implemented on the quantum system as part of a unit gate may rotate to a different angle than expected and end, but it is still a unit gate. This is a case where the characterization of the quantum system is directly helpful. If we know what the gate is doing when implemented in a particular quantum chip, rather than what it should be doing, better results can be compiled. Thus, it is advantageous to keep track of these characterizations and consider them during the quantum compilation process. Furthermore, in many cases, the noise is non-Markovian and can be balanced to some extent. For example, there are various ways to decouple it, or simply calibrate the quantum system in a slightly different way to account for some broadening observed in the spectrum. Thus, causal characterization is performed according to some embodiments of the systems and methods of this disclosure, such that the characterization can be fed back to lower levels of the compiler so that the quality of the gates can be taken into account when attempting to embed the loop into a quantum processor. For example, not all CZs or CNOTs are created equal. Some are better than others, and some operations are cheaper than others in terms of the overall error budget if gate synthesis is performed. Thus, the characterization occurring according to the systems and methods of this disclosure is designed to take this into account. Furthermore, the characterization is used to account for unit error and to generate the best possible operation.

[0097] Figure 11 An example is provided from a 32-qubit Regetti chip. When performing a Ramsey experiment with qubits, a good cosine curve is observed for the gradual decay of most qubits, but one qubit (1102) shows a different pattern. Figure 11 Other qubits in the grayscale comparison do not exhibit periodic behavior. It is unclear what is happening with qubit 1102. Qubit 1102 could be considered a bad qubit, containing some error, and should never be used. However, investigation revealed that qubit 1102 is actually very close to a pure state. It is well initialized, and what is happening is that the operation being performed on the qubit itself does not begin at the correct initial stage, and the operation is incorrect. That is, a sequence of operations is being performed using the qubit, but these are different from the intended operations, and therefore produce undesirable results. However, if this information were known, characterization could be used to attempt to consider this.

[0098] Figure 24 Another example is provided, illustrating the practical results of mitigating stray coupling within a quantum device. Common in superconducting processors, individual qubits are essentially coupled to each other (e.g., using Ising interactions), but this should not be the case here. Thus, the general effect is that the gap between the |0> and |1> states of a corresponding qubit has a specific value when the interacting neighbor is in the |0> state, but if the interacting neighbor is in an excited state (|1>), it has the effect of changing the operational level of the corresponding qubit. In other words, the amount of energy required to change the corresponding qubit from the |0> state to the |1> state changes. Thus, if the interacting neighbor and the corresponding qubit are each in their respective |1> state, one limit of the energy graph is achieved, and if the interacting neighbor and the corresponding qubit are each in their respective |0> state, different limits of the energy graph are achieved. Furthermore, more than one interacting neighbor may exist. Figure 24 This is merely an example of a case where only one interactive neighboring qubit exists. If a qubit is in an entangled state, widening occurs and an undefined gap exists between |0> and |1>, which causes problems. The problem arises because if a qubit is placed alone in the |1> state, it will begin an accumulation phase depending on the state of its neighbor. Most of the time, regardless of the calibration process, it is assumed that the neighbor is in the |0> state. Thus, this calibration assumes that the neighboring qubits in the device are in the |0> state, and in this case, performing an x-rotation or a y-rotation perfectly makes the corresponding qubit go from |0> to |1>, turning it off at resonance, but as the state of the qubit adjacent to the corresponding qubit changes, decoherence is triggered because there is superposition between the neighboring qubit and the corresponding qubit. Figure 12 As shown. Figure 12 This is an example of real data obtained from the Regetti Q32 aspen-7 chip. Figure 12 On the left, the joint Ramsey experiment is shown. A single qubit is prepared in a superposition of |0> and |1>, allowing for a certain amount of time of processing before another rotation. After this, without an accumulation phase, the qubit should be at the computational basis |0>. However, each of the qubits has a certain natural frequency, thus causing some hysteresis. Furthermore, for… Figure 12The curves shown have been rotated to achieve a clearer representation. Therefore, one of the curves shown in the plot is executed with a specific adjacent qubit in |0>, and the other curves are executed with said adjacent qubit in |1>. Thus, the curves show how the frequency shifts when adjacent qubits are in |0> and |1>, and this represents a change in the gap. Thus, in some cases, this change in the gap is appropriately small, approximately several kilohertz. In other cases, it rises to approximately 35 kHz coupling on the Regetti chip. Up to 150 kHz has been observed on the IBM chip. Furthermore, these gaps can be... Figure 12 The diagram shown on the right side is for a given quantum processor. Figure 12 The right-hand side shows the test maxima between different pairs of qubits on a single processor to establish the mapping where stray couplings lie. For example... Figure 12 As shown in the right panel, stray coupling often occurs between the closest neighbors. Figure 12 The positions of the vertices in the middle (right side) are their physical locations on the chip. However, there are some strong couplings between those that are not the closest neighbors.

[0099] In the `hydrogen` class, there exist command wait(time) [addr1, ..., addrk] and wait(time) that cause the target quantum system to refrain from applying any gates on the indicated subsystem (the qubits or quantum quaternions specified by addr1, ..., addrk) or on all qubits for a specified time period (the time parameter in parentheses). See below. Figure 25 and 26 This will describe a situation in a non-ideal quantum system where, during this waiting period, a certain condition actually occurs. Thus, the "wait" is not as effective as intended. In the Rigetti and IBM systems, it has been found that some small Z-rotations occur on each qubit, and some small Ising (ZZ) interactions occur between some qubit pairs. Figure 12 The right side of the neutralization Figure 28 The thickness of the line in the graph indicates the strength of this undesirable coupling. Figure 25 and 26 The plot in the image illustrates the results of applying several mitigation strategies to attempt approximate equivalent values ​​of hydrogen command wait(t)[q] for q=0 and q=33 (two different qubits in the Rigetti Aspen-7 processor), but similar behavior exists in most (non-photon) quantum processors. For Figure 25 and 26 Error mitigation techniques are used to ensure that nothing happens to the qubit within a certain time period, but for... Figure 25 and 26 The same publicly disclosed technology can be used during more interesting operations.

[0100] Figure 25 An example of error mitigation techniques performed according to the system and method of this disclosure is shown. Curve 2502 represents the original qubit and indicates the probability of recovering a particular quantum state as a function of time (in microseconds). A quantum state is prepared, a certain amount of time is allowed to pass, and then an attempt is made to try to recover the original quantum state. But when doing so, all other qubits in the device are superimposed. Therefore, the qubits are out of phase due to these stray couplings. This disclosure provides various ways to deal with this problem. The first and simplest way is to update the frame. As mentioned above, when calibrating quantum devices, they are often calibrated under the assumption that neighboring qubits are in the |0> state. Thus, the duration of the gate pulse is calibrated based on the assumption that neighboring qubits are in the |0> state. Therefore, between the |0> state and the |1> state, when all neighbors are in the |0> state is quite close to the pulse actually used. However, if the neighboring qubits are placed in the |1> state, the corresponding qubit is at another limit of the energy map, as described above. Figure 24 The discussion focuses on the significant energy changes that occur. A good strategy for addressing this issue is to assume that if all qubits on the quantum chip under consideration become part of the computation, they may be entangled with other qubits and it will be unknown whether they will be in the |0>-|1> state. In these cases, it can be assumed that they are in the |0>-|1> state with equal probability or better, and therefore the observed bandgap should not be considered a limiting value achieved by measuring when neighboring qubits are in the |0> state. In fact, a bandgap should be chosen that falls between the observed range of when all neighboring qubits are in the |0> state and when all neighboring qubits are in the |1> state.

[0101] Curve 2504 (frame update) illustrates what happens when this bandgap is selected in the middle of the observed range. In this approach, wait(t)[q] is replaced by rz(w*t)[q]. This means adding a small time-dependent Z-rotation to the qubit. This is done via a frame update in the pulse control software on the Rigetti system. Figure 25 (as illustrated), but it can be changed to be directly synthesized in the gate synthesis module of compiler 12 (as shown in the diagram ...). Figure 31 The process will take place at stage 25.

[0102] Curve 2504 decays more slowly than curve 2502 (the original). For curve 2504, dephasing still occurs, but because the pulse sequence has been set under the assumption that the bandgap of the corresponding qubit is in the middle of its range, some coherent rotations are not being picked up. In contrast, curve 2502 dips slightly and begins to rise again because coherent rotations are effectively occurring at the top of the dephasing, due to the fact that the pulse sequence of curve 2502 is calibrated at one limit of the bandgap range, rather than at the center as in the case of curve 2504.

[0103] Alternatively, a spin echo method can be used, where a qubit is allowed to evolve for a certain amount of time, flips, is allowed to evolve for the same amount of time again, and then the flip is reversed. This decouples any Ising interaction from the qubit, thus providing curve 2508 exhibiting slower decay. Curve 2506 is produced when this decoupling occurs, but with alternating sets of qubits flipping. Alternating qubit flips decouple each qubit from each other, rather than just a specific qubit decoupling from its neighboring qubits. If all qubits flip simultaneously, all those couplings remain the same; they are decoupled from the environment, not from each other. Dividing them into two groups and determining which one to flip based on which set it belongs to produces curve 2506. Therefore, according to this second error mitigation technique, qubits are periodically flipped 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 decoupling pulses can also be used. This produces... Figure 25 Curves 2506 and 2508. According to... Figure 36 The example code shown, curve 2508, represents the performance when only qubit q is flipped. This achieves much better performance for the target qubit, but not for the other qubits. A more complex procedure to improve all address selections instead of just the wait(t)[addr1, ..., addrk] for q is to select a subset of qubits to flip at different time points. Because the strongest undesirable coupling is between even-numbered and odd-numbered qubits, in Figure 25 In the demonstration, only the odd-numbered qubits were flipped, resulting in curve 2506. The Hydrogen code for each of the two versions of this error correction technique is... Figure 36 As shown in curves 2508 (collection echo) and 37 (curve 2506, based on parity echo). In some embodiments, Figure 25 Any of the error mitigation techniques shown, or their equivalents, are automatically applied to the gate synthesis module of compiler 12. Figure 31 It can be applied separately in stage 25 or before being output to the target quantum system.

[0104] Figure 25 The image shows a qubit zero on the Aspen-7 device, calibrated at a specific time. However... Figure 25 The qubit is not the one that shows the greatest difference across various calibration techniques.

[0105] Figure 26 The typical differences seen on the Aspen-7 device are shown. Figure 26This is an example of a qubit that cannot be well represented on the original device. Thus, in this case, curve 2602 is the original effect: preparing a qubit in an additive state, letting it rest for a certain amount of time, and then measuring it again, thus effectively performing a Hadamark and measuring it. Curve 2602 drops very rapidly below 50%, but actually rises back up because it is picking up coherent Z-spin (which it shouldn't), but this is an effect of the Ising coupling to other qubits on the quantum computing chip.

[0106] Continue to refer to Figure 26 The frame update method produces curve 2604, which has already provided a significant improvement of up to about 30 or 40 microseconds. At this point, decoupling (curves 2606 and 2608) again performs much better. Therefore, curves 2606 and 2608 are significantly better than either curves 2602 or 2604. Considering the wait time for reaching the recovery state with a 70% probability as a metric for comparison, the original strategy (curve 2602) and if a decoupling strategy is adopted (based on parity echoes, curve 2606, Figure 37; or one echo set, curve 2608), Figure 36 There are significant differences between any of them. Therefore, different methods significantly alter the lifetime of qubits on quantum computing chips.

[0107] In the above discussion, the term Ising is intended to represent CZ coupling. That is, there is no specific mechanism for coupling. Paired tomographic scans between qubits of varying durations have been observed, thus revealing how each term in the density matrix changes over time, with its effective quantity being the ZZ term. See also... Figure 12 If we consider qubit 14, there are contributions from qubits 1, 15, and 13. Thus, for example, if we only consider qubits 15 and 14, there is very strong ZZ coupling, but dephasing is also observed, partly caused by coupling to qubit 13 and partly by coupling to qubit 1. If we plot these entries over time, we can see that the dephasing is a non-Markovian chain, causing it to decrease more slowly than initially expected, followed by a pick-up rate. This indicates that the coupling between qubits is coherent. Relaxation and other forms of error exist, but the coupling is extremely significant. Therefore, Figure 25 and 26 The decoupling method shown in the figure improves the lifetime of qubits used to perform quantum operations.

[0108] See Figure 26 Another reason for the coupling, obviously, is that when a simple spin echo is performed (where the qubit is flipped halfway through the time sequence and then flipped back), the sequence very effectively cancels the coupling.

[0109] To further calibrate the quantum computing chip, it is useful to measure where all stray couplings are located on the quantum computing device. While it would be desirable to decouple all qubits on the device, the problem is that this approach is not feasible. Running the same decoupling sequence on each qubit would not decouple them from each other, but rather from the environment. To decouple the qubits from each other, a different sequence would need to be performed on each qubit. However, the gates required to achieve this take a very long time compared to the coherence time (T²). Thus, it is necessary to decouple the qubits without using a very large number of gates. For this purpose, it is helpful to know which qubits are coupled to which other qubits. While performing a joint Ramsey experiment between each pair of qubits as an alternative seems reasonable, on a real device, to obtain sufficient statistics, the experiment would need to be run continuously for more than a day. The problem is that these parameters change and drift over time, so by the time the Ramsey experiment is complete, the measurements are no longer valid. Thus, for it to be useful, it is necessary to be able to take all measurements within about half an hour and then update the parameters on the device, update the frame for each qubit, and design a decoupling pulse sequence that is implemented over several hours, and then recalibrate again. There is not enough time to perform pairwise measurements for this purpose. Therefore, some embodiments of the systems and methods disclosed herein are aimed at exciting all qubits, exposing them to the natural Hamiltonian system for varying amounts of time, then measuring these qubits and then attempting to decouple all pairs of qubits. Thus, what previously took several thousand runs can be reduced to about seven runs on a Rigetti Q32 Aspen-7 QPU, which is useful. At least on the Rigetti system, a side effect is that it appears to take longer on larger chips, due to some compilation that occurs just before the run, and the effect is that the process runs the same number of frames on a larger chip slower than on a smaller chip or sublattice, which is why... Figure 28 The coupling curves shown are slightly noisy. Figure 28 In this process, coupling between unit cells has been ignored in order to improve visibility, but it has been observed that... Figure 28 The couplings from the latest chip are shown in several frames, where all couplings have been plotted using the systems and methods disclosed herein.

[0110] Compared to Figure 31 In stage 29, in some embodiments, the gates, quantum quaternions, and other resources required for the loop are counted. In some embodiments, the wall clock time is estimated based on quantum processor specifications.

[0111] Hydrogen Figure 3 Element 212).

[0112] From hardware-level mobility, attention shifts Figure 31The low-level programming used in stages 20-27 and 29. See also Figure 8 This disclosure provides gate-level modules utilizing a low-level programming language nominally called hydrogen. hydrogen is a gate-level language in which quantum operations to be performed and optionally, the hardware addresses where these quantum operations are to be performed are specified. Quantum bits are dynamically assigned, specifying parameters such as rz gates, and this is then compiled into code suitable for the hardware. If a specific hardware address for a quantum operation has not yet been specified, the qubit assignment is changed to attempt to find the optimal assignment, for example, minimizing the number of swaps that must be performed within computation.

[0113] See the example code for hydrogen. Figure 9 The right-hand panel structures the Hydrogen programming language. That is, the language is defined by structured text files. The format is command_name(param1, ..., paramN)[addr1, ..., addrM], where "->" indicates the command return value. Quantum bits are defined according to gates. For example, in some embodiments, each gate is defined in a separate text file, and new operations can be added by editing the text file by adding Kraus operators for those gates.

[0114] For example, refer to Figure 9 Under the limitation Figure 9 In the case of using the CNOT(a,b) gate at row 7 on the right, in a data structure that provides the gate name "CNOT", the number of dimensions on the subset system, and the appropriate Kraus operator, Figure 9 The CNOT gate is specified in the middle panel. Here, "dim_in:2 2" means that the first subsystem has dimension two and the second subsystem has dimension two. To constrain how the CNOT gate interacts with, for example, qubits, the appropriate Kraus operator for CNOT operations is specified: [1 00 0; 0 1 0 0; 0 0 0 1; 0 0 1 0].

[0115] As another example, Figure 9 Line 10 of the code on the right side requires h[a]. In some embodiments, h[a] is defined in a separate data structure as:

[0116] h{

[0117] dim_in:2

[0118] dim_out:2

[0119] kraus:[0.7071067811865475 0.7071067811865475; 0.7071067811865475 -0.7071067811865475]

[0120] }

[0121] In other words, the data structure is given the name "h", the dimension is specified ("dim_in:2"; "dim_out2"), and it is limited to the Kraus operator used for h[a].

[0122] Turn Figure 9 The "measure" instance at line 11 on the right-hand side of the code indicates that compiler 12 supports Positive Operator Value Measurement (POVM). Therefore, any set of Kraus operators corresponding to the traditional output can be specified. Figure 9 In the measurement instance at line 11 on the right side, the gate name (“measure”), the number of dimensions (“dim_in:22”; “dim_out:2 2”), and the Kraus operator used for the measurement gate (“Kraus:[1 0]->0”; “Kraus[0 1]->1”) are in Figure 9 The data structure is specified in the separate data structure shown in the middle panel.

[0123] In addition, see Figure 9 On line 14 of the code on the right-hand side, compiler 12 supports parameterized gates, where the Kraus operator is given by the function handle. This generates the Kraus operator when a value is passed to the parameter and allows compiler 12 to implement arbitrary parameterized gates. Therefore, the code rz(0.3927)[b] passes the parameter value 0.3927 to Figure 9 The rz gates defined in the middle panel. In some embodiments, compiler 12 calls these function handles to generate Kraus operators at runtime for whatever parameters have been specified by the gates.

[0124] Figure 32A , 32B 32C shows the definition of an instance of a gate set. Figure 32A , 32B Any of the gates specified in Figure 32C can be called by the hydrogen code to implement the desired gate as part of the quantum algorithm. Furthermore, Figure 32 illustrates how new gates can be easily defined and added using a general format:

[0125] instruction{

[0126] dim_in:subsysdim1 subsysdim2...subsysdimM

[0127] dim_out:subsysdim1 subsysdim2...subsysdimM

[0128] kraus:krausl(->output1) ...

[0130] kraus:krausN(->outputN)

[0131] }

[0132] See Figure 10 One advantage of using function handles is that it makes it easier to change the quantum hardware instruction set associated with different quantum devices. This is due to... Figure 31 Element 25 is indicated. This is useful because the set of natural gates varies between quantum devices. For example, an ion trap with its Molmer Sorensen gate differs from the Kraus reference gate in a superconducting qubit, which in turn differs from the Knill-Laflamme-Milburn (KLM) gate in an optical system. For illustration, this can be defined for each instruction set of each quantum system that will be used by the quantum program (e.g., as...). Figure 9 (As shown in panel 902) Different language files.

[0133] For example, Figure 9Panel 902 shows a subset of the standard set of gates as seen in Nielsen and Chuang, Quantum Computing and Quantum Information (2010, Cambridge University Press, New York), which is hereby incorporated by reference. These gates are defined in one embodiment of this disclosure because they are largely intuitive to operate. Next, beyond the standard gates, hydrogen can be used to define additional gates associated with a particular target quantum device. Then, the calibration techniques discussed in the calibration section above are used to fill in Kraus operators for each operation available on the quantum device. Thus, instead of having Kraus operators associated with ideal operations at the physical level, some embodiments of the systems and methods of this disclosure use the calibration techniques discussed above to ascertain what is actually happening within the target quantum device. In some examples, this results in one set of instructions referencing the desired ideal gate (e.g., CNOT), while another set of instructions refers to the actual counterpart of the ideal gate considering the characterization of the particular quantum system. Thus, when the quantum code requires a CNOT instruction on the target quantum processor, the actual quantum gate implemented on the target quantum processor may have parameters that differ from the ideal CNOT gate given the characterization of the target quantum process. One advantage of having these different instruction sets (e.g., the ability to specify different instruction sets) is that it allows for the exploration of different types of quantum processors, not just qubits. Furthermore, this approach supports the development of novel gates or hardware-specific gates. Additionally, this approach allows for the synthesis of conversion instruction sets using gates (e.g., from one type of quantum device to another).

[0134] Therefore, in the case of hydrogen, there exists an ideal gate that the user wants to execute, and for each corresponding ideal gate, there exists a corresponding gate that a particular quantum processor will actually execute when the ideal gate is invoked. hydrogen converts the sequence of ideal gates into a sequence of corresponding gates specific to a particular quantum processor to obtain the same result as the sequence that implements the ideal gates, or a result with the highest possible fidelity. Thus, hydrogen is able to support different gates and only defines these different gates in a structured text file, thereby making it possible to work with different instruction sets and convert between them.

[0135] The following provides information based on Figure 31 Phase 25 involves swapping an instance of the gate set. Consider an example program written in helium code:

[0136] #This is a note

[0137] qubit->1

[0138] qubit->2

[0139] h[1]

[0140] cnot[1,2]

[0141] rz(0.3)[1]

[0142] measure[1]->1

[0143] measure[2]->2

[0144] Thus, this code serves as the hydrogen-level compiler for compiler 12. Figure 10 Instruction 1002.

[0145] Figure 34 The gate synthesis is illustrated, where the target quantum system is a continuous-variable quantum system. Therefore, Figure 34 The code for element 1004 corresponds to Figure 10 The element 1004, and based on the instruction 1002 provided above, provides the set of input gates for definition 1004. Figure 34 The code for element 1006 corresponds to Figure 10 The elements 1006, and provide the set of output gates for the definition 1006 of the target continuous variable quantum system.

[0146] Figure 34 The code for element 1008 corresponds to Figure 10 Element 1008, and based on the given instructions 1002 above and Figure 34 The output gate set definition 1006 provides synthesis instructions 1008 for target continuous variable quantum systems.

[0147] Figure 35 The gate synthesis is illustrated, where the target quantum system is a discrete-variable quantum system. Therefore, Figure 35 The code for element 1004 corresponds to Figure 10 The element 1004, and based on the instruction 1002 provided above, provides the set of input gates for definition 1004. Figure 35 Definition 1004 of the input gate set and Figure 34 The same applies because the set of input gates defined in 1004 does not yet take into account gates that the target quantum system can efficiently handle or that are locally supported. Figure 35 The code for element 1006 corresponds to Figure 10 The element 1006, and provides the set of output gates for the definition 1006 of the target discrete variable quantum system. Figure 35 Definition 1006: The set of output gates relative to a specific gate or gate parameters relative to Figure 34 The output gate set of definition 1006 is different because the output gate set of definition 1006 considers the characterization of gates or doors that the target quantum system can locally support or effectively dispose of. Figure 35 The code for element 1008 corresponds to Figure 10Element 1008, and based on the given instructions 1002 above and Figure 35 The output gate set definition 1006 provides synthesis instructions 1008 for target discrete-variable quantum systems. Similar to output gate set definition 1006, Figure 35 The synthesis instruction 1008 is different Figure 34 Although both implement the same established instruction 1002. Figure 34 and 35 This demonstrates the ability of gate-level module 110 to switch between sets of gates when the target quantum system changes.

[0148] In gate synthesis ( Figure 31 In stage 25), the compiler 12 automatically converts the individually operable descriptions between one instruction set and another. This can be used to address systematic errors in the target quantum system. For example, consider a loop C expressed using ideal (textbook) operations. For instance:

[0149] qubit->1

[0150] qubit->2

[0151] h[1]

[0152] cnot[1,2]

[0153] If run on ideal quantum hardware, this code should generate maximally entangled states. But quantum hardware is not ideal. Thus, if the quantum hardware is instructed to follow an exact input loop, it will produce the correct states inaccurately due to small errors in each operation. What can be done is to characterize the target quantum hardware to obtain a description of the quantum channels applied to the quantum system when a specific command is sent. For example, if the target quantum system is sent command h[1], the result may be that the target quantum system actually applies some other operation h'. Because this operation is different between qubits (unlike ideal gates), the actual operation applied is called h1 when the given operation is Hadamard(h) on the first qubit, and h2 when the given operation is Hadamard on the second qubit of the target quantum system. Similarly, suppose cnot12 is the true (imperfect) operation applied when the cnot command is sent between qubits 1 and 2 to the target quantum system, and suppose rz1(θ) and rz2(θ) are the true (imperfect) operations applied when instructing the target quantum system to perform Z rotations on qubits 1 and 2 via angle θ, respectively. The goal is to approximate C as closely as possible using the sequence of operations rz1, rz2, h1, h2, and cnot12. This is generally a solvable optimization problem.

[0154] See Figure 31In stage 24, in some embodiments, the processing is indicated to follow the positioning constraints of the quantum processor, optionally taking into account the mass of the 2-subsystem (e.g., 2-qubit) gate. In some examples, according to Figure 31 The loop embedding procedure 24, when routing qubits around the target quantum chip, can take into account the quality of the 2-qubit gate to minimize undesirable coupling.

[0155] Can be Figure 31 Phases 24, 25, and 26 are reordered. Relative to... Figure 31 In stage 25, in some embodiments, gate synthesis techniques are used, and there is a conversion between the instruction set used in the low-level language / internal representation and the instruction set used by the hardware. See also Figure 31 In stage 26, in some embodiments, the code is scanned to obtain the opportunity to reduce the instruction count within the loop segment (or improve another user-specified metric).

[0156] Helium Figure 3 Element 210).

[0157] See Figure 13 as well as Figure 31 In stages 14-19, the compiler 12 utilizes a programming language referred to herein as helium, moving up and down the hierarchy. Helium is supported by low-level module 106 of compiler 12. Helium acts as a form of quantum BASIC. Low-level module 106 parses the helium source files (secondary code) to create a parse tree and extract an abstract syntax tree.

[0158] like Figure 13 As shown in the example helium code, helium can be used to create new qubits or quantum quaternions using the general form qubit->variable, or registers with a fixed number of qubits or quantum quaternions. Figure 13 Lines 1-3 of the helium code provide an example of this situation.

[0159] like Figure 13 As shown in the example helium code, helium has the same instructions as gate-level languages ​​but it expands with conditional statements. For example, see... Figure 13 The example of helium code, lines 5-7, demonstrates that helium supports "if" loops. "If" loops allow control of qubits using "if" statements. They can also use a similar syntax to set conditions for traditional variables. For traditional control, the control hardware must support this functionality or allow custom control code. Another example of an "if" loop supported by helium is:

[0160] if[a]

[0161] cnot[b,c]

[0162] end

[0163] like Figure 13 As shown in lines 9-11 of the helium code, helium supports repetition, where actions are repeated until a predetermined condition is met (e.g., a traditional measurement result). Therefore, Figure 13 Lines 9-11 of the code are a repeating loop monitoring the measurement results, where, in effect, the while loop continues execution until a condition is met that defines a specific measurement result. This is not compileable to a loop and would result in a program that requires implementing control flow logic (e.g., FPGA-based pulse sequencing and readout processing) on ​​conventional hardware for controlling quantum computing. The repeat until loop monitoring the measurement results has a general form:

[0164] repeat

[0165] operation

[0166] until [measurement outcome]

[0167] Another example of this type of repeat loop is:

[0168] repeat

[0169] h[b]

[0170] rz(u)[c]

[0171] h[c]

[0172] until[a]

[0173] like Figure 13 As shown in lines 13-18 of the example helium code, helium also supports subroutines. A subroutine can be defined as a self-contained block of code and then called from the main program. The general form of a subroutine definition is:

[0174] sub SubName

[0175] Operation 1

[0176] Operation 2

[0177] endsub

[0178] like Figure 13 As shown in line 10 of the example helium code, in order to call a subroutine in the main program, the syntax gosub SubName is used. Figure 13Lines 9-11 of the code repeatedly call the subroutine defined by lines 13-18 of the instance helium code until the measurement result is achieved [a].

[0179] Helium also supports a form of simple loop, referred to in this paper as an "increment loop," which is based on a variable incrementing from "one" to a specific integer value, such as... Figure 13 The code "increment k to 8" in the code shows an integer increment from K to 8. When the loop first passes through, starting at line 14 of the code, K has a value of one. The next time the loop is passed, K has a value of two, then three, then four, and so on until eight. This command increments the value of a conventional variable, and the gate for each loop pass depends on this variable. The general form of this loop has the following syntax:

[0180] Increment k to LoopSize

[0181] gate1(k)[target qubit]

[0182] gate2(parameter)[k] ...

[0184] next

[0185] Another example of an increment loop in Helium is:

[0186] Increment k to 12

[0187] h[k]

[0188] cnot[k,6]

[0189] t[k]

[0190] rz(k)[k)

[0191] next

[0192] Helium also supports readout. For example, a single measurement of a quantum system / qubit can be performed via a command with the following general form:

[0193] measure[qubit name]->variable

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

[0195] Figure 33A Another example of the helium program is shown, which defines qubits a, b, and c and then calls an increment loop that executes a series of gates. Finally, qubit a is measured. Figure 33B Another example of the helium program is shown, where qubits a, b, and c are specified. Then, variable u is set to 9. Next, the 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, subroutine tests are executed, followed by subroutine test 2. Each of these subroutines executes the specified gate. Figure 33A and 33B The example programs in the example demonstrate support for comments using the # symbol. Comments are not parsed by the compiler. What makes helium unique is its complete focus on quantum processors and their controlled hardware. It does not focus on digital computers. Unlike IBM Qiskit, where loops are run in Python to construct circuits, helium focuses on what should happen on the quantum processor. Loops do not run on the quantum processor; they are unrolled before running on it. The reason for this structured approach is that it allows for optimization within the loops. For example, if there is a loop that will be called many times, it allows calling an optimization subroutine to run on the current program with the loop to try to optimize what is happening within the loop so that the loop doesn't have to be unrolled many times. For example, to understand whether a specific action within the loop can be performed only once instead of every time, the loop is entered incrementally. This has advantages. For example, if the quantum program has a large number of gates and the optimization identifies a specific action within the loop that only needs to be performed the first time the loop is traversed, the entire loop does not need to be unrolled to produce a large-scale circuit. Therefore, the low-level modules of the compiler supporting helium code appear to be exactly within the conditional block, exactly within the repeat loop, and optimized within these increment loops before expansion, in order to reduce the complexity of the expanded loops. This involves optimizing the code within the conditional block to form an instance of the optimized conditional block, and determining whether the iteration of the code sequence specified by the optimized conditional block has fewer instructions than the iteration of the code sequence specified by the conditional block before expanding the optimized conditional block into a series of quantum gates.

[0196] The `repeat until` instruction is not supported by currently publicly accessible systems. In principle, this feature of helium allows quantum programs with indefinite runtimes. For example, it doesn't necessarily terminate after a set number of gates (e.g., 27 gates); it can run for a longer time depending on the measurement results.

[0197] Figure 14 Examples of some optimized subroutines within the low-level modules that provide support for the helium source code. Figure 14A quantum Fourier transform (QFT) 1402, an incrementing procedure 1404, and then an inverse QFT 1406 are performed for a total of 53 gates. When this is helium-coded and compiled by a low-level module of the compiler of this disclosure, as a result of the loop optimization subroutine 1408 of the low-level module, the 53 quantum gates are reduced to only three quantum gates 1410.

[0198] See Figure 29 Another thing supported by helium and its associated low-level modules is the definition of subroutines. For example, it can be used to define measurement subroutines. For single-qubit or two-qubit experiments, it is often the case that many target quantum chips have many additional qubits, whether these are superconducting chips, ion traps, or others. When this is the case, the measurement subroutines can be made more precise by utilizing these additional unused qubits for the measurement subroutines. For example, it can be used as an aid during measurement. Thus, instead of measuring a single target qubit, fan out from the qubit with CNOTS to some auxiliary qubits, and then measure those auxiliary qubits along with the single target qubit. Error correction can then be applied to see if they all give the same result, or error correction can be used to take a majority vote. Figure 29 The top panel compares the performance of zero (uncoded), one, and two auxiliaries on an early Regetti chip and an Aspen-4. The specific qubit used has an uncoded error rate of 9%, which is a reasonably high measurement error. CNOT also has a high error, but some of the errors that occur are in the form of dephasing errors on the qubit, which, for example, do not affect the measurement results because the dephasing is ultimately exchanged with the measurement of the qubit. Thus, it can eventually fan out several times. In this way, a pseudo-copy is formed on the Regetti device, and the results are compared. If zero-zero or one-one is obtained, it is compared with the actual state of the qubit. In this way, it can be seen that if one auxiliary is used, an improvement of 3% on average for the post-selection is achieved, and if two auxiliaries are used, an improvement of up to 2% on the post-selection is achieved. Thus, this form of measurement subroutine supported by helium is useful. Accordingly, more robust measurements can be made each time the experiment is run, without having to consider how to implement the fan-out each time. In fact, the measurement subroutine handles these details.

[0199] Similarly, see Figure 29The lower part of the experiment involved attempting the same operation with an IBM QX4. A specific qubit on a specific day was tested with this operation, exhibiting an uncoded error rate of 19%. Using two auxiliary qubits and majority vote error correction, thus eliminating the discarding of results and the need for post-selection, performance improved from 19% to 12%. Using four auxiliary qubits improved performance to 10%. This demonstrates diminishing returns, as the error rate is ultimately promoted rather than suppressed if sufficient CNOT is not performed. However, compared to... Figure 29 Consistently, most quantum systems from these quantum systems exhibit at least a twofold performance gain, and in some cases more.

[0200] See Figure 31 In stage 18, the program written in helium, along with conventional control flow (which is generally not expressible as a quantum circuit), is transformed into a set of quantum circuit fragments (expressible as hydrogen), which specifies how these circuit fragments are pieced together when run on hardware based on measurements obtained during computation. This representation can be used for general quantum computing, but there are many cases where this would simply be equivalent to a single quantum circuit. The final output of the compiler is a finite state machine to control the behavior of a system that governs the signals sent to the hardware. However, there are many cases where conventional control logic is avoided and quantum circuits or pulse sequences are output only in a suitable instruction set (but the most general form of computation requires a fully finite state machine). See also Figure 31 In stage 19, the code can optionally be scanned to gain the opportunity to reduce the instruction count within the loop segment (or improve another user-specified metric). See also Figure 31 In stage 28, the output of low-level module 108 can run on a simulator instead of a quantum processor.

[0201] beryllium Figure 3 Element 208).

[0202] See Figure 15 and Figure 31In stages 8-13, attention now turns to the beryllium language supported by this component of high-level module 102 and compiler 12. High-level module 102 parses beryllium source files (first code) to create parse trees and extract abstract syntax trees. beryllium can access gate-level commands, but it also supports function and struct definitions and allows non-expandable separable loops. An example of a separable loop is a "for" loop, where a split occurs if a certain condition is met. In this instance, the compiler cannot determine in advance how many times the loop needs to be run before calling the split. An example use case for this is wanting to coherently split the loop, meaning traversing the loop a certain number of times, exiting the loop, entering another loop a certain number of times, exiting the loop, and then finally performing a measurement. In this instance, the total runtime is known, but the number of times each loop is traversed is unknown. There is a superposition of different possible numbers of traversals of each loop, as long as the total runtime is fixed.

[0203] beryllium supports pointers. Figure 16 Here is one example where this situation is useful. See also... Figure 16 Instead of passing specific parameters to the gate, traditional parameters such as angles, address ranges, or sets of addresses can be passed. The code then observes the values ​​stored in the address ranges and performs the gate based on those values. 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 performed with the rotation specified by the address range. Thus, Figure 16 The beryllium code line is shown, where qubits A and B specify the angle αZ rotation (RZ gate) to be performed on qubit C. This requires setting up and implementing a large number of gates. This is difficult to do. This operation is a key component of the HHL algorithm (Harrow et al., 2009, “A Quantum Algorithm for Solving Linear Systems of Equivalences,” Physical Review Letters, 15, 150502) and is extremely difficult to implement because the gate sequence is hard to set up. With beryllium, this can be done on runtime for any gate. For example, given a Matlab function specifying the Kraus operator for a particular unit gate, the range of parameters to be used, and the number of qubits to be read (as a set of addresses), the high-level module 102 can automatically generate the loop that implements the controlled rotation.

[0204] See Figure 30Another reason for having the high-level programming language beryllium is to begin implementing quantum data structures. In other words, implementing data types allows the use of quantum states to store data types or quantum algorithms to manipulate data types, attempting to achieve a better trade-off than what can be done conventionally. While the quantum community has focused a lot on algorithms, it hasn't focused much on quantum data structures and implementing quantum data types. However, the fact is that utilizing different data types from quantum mechanics can outperform comparable conventional (digital) implementations of these data types in many cases. Therefore, beryllium allows for more freedom in choosing how data is structured. Thus, instead of more complex algorithms, one can instead define a specific quantum data structure, to which instructions for simply applying specific manipulations of the quantum data structure are appended. As another example, one can define a quantum data structure that always stores the results in all possible outputs of interest to a particular quantum computation, thereby simplifying the output.

[0205] However, there exists a dichotomy, in which two distinct tasks cannot be performed quickly. To illustrate this, Figure 30 This illustrates the case where the simplest possible data structure is used to store the curve. The simplest data structure is one that stores the vector as a state vector, which forms the basis of HHL-type algorithms. In HHL algorithms, the real-valued vector must be manipulated by the quantum computer. That is, it must be loaded into a computation register, where the elements of the vector are encoded in the amplitudes of the quantum state. As the quantum state is normalized, these amplitudes will be the elements of the vector scaled according to the norm of the vector. See Dervovic et al., arXiv:1802.08227v1[quant-ph], February 22, 2018, which is hereby incorporated by reference.

[0206] A more complex quantum data structure is one that stores curves as sets of curves. This data type allows for direct local edge completion, such as... Figure 30 As shown in the top left corner, for a given vertex a, an edge is drawn if there is no edge between adjacent vertices, and is removed if an edge exists. Using this data structure, this operation can be performed around individual vertices in O(1). Storing curves as a set of curves also allows for edge completion within the set. If a subset of vertices is selected, all edges between them can be completed in linear time. In contrast, this would require quadratic time in most common conventional curve representations. However, quantum data structures that allow this to be done in O(1) can be constructed.

[0207] Edge completion between sets is also possible. Given two distinct sets in a curve, all edges between them can be completed in linear time using a quantum data structure. Curve comparisons are also possible, where two curves are compared in linear time with a constant success probability using a quantum data structure, regardless of the curve size. Vertex comparisons in O(1) time can also be performed using a quantum data structure.

[0208] Automorphism testing is also possible, where a specific operation is tested to see if it is an automorphism on the curve. This can be performed with a constant success probability in the time it takes to perform the automorphism. If there are 2n copies of these, it can be conventionally read out to output the curve. It takes only O(n) qubits to store, where n is the number of vertices. Thus, fewer qubits are needed to store the adjacency matrix, which is a linear number of copies required to obtain the recovery. For a particular pair of operations (e.g., vertex comparison in O(1) and local edge completion in O(1)), no conventional data structure can match this performance. While there are conventional data structures that allow either of these to occur in O(1), there are no conventional data structures that allow both to be performed in O(1), and in fact, the average would be linear. In any case, if the complexity of vertex comparison is averaged with the complexity of local edge completion, the best operation that can be done conventionally is O(n). Thus, this provides the motivation for why beryllium supports structs and classes, enabling the use of various different kinds of quantum data types that utilize quantum mechanics rather than the conventional. This directly led to the release of the high-level language Carbon.

[0209] See Figure 31 In stage 13, during the compiler workflow, the code may be optionally scanned for the opportunity to reduce the instruction count (or improve another user-specified metric) by making local changes within the program.

[0210] Carbon Figure 3 Elements 202 to 206).

[0211] See Figure 17 as well as Figure 31 Phases 1-7 now shift attention to the Carbon language supported by this component, the Unified Level Module 14 and the Compiler 12. In some embodiments, the Unified Level Module 14 parses Carbon source files to create parse trees and extract abstract syntax trees. In some embodiments, Carbon provides a subset of Matlab and Octave functionality. (Settings are missing from the original text.) Figure 17The left panel displays example Carbon code. Carbon allows users to write conventional code to solve quantum problems presented as scripts written in the Carbon language. In some embodiments, compiler 12 compiles the Carbon code into a high-level quantum language (beryllium), and then into a lower-level language (helium, hydrogen, or a sequence of gates). In some embodiments, compiler 12 compiles directly to the lower-level language (helium, hydrogen, or a sequence of gates). Figure 31 The components of compiler 12 shown in stage 12 handle this transformation.

[0212] The goal of compiler 12 is to take this conventional code and ultimately use compiler 14’s unified-level module 14, high-level module 102, low-level module and gate-level module 110 to transform the conventional code into a set of quantum gates that implement quantum tasks but have fewer operations than those originally specified by conventional quantum computing procedures.

[0213] Figure 18 This illustrates a method for generating this set of quantum gates that accomplish tasks with fewer operations. Two things slow down quantum code: explicit complexity and implicit complexity. Compiler 14 provides a set of tools to address both forms of complexity in order to generate a set of quantum gates that accomplish tasks with fewer operations.

[0214] Explicit complexity refers to the inherently slower steps that the programmer hard-codes into the code. An example of this is specifying a loop that will be repeated a million times. In this case, the loop will be repeated a million times because the programmer has already told the computer to execute the loop a million times. Explicit complexity also arises from recursive algorithms that call functions within functions within functions. This recursion will traverse any number of recursion levels until it terminates. In both instances, the programmer has created a large number of instructions from a relatively small amount of code.

[0215] Another aspect of generating complexity is the implicit cost of operations, such as multiplying matrices together. While a single line of code can be written in programs like Matlab or Carbon to multiply matrices together, the complexity of the resulting matrix multiplication scales efficiently with the cube of the matrix size. Most implementations of this operation are cubic time, or near cubic time, simply because better complexity scans have a large number of antecedent factors.

[0216] The approach taken by compiler 12 is to refactor, where possible, code that results in explicit complexity so that it no longer possesses that explicit complexity, thus transforming it into implicit complexity, and then taking care of the implicit complexity by using a better implementation of the data type. For example, this can be achieved by using quantum algorithms to take care of some functions that result from the transformation of explicit complexity into implicit complexity. Figure 19 An example of this method is shown. Figure 19 Here is an example of Matlab code. Lines 1-7 of the code recursively constrain a specific matrix. Therefore, in lines 3-7, each i-th entry of the matrix is ​​constrained. Lines 9-11 of the code constrain and set some constants. Next, lines 13-19 of the code constrain a loop that finds the hottest position in the heatmap matrix constrained by lines 1-7. Finally, lines 24-28 of the code constrain another loop that moves along the diagonal of the array until the value on the diagonal exceeds five, at which point process control is decoupled from the loop.

[0217] when Figure 19 When the code shown is compiled by compiler 12, the compiler breaks the loop in an attempt to simplify it. Figure 20 As shown. Compiler 12 separates the complex loop to make it a simpler loop. Therefore, instead of being... Figure 19 The code lines 13-19 define a composite loop; there are now two simpler loops. Figure 20 Lines 13-15 and 17-22 in the example. This is the complete opposite of what happens when building optimized compilers for traditional computing. Traditional compilers typically try to concatenate small loops to minimize branch conditions and reduce the probability of making incorrect branch predictions.

[0218] Turn Figure 20 In addition to rearranging complex loops into simpler loops, the compiler also performs some reordering of comparisons and if statements. Next, compiler 12 categorizes the loops. See also... Figure 21 The first loop (loop 2102) recursively limits the ij-th entry of the matrix. Because HHL (Harrow et al., 2009, "A Quantum Algorithm for Solving Linear Systems of Equality") is needed where possible, the matrix is ​​stored not as an explicit repository containing the values ​​of each element, but as an oracle database that returns the ij-th element given ij. That is, instead of having loop 2102, a function is provided that, given ij, provides the ij-th entry of the heatmap. This can be achieved without ever traversing the "for" loop. A closed-form expression can be found by implementing a closed-form way of solving this, which computes the ij-th entry of the heatmap without recursion.

[0219] Next, see Figure 21 Element 2104, again, there exists a relationship that can be found for the second loop and analyzed and solved, so it is exactly the type of loop that can be analyzed and solved.

[0220] Figure 21 The loop 2106 can be used as a quantum maximum search decoder. The loop seeks the limit value, and this appears frequently in the code.

[0221] Figure 21 Loop 2108 is a sequential search. Thus, these are not directly Grover searches, but can be constructed using capability amplification (a form of quantum computing) to construct maximum search 2106 and sequential search 2108. The loop being analyzed (element 2104) runs much faster due to the data type used for the matrix, taking logarithmic time, rather than the 9998 squared time that would traditionally be twice as long. Therefore, as implemented by compiler 12, the solution is executed in logarithmic time (9998). The two searches 2106 and 2108, implemented by compiler 12, provide quadratic speedup. The end result is that compiler 12 produces a quantum algorithm and a quantum loop with virtually 300,000 fewer operations than at the algorithm level (e.g., assuming the quantum system is noise-free and not considering complete tolerance for overhead). This demonstrates that compiler 12, capable of reaching quantum algorithms from conventional code, solves computational problems with far fewer operations. In instances where quantum algorithms do not speed up code because satisfactory or better solutions exist, compiler 12 compiles to a conventional processor rather than a quantum process. For example, if the source code computes priorities, then truly good conventional algorithms already exist for calculating priorities, and the current quantum algorithm is not a better one. This is an instance where the quantum algorithm or quantum data structure will not be able to speed up the program, and therefore priority computation is relegated to a conventional processor target.

[0222] Depend on Figure 19 The processing of the composite loops defined in lines 13-19 of the code is an instance of stage 5 of compiler 12, loop processing. Loops are refactored, simplified, classified, and replaced. Loops are processed to identify independent instructions and separate them into sets of simpler loops. These simpler loops are then classified based on their effects: whether they have an effect only when a specific condition is met, whether they are recursively defined, etc. The loops are then replaced by different programs that achieve the same result more efficiently. There are various types of these loops. Some types of loops (maximum search, recursive array / matrix definition, sequential search) are replaced by quantum programs, while others are accelerated using purely conventional processing.

[0223] Figure 19The code processing also highlights the functionality of stage 6 of compiler 12: recursive processing. Recursive functions are refactored, simplified, categorized, and replaced. Similar processing is applied to recursive functions and function calls, refactoring them into a sequence of simpler function calls, and then categorizing each one and replacing it with a more efficient program that achieves the same end result (where possible).

[0224] Figure 19 The code processing also highlights the capabilities of stage 7 of compiler 12, including quantum data structures and low-level algorithms. Where possible, quantum processing is used to implement data types. Data types such as vectors, arrays, matrices, curves, and queues are implemented using quantum states and quantum algorithms for processing, resulting in a performance trade-off that is better than could be achieved traditionally.

[0225] Compiler 12 operates in any order through stages 5 through 7 to construct quantum algorithms. Any one or more of the loop processing (stage 5), recursive processing (stage 6), and data structures (stage 7) are used to construct these quantum algorithms, and these fundamental techniques (loop processing, recursive processing, and data structures) are used in any order to produce these quantum algorithms. As used herein, a quantum algorithm is any algorithm that specifies one or more sequences of gates to be executed on a target quantum processor.

[0226] While the compiler 12 of this disclosure utilizes Carbon as the top-level language, this disclosure is not limited thereto. The compiler 12 analyzes loops, recursion, and data types as described above. Accordingly, in some embodiments, the compiler 12 is used to compile code written in any conventional programming language (e.g., C, C++, Python, Ruby) that utilizes loops, recursion, or data types into code that can be simulated by a quantum simulation program and can be run directly on the target quantum processor.

[0227] Return to view Figure 19 If traditional code has already been written more efficiently, it is very likely that it will be replaced by... Figure 19 The problems solved by the code can traditionally be handled in a more efficient way. However, the point of comparison is real code versus real code. Given input code in the form of carbon, compiler 12 determines whether it can be converted into quantum code, which takes significantly less time to run compared to compiling and running the same code on a conventional computer.

[0228] There exist cases where quantum code does not provide a significant speedup. And this is entirely tolerable; the additional overhead from complete tolerance might terminate algorithm-level speedups. Furthermore, the existence of quantum speedups depends on the nature of the quantum target processor that will ultimately run the code. For example, there are some operations that nearest-neighbor quantum architectures cannot perform as fast as fully connected quantum architectures. Moreover, there are limitations to quantum architectures that should be fully connected, such as ion traps. At some point, simply because a connection graph exceeding a certain size does not necessarily need to be simpler. Specifically, consider quantum systems such as optical quantum systems. In these quantum systems, each qubit only needs to be able to interact with a constant number of other qubits, but the qubits used for quantum operations in these systems can be located at any physical address in the system. Thus, interaction curves better suited for long-range communication can be derived for these systems while still maintaining a constant level in terms of, for example, the number of neighbors per qubit.

[0229] Different quantum processors exhibit varying performance when processing quantum RAM (qRAM). qRAM is described in Dervovic et al., arXiv:1802.08227v1[quant-ph] (February 22, 2018), which is hereby incorporated by reference. One of the things happening in the background when performing HHL-type operations on matrix data structures (e.g., or more complex data structures) is the use of qRAM. However, some quantum processors do not have qRAM. In such instances, in order to execute quantum algorithms that typically require running on qRAM on a quantum processor that does not natively support qRAM, compiler 12 determines whether a performance gain exceeding that of conventional computation can still be 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, address registers and return registers can be constructed from gates within the quantum device. Thus, a set of qubits can be assigned as a pointer register pointing to an address in memory, and another set of qubits becomes its return register. This can then be constructed from a sequence of Fredkin gates (Fredkin and Tofoli, 1982, “Conservative Logic,” International Journal of Theoretical Physics, 21(3-4), pp. 219-253, which are hereby incorporated by reference) or similar structures that will perform the function of qRAM. However, noise from this composite set of gates can potentially make its performance worse than a digital equivalent. Furthermore, this process is linearly chained, and therefore introduces linear overhead. On the other hand, if the code calls are not linearly chained operations (e.g., square lattice), then in some embodiments, compiler 12 actually accelerates the quantum implementation over the conventional implementation. The acceleration may not necessarily be an exponential speedup achieved with an HHL-type algorithm. In some embodiments, the speedup of the quantum implementation relative to the conventional implementation by compiler 12 is a square root speedup due to the overhead. For example, in some embodiments, the speedup of the quantum implementation by compiler 12 compared to the conventional implementation for QRAM-type queries is a square-root speedup, rather than O(n) or logarithmic time. While the square-root speedup is not as significant, the square-root event is still less than the linear speed required for some operations on a conventional system. Furthermore, in the case of a three-dimensional array, the quantum implementation by compiler 12 is a cubic-root event or equivalent in some embodiments, depending on the connectivity between the qubits that the quantum device depends on.

[0230] There are some conventional algorithms that compiler 12 cannot accelerate. In some such embodiments, compiler 12 takes written code and sends algorithms or instructions that can be efficiently executed on conventional machines to a conventional processor, and then the algorithms or instructions can be accelerated to a quantum processor by encoding them in quantum data structures or quantum algorithms.

[0231] In some embodiments, compiler 12 compiles function-by-function, where possible, to build a tree of interdependent elements, and within that tree, determines on which quantum processors to place them and at what level. If several different quantum processors are available to compiler 12, the compiler determines how to split the task among the quantum processors, which fragments of the element tree are best suited for which quantum processor, and which fragments of the element tree are not quantum-accelerated mechanically and should only be executed conventionally, and even among those, which should be pushed off to the graphics processing unit compared to execution on a digital central processing unit. Furthermore, parallelism is considered. For example, if the elements in the element tree are parallelizable and there are 10 conventional target processors to be used, then multiple target processors are used.

[0232] Compiler 12 provides different languages ​​for each level of the compiler, handling different use cases. The gate-level language `hydrogen` is provided because a gate-level language is required. Instead of using publicly available gate-level languages ​​such as Quill, cQASM, or Qsharp, compiler 12 has its own gate-level language, allowing for complete control over its extensions and avoiding highly inconsistent results during compilation when using conventional lower-level languages. `helium` and `hydrogen` are the most widely used languages ​​in the quantum computing community. For example, to perform quantum experiments, where circuits are developed and different circuits and quantum processors need to be tried, experiments are conducted at a low level where the programmer specifies the gates. Moving up and down, the low-level module (Helium) provides interesting use cases that allow for good optimization. `helium` allows the programmer to define subroutines and related structures. Therefore, for this kind of low-level programming, `helium` is a more powerful language than `hydrogen`. It is useful for performing characterization-type experiments on devices, trying simple quantum algorithms, variable algorithms, etc., at advanced gate levels. `helium`, similar to `hydrogen`, is the language that quantum researchers will utilize. Therefore, the gate-to-hardware-level features of compiler 12 are more geared towards specific hardware characterization and related topics. Thus, the hydrogen-to-hardware-level features, utilizing the characterization subroutines provided by the systems and methods of this disclosure, are particularly suitable for hardware companies.

[0233] The higher-level language beryllium is particularly suitable for quantum algorithm researchers working on quantum algorithms or quantum data structures. Using beryllium, these researchers can implement quantum algorithms, see how they perform, and determine the resources they require. Furthermore, they can use beryllium to run quantum algorithms in simulations. This is especially advantageous. For example, it is difficult to implement quantum algorithms from publicly available quantum algorithms (e.g., cited in literature) into languages ​​such as Quill or cQASM. One example is HHL. Anything based on HHL is difficult to implement in regular gate-level languages ​​because it requires complex arithmetic, controlled rotations based on values ​​stored in some qubits, and circular queries. beryllium replaces all of this complex number operation with a few lines of code because the language provides support such as pointers to automatically handle this cumbersome implementation. There are operations in publicly available quantum computing papers that obscure the details and state that these operations can be completed in some linear time, but actually trying to figure out how to implement them is very tedious. To address this problem, beryllium focuses on providing tools to constrain non-zero quantum data structures. This is highly advantageous because there is significant focus on quantum algorithms, but very little on non-zero quantum data structures. However, many traditional data structures exist, and they constitute a large part of traditional algorithms. Beryllium will allow users to explore quantum data structures more extensively by greatly reducing the burden of setting them up on target quantum processors.

[0234] Beryllium allows users to essentially define new data structures and data types based on their categories, making them callable in the source code at a higher level (carbon). For example, if a user wants to add a graph data type instead of just standard Matlab, they create objects of the new type written in a lower-level language because leveraging a certain advantage of quantum performance relative to conventional methods requires implementing the graph data type in some quantum way. If a new technique is needed to perform this process, then the lower level needs to extend the language upwards to access quantum definitions. Thus, Beryllium aims to enable the writing of libraries that can be programmed using conventional constructs. Beryllium focuses more on the quantum algorithm level, while Carbon focuses on the non-quantum level. Both carbon and beryllium are useful for those who may want to evaluate future plans for quantum computing but are not quantum computing experts or work in the field.

[0235] The key point of Beryllium is building software tools that make quantum computers easier and more useful to program, allowing a wider audience to perform useful quantum computing programming. Thanks to the support provided by Beryllium and (generally) compilers, users will be able to build more complex software. That is, the key point of Beryllium and Carbon is making quantum computing more accessible by completely abstracting away the quantum mechanics aspects of quantum computing. Therefore, regular software engineers can write actually useful quantum code.

[0236] Conclusions and References

[0237] All references cited in this document are incorporated herein by full citation and, for all purposes, to the extent that each individual publication, patent, or patent application is specifically or individually indicated to be incorporated herein by full citation for all purposes.

[0238] This invention can be implemented as a computer program product including a computer program mechanism embedded in a non-transitory computer-readable storage medium. For example, the computer program product may contain... Figure 1 or any combination of 2 shown or Figure 3 The program modules described herein. These program modules may be stored on CD-ROM, DVD, disk storage products, USB keys, or any other non-transitory computer-readable data or program storage products.

[0239] For illustrative purposes, the foregoing description has been described with reference to specific embodiments. However, the above illustrative discussion is not intended to be exhaustive or to limit the invention to the precise forms disclosed. In view of the above teachings, many modifications and variations are possible. The embodiments described herein were selected and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to best utilize the invention and its various embodiments with various modifications suitable for the particular intended use.

Claims

1. A digital computer system for compiling computer programs for a target quantum processor comprising multiple qubits or multiple quantum quaternions, the computer system comprising: One or more digital processors; Memory; as well as One or more programs in the form of a compiler, wherein the compiler includes: (A) A unified-level module that obtains a computer program written in a unified language, performs code refactoring on all or part of the computer program to form refactored code, and converts the refactored code into first code; (B) A high-level module that compiles the first code into a second code, wherein the high-level module provides access to quantum gate-level commands specified in the first code and supports pointers, functions, non-expandable loops, recursions, data structure definitions and class object definitions encoded on qubits of the plurality of qubits or on quantum quaternions of the plurality of quantum quaternions in the first code, as well as support for subroutines and flow control instructions within the first code; (C) A low-level module that receives the second code and converts the second code into third code comprising a series of quantum gate-level operations; and (D) A gate-level module that compiles the third code into a fourth code expressed in a quantum gate-level language according to the instruction set and the gate positioning constraints of the target quantum processor.

2. The computer system of claim 1, wherein the unified-level module performs code refactoring at least in part by replacing the source loop with a plurality of loops that commonly implement the results of source loops in the computer program written in the unified language.

3. The computer system of claim 2, wherein the complexity of each of the plurality of loops is less than the complexity of the source loop.

4. The computer system of claim 3, wherein the unified-level module performs code refactoring at least in part by analyzing and solving source loops in the computer program written in the unified language.

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

6. The computer system of claim 3, wherein the unified-level module performs code refactoring by encoding a portion of the computer program written in the unified language to execute a quantum algorithm, the quantum algorithm performing the functionality of the portion of the computer program.

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

8. The computer system of 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 curves.

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

11. The computer system of claim 1, wherein the second code is written in a gate-level language augmented with conditional statements, and wherein the second code includes conditional statements.

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

13. The computer system of claim 12, wherein the predetermined condition is a conventional measurement result for one or more qubits or quantum quaternions defined by the second code.

14. The computer system of claim 12, wherein the gate-level language is augmented with support for subroutines, wherein 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 of claim 14, wherein the subroutine is a measurement subroutine.

16. The computer system of claim 15, wherein the measurement subroutine utilizes auxiliary qubits or quantum quaternions of the plurality of qubits or quantum quaternions to improve the measurement results.

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

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

19. The computer system of claim 11, wherein the low-level module converts the second code into the third code at least in part by: The code within the conditional statement is optimized to form an optimized conditional statement, wherein iterations of the code sequence specified by the optimized conditional statement have fewer instructions than iterations of the code sequence specified by the conditional statement. The optimized conditional statement is expanded into a series of quantum gates, and the series of quantum gates are incorporated into the third code.

20. The computer system of claim 11, wherein the low-level module converts the second code into the third code at least in part by optimizing quantum operations used to perform a portion of the second code, thereby reducing the number of gates, qubits, or quantum quaternions required to perform the quantum operations in the third code.

21. The computer system of claim 20, wherein the second code defines a qubit or quantum quaternion within the target quantum processor.

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

23. The computer system of claim 22, wherein the gate-level language supports qubit or quantum quaternion measurement.

24. The computer system of claim 23, wherein the quantum gate-level language uses a plurality of different gates, wherein each of the plurality of different gates is defined in a different data structure, the different data structure including the name of the corresponding gate, the size of the corresponding gate in terms of the number of qubits or quantum quaternions, and a corresponding plurality of Kraus operators for the corresponding gate.

25. The computer system of claim 24, wherein the respective plurality of Kraus operators for the respective gates are specified by function handles.

26. The computer system of claim 20, wherein the third code supports a general positive operator value measure for one or more of the plurality of qubits or one or more of the plurality of quantum quaternions.

27. The computer system of claim 26, wherein the gate-level model compiles the third code into the fourth code at least in part by performing gate synthesis, wherein in the gate synthesis, a sequence of ideal gates implementing at least a portion of the third code is interchanged with a sequence of gates different from the sequence of ideal gates, but the function of the sequence of ideal gates is executed on the target quantum processor.

28. The computer system of claim 27, wherein the sequence of gates, which is different from the sequence of ideal gates, is identified by the stored hardware representation of the target quantum processor.

29. The computer system of claim 1, wherein the compiler further includes instructions for loop embedding of the fourth code while complying with the positioning constraints of the target quantum processor.

30. The computer system of claim 29, wherein the instructions for loop embedding the fourth code while complying with the positioning constraints of the target quantum processor further include taking into account the determined quality of the target quantum processor when executing the 2-subsystem gate.

31. The computer system of claim 1, wherein the compiler further comprises instructions for counting the number of gates, qubits, quantum quaternions, or all clock times required to implement the computer program on the target quantum processor.

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

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

34. A method for compiling a computer program capable of running on a target quantum processor comprising multiple qubits or multiple quantum quaternions, comprising: In a digital computer system comprising one or more digital processors and memory, the memory includes non-transitory instructions configured to execute a program using the one or more digital processors, the program comprising: (A) Obtain computer programs written in a unified language using unified-level modules; (B) Refactoring all or part of the computer program using the unified-level module to form refactored code; (C) Convert the refactored code into first code; (D) The first code is compiled into a second code using a high-level module, wherein the high-level module provides access to quantum gate-level commands specified in the first code and supports pointers, functions, non-expandable loops, recursions, data structure definitions and class object definitions encoded on qubits of the plurality of qubits or on quantum quaternions of the plurality of quantum quaternions in the first code, as well as support for subroutines and flow control instructions within the first code; (E) Convert the second code into a third code comprising a series of quantum gate-level operations using a low-level module; and (F) The third code is compiled into a fourth code expressed in a quantum gate-level language according to the instruction set and the gate positioning constraints of the target quantum processor.

35. A non-transitory computer-readable storage medium storing one or more programs, said one or more programs comprising instructions that, when executed by a digital computer system having one or more digital processors, cause the digital computer system to: (A) Obtain a computer program written in a unified language using a unified-level module, the computer program being able to run on a target quantum processor, the target quantum processor comprising multiple qubits or multiple quantum quaternions; (B) Refactoring all or part of the computer program using the unified-level module to form refactored code; (C) Convert the refactored code into first code; (D) The first code is compiled into a second code using a high-level module, wherein the high-level module provides access to quantum gate-level commands specified in the first code and supports pointers, functions, non-expandable loops, recursions, data structure definitions and class object definitions encoded on qubits of the plurality of qubits or on quantum quaternions of the plurality of quantum quaternions in the first code, as well as support for subroutines and flow control instructions within the first code; (E) The second code is converted into a third code comprising a series of quantum gate-level operations using a low-level module; as well as (F) The third code is compiled into a fourth code expressed in a quantum gate-level language according to the instruction set and the gate positioning constraints of the target quantum processor.

Images