Compressed paths in matching-based quantum decoders
By employing compressed edge representations in matching-based quantum decoders, the method efficiently processes measurement data from quantum computers, predicting error occurrences and enabling real-time characterization, thus overcoming the challenges of high data volume and error identification in existing technologies.
Patent Information
- Application Number
- PCT/US2024/037717
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-07-14
- Filing Date
- 2024-07-12
- Publication Date
- 2025-01-23
AI Technical Summary
Current quantum decoders face challenges in efficiently processing the high volume of measurement data from quantum computers, particularly in identifying errors quickly enough to prevent data backlog and ensure reliable quantum computations.
The implementation of a method for decoding measurement data using compressed edge representations in matching-based quantum decoders, which involves initializing detection events as source nodes, modifying regions in a detector graph to include empty nodes and edges, and computing decoding outputs using stored logical observables to predict error occurrences.
This approach significantly reduces processing time, enabling real-time or near real-time characterization of quantum computers, and can process around a million errors per second on a single core, several orders of magnitude faster than conventional methods.
Smart Images

Figure US2024037717_23012025_PF_FP_ABST
Abstract
Description
[0001]Attorney Docket No.: 56113-0484WO1 COMPRESSED PATHS IN MATCHING-BASED QUANTUM DECODERS BACKGROUND This specification relates to quantum computing. Quantum computing provides a means to solve certain problems that cannot be solved in a reasonable period of time using conventional classical computers. These problems include factoring very large numbers into their primes and searching large, unstructured data sets. A number of physical systems are being explored for their use in quantum computing, including ions, spins in semiconductors, and superconducting circuits. However, these systems do not perform sufficiently well to serve directly as computational qubits. For example, single two-state physical systems, which can be used as physical qubits, cannot reliably encode and retain information for long enough to be useful, e.g., due to noise. Quantum error correction is a technology that can enable a quantum computer to reliably execute a quantum algorithm despite noise afflicting its qubits. A decoder is a key component of quantum error correction schemes whose role is to identify errors faster than they accumulate in the quantum computer. The decoder takes as an input a syndrome, which is measurement data extracted from quantum parity check measurements, and returns as output an estimation of error. Given this estimation, the effect of the error can be reversed. Decoders should be implemented with minimum hardware resources in order to scale to the regime of practical applications of quantum computing. SUMMARY This specification describes methods, systems and apparatus for compressed edge representations of paths in matching based quantum decoders. One innovative aspect of the subject matter described in this specification can be implemented in a method for decoding measurement data received from a quantum computer that performs a quantum computation. The method can include initializing detection events that occur in the measurement data as source nodes of respective regions in a detector graph; performing a decoding process on the detector graph, comprising modifying the regions in the detector graph until the decoding process terminates, wherein modifying the regions in the detector graph comprises, for each of one or more of the regions: expanding the region in the detector graph to include an empty node in the detector graph and to include an edge that connects the empty node to the region; and in response to expanding the region to include the empty node in the detector graph and the edge that connects the empty node to the region, Attorney Docket No.: 56113-0484WO1 storing, at the empty node: a pointer to a source detection event of the empty node and logical observables crossed during expansion of the region; and computing a decoding output of the decoding process using one or more of the stored logical observables, wherein the decoding output predicts an occurrence of errors in the quantum computation. Other implementations of these aspects include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods. A system of one or more classical computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination thereof installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. The foregoing and other implementations can each optionally include one or more of the following features, alone or in combination. In some implementations the logical observables crossed during expansion of the region represent logical observables crossed along a shortest path from the source detection event to the empty node. In some implementations logical observables crossed during expansion of the region are stored at respective empty nodes as bitmasks. In some implementations the bitmasks comprise a fixed size, optionally wherein the size is 64 bits. In some implementations the method further comprises computing, for the empty node, the logical observables crossed during expansion of the region, the computing comprising: computing a XOR of a bitmask stored at the node in the region that is connected to the empty node and a bitmask stored at the edge that connects the empty node to the region, wherein: the bitmask stored at the node in the region that is connected to the empty node represents the logical observables crossed to reach the node from the source detection event, and the bitmask stored at the edge that connects the empty node to the region represents the logical observables crossed by the edge. Attorney Docket No.: 56113-0484WO1 In some implementations modifying the regions in the detector graph further comprises, for each of one or more first regions: expanding the first region in the detector graph to include a second region in the detector graph, wherein an edge in the detector graph connects a first node in the first region to a second node in the second region; and in response to expanding the first region to include the second region: determining endpoints of a collision edge for the expansion using pointers to source detection events stored at the first node and at the second node, wherein the collision edge represents a shortest path between a first detection event in the first region and a second detection event in the second region; computing a set of logical observables crossed during expansion of the first region using logical observables stored at the first node, second node, and the edge that connects the first node to the second node; and storing the computed set of logical observables at the collision edge. In some implementations sets of logical observables crossed during expansion of the first region are stored as observables bitmasks. In some implementations the bitmasks comprise a fixed size, optionally wherein the size is 64 bits. In some implementations computing the set of logical observables crossed during expansion of the first region using logical observables stored at the first node, second node, and the edge that connects the first node to the second node comprises: computing a XOR of an observables bitmask stored at the first node, an observables bitmask stored at the second node, and an observables bitmask stored at the edge that connects the first node to the second node. In some implementations the pointer to the source detection event of the empty node and the logical observables crossed during expansion of the region are stored in a data structure, wherein the data structure stores dynamic data for each node in the detector graph, the data for each node comprising, at a time t during the decoding process: current neighboring edges of the node at the time t; and for each current neighboring edge of the node: a current weight of the neighboring edge; current logical observables flipped by the neighboring edge; a current neighboring node connected by the neighboring edge. In some implementations modifying the regions in the detector graph comprises updating respective data stored in the data structure. In some implementations the data structure further stores, for each node in the detector graph that is included in one or more of the regions: a pointer to an active region the node is contained in; and a radius of arrival for the node. Attorney Docket No.: 56113-0484WO1 In some implementations predictions of the occurrence of errors in the quantum computation comprises a prediction of crossed logical observables. In some implementations the decoding process terminates when each region in the detector graph is matched to another region in the detector graph or to a boundary of the detector graph. In some implementations computing a decoding output of the decoding process using one or more of the stored logical observables comprises: identifying, for each pair of connected detection events in the detector graph, a shortest path between the pair of connected detection events; for each shortest path, retrieving, from a compressed edge on the shortest path, stored crossed logical observables for the path; and adding the stored crossed logical observables. Another innovative aspect of the subject matter described in this specification can be implemented in a method for decoding measurement data received from a quantum computer that performs a quantum computation. The method can include initializing detection events that occur in the measurement data as source nodes of respective regions in a detector graph; performing a decoding process on the detector graph to determine a plurality of compressed paths between pairs of connected detection events that occur in the measurement data, wherein the detector graph stores, for each compressed path, data specifying endpoints of the compressed path and logical observables flipped by the compressed path; and computing a decoding output of the decoding process using the data stored by the detector graph, wherein the decoding output predicts logical observables that were flipped during the quantum computation. Other implementations of these aspects include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods. A system of one or more classical computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination thereof installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions. The subject matter described in this specification can be implemented in particular ways so as to realize one or more of the following advantages. Attorney Docket No.: 56113-0484WO1 Quantum computers prevent a number of technical challenges associated with the underlying physical operation of the qubits. For example, a surface code superconducting quantum computer with a million physical qubits will generate measurement data at a rate of around 1 terabit per second. In order to adequately characterize the physical states of the qubits for functional operation of the quantum computer, this data must be processed at least as fast as it is generated by a decoder, the classical software used to predict which errors may have occurred, to prevent a backlog of data that grows exponentially in the T-gate depth of the computation. The present disclosure introduces a new variant of the so-called blossom decoding algorithm that directly solves the minimum-weight perfect matching (MWPM) decoding problem relevant to error correction. The presently described approach avoids the computationally expensive all-to-all Dijkstra searches often used in implementations of the MWPM decoder, where a reduction to the traditional blossom algorithm is used, while still facilitating interpretation of the underlying technical state of the quantum system. The presently described approach is several orders of magnitude faster than other, conventional approaches and can process around a million errors per second on a single core. For a distance-17 surface code, it can decode both X and Z bases in under 1μs per round of error correction, which matches the rate at which syndrome data is generated on a superconducting quantum computer. As a result, present technique may allow real-time, or near real-time, characterization of the quantum computer in circumstances where the degree of technical complexity would have made such characterization in practice unachievable using prior techniques. This can increase the realizable functional capabilities of the quantum computer. In addition, the presently described techniques can be directly applied to improve the performance of other decoders. For example, the compressed tracking technique described herein uses the fact that the decoder only need to predict which logical observables were flipped, rather than the physical errors themselves. This means a simplified and rationalized relationship with the underlying physical mechanisms, reducing complexity of measurements etc., while maintaining output performance. For example, this allows a sparse representation of paths in the detector graph to be used, storing only the endpoints of a path, along with the logical observables it flips (as a bitmask). In addition, instead of representing paths between detection events as lists of edges, or intrusive pointers, the paths are compressed down to a fixed-size representation: two end-of- path pointers for the two ends of the path, and a 64 bit mask tracking which observables were crossed an odd number of times by the path. This reduces the size of the representation from Attorney Docket No.: 56113-0484WO1 ^^^ ^^^ in the worst case to ^^^1^ in the worst case, makes updating the path information very cheap (e.g. concatenating two paths involves taking the far end point pointers from each and XOR-ing their masks), and means the key information needed to make a final logical observable flip prediction is already directly stored on the nodes at the end of the matching process. The details of one or more implementations of the subject matter of this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims. BRIEF DESCRIPTION OF THE DRAWINGS FIG.1 is a block diagram of an example computing system that uses compressed edge representations of paths in a matching based quantum decoder. FIG.2 is an illustration that shows key concepts in a sparse blossom decoding process. FIG.3 is a block diagram of an example sparse blossom decoder. FIG.4 illustrates example types of alternating tree events. FIG.5 illustrates an example construction of a compressed edge. FIG.6 is a flowchart of an example process for decoding measurement data received from a quantum computer that performs a quantum computation using compressed edges. FIG.7 is a plot that shows decoding times per round for an implementation of the presently described sparse blossom decoding process compared to other, conventional decoding processes. Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION FIG.1 is a block diagram of an example computing system 100 that uses compressed edge representations of paths in a matching based quantum decoder. The example computing system 100 is an example of a system implemented as classical and quantum computer programs on one or more classical computers and quantum computing devices in one or more locations, in which the systems, components, and techniques described herein can be implemented. Attorney Docket No.: 56113-0484WO1 The example computing system 100 includes a quantum computing device 102 and a classical processor 104. For illustrative purposes, the quantum computing device 102 and classical processor 104 shown in FIG.1 are illustrated as separate entities, however in some implementations the classical processor 104 may be included in the quantum computing device 102. For example, in some implementations the quantum computing device 102 can be directly connected to the classical processor 104. In other implementations, the quantum computing system 102 can be connected to the classical processor 104 through a network, e.g., a local area network (LAN), wide area network (WAN), the Internet, or a combination thereof. The quantum computing device 102 includes components for performing quantum computation. For example, the quantum computing device 102 can include a quantum data plane that, in turn, includes multiple physical qubits, a control and measurement plane that is configure to perform operations and measurements on the physical qubits, a control processor plane that is configured to determine sequences of operations and measurements that a quantum algorithm being performed by the quantum computing system requires, and a classical computer that is in data communication with the control processor and facilitates user interactions and access to networks or storage. The particular type of the quantum computing device 102 can depend on the type of qubit used. In some implementations the qubits can be superconducting qubits, semiconducting qubits, photonic qubits, or atom-based qubits. For example, the qubits can include Xmon qubits, flux qubits, phase qubits, CAT qubits, or qubits with frequency interactions. Typically, quantum computations performed by the quantum computing device 102 will be noisy due to the unavoidable presence of errors caused by, e.g., unwanted interactions between qubits, unwanted interactions with the environment (causing decoherence), faulty quantum gates or operations, or errors in the state preparation or measurement process. Example types of errors include coherent errors that act on single qubits, e.g., Pauli X-type errors called bit-flip errors that map the qubit basis states ^^|0^ ൌ |1^ and ^^|1^ ൌ |0^ and Pauli-Z errors called phase-flip errors that map the qubit basis states ^^|0^ ൌ |0^ and ^^|1^ ൌ െ|1^. Noise in a quantum computing device can be represented by an error model, e.g., independent error models as described in more detail below. If left unchecked, errors can destroy quantum information and render quantum computations performed by the quantum computing device 102 useless. Attorney Docket No.: 56113-0484WO1 Therefore, the quantum computing device 102 can be configured to execute a quantum error correcting code 106 when performing quantum computations. Quantum error correcting codes encode a first number ^^ of qubits (a Hilbert space of dimension 2 ^^ ) into a second number ^^ of qubits (a Hilbert space of dimension 2 ^^ ), where the second number is larger than the first number, i.e., ^^ ^ ^^. The ^^ qubits are data qubits that store logical information and are to be protected from error. The additional ^^ െ ^^ qubits are ancilla qubits that are used to detect errors. Example quantum error correcting codes include Stabilizer codes, e.g., the surface code 108. The surface code 108 encodes a logical qubit into a patch of multiple physical qubits on a lattice, e.g., a square or hex grid. The lattice includes alternating data qubits and ancilla qubits, where a qubit is placed on each edge of the lattice. The code is defined to be the ground space of the Hamiltonian ^^ ൌ െ∑௩∈^^^௩െ ∑^∈ி^^^where ^^ represents vertices of the lattice, ^^ represents faces defined by edges connecting vertices of the lattice, the operator ^^௩is associated with vertex ^^ and is a product of Pauli-X matrices acting on edges incident to ^^, and the operator ^^^is associated with face ^^ and is a product of Pauli-Z matrices acting on all edges of ^^. The code space is defined as the simultaneous “+1” eigenstate of the operators ^^௩and ^^^. These operators (or products of these operators) called the stabilizers of the code. When an error has affected the qubits of the code, any stabilizer that anti-commutes with the error returns a “-1” measurement outcome. A subset of vertices with −1 measurement outcomes is called a syndrome ^^. The syndrome ^^ can be used to determine a correction operator that, when applied to the code, corrects the error up to a stabilizer. During execution of the quantum error correcting code 106, the quantum computing device 102 is configured to provide measurement data 110 to the classical processor 104. The measurement data 110 can be received as a batch or stream of data. The measurement data 110 includes classical measurement outcome bits, e.g., corresponding to stabilizer measurements. In the present disclosure, a detector is a parity of measurement outcome bits that is deterministic in the absence of errors. The outcome of a detector measurement is 1 if the observed parity differs from the expected parity for a noiseless computation, and is 0 otherwise. A Pauli-type error ^^ is said to flip a detector ^^ if including ^^ in the circuit changes the outcome of ^^, and a detection event is a detector with outcome 1. A logical observable is a linear combination of measurement bits, whose outcome corresponds to the measurement of a logical Pauli operator. Attorney Docket No.: 56113-0484WO1 The classical processor 104 includes components for performing classical computations. For example, the classical processor 104 can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory storage medium for execution by, or to control the operation of, a data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. The classical processor 104 includes a decoder 112 that is configured to process measurement data 110 received from the quantum computing device 102 to decode the measurement data, i.e., predict which errors may have occurred during the quantum computation performed by the quantum computing device 102. To process the measurement data 110, the decoder 104 is configured to execute a decoding algorithm 114 (also referred to herein as a decoding process) that maps the decoding problem onto a graph problem using a graph-like error model for the quantum error correcting code 106. A graph-like error model is an independent error model, i.e., a set of ^^ independent error mechanisms, where error mechanism ^^ occurs with probability ^^^ ^^^ (where ^^ ∈ ℝ^is a vector of priors), and flips a set of detectors and observables. In a graph-like error model, each error mechanism flips at most two detectors. Graph-like error models can be used to approximate common noise models for many important classes of quantum error correction codes including surface codes, for which X-type and Z-type Pauli errors are both graph-like. Agraph-like error model is represented by a detector graph of nodes and edges ^^ ൌ^ ^^, ^^^, e.g., detector graph 116. Each node ^^ ∈ ^^ in the detector graph corresponds to adetector. Each edge ^^ ∈ ^^ is a set of detector nodes of cardinality one or two representing an error mechanism that flips this set of detectors. The set of edges ^^ can be decomposed as ^^ ൌ ^^^∪ ^^ଶwhere for each edge ^^ in ^^^, | ^^| ൌ 1 and for each edge ^^ in ^^ଶ, | ^^| ൌ 2. Aregular edge ^^ ൌ^^^, ^^^∈ ^^ଶ ^^ ∈ ^^, whereas a half-edge^^^,^∈ ^^^flips a single detector ^^ ∈ ^^. A half-edge can be connected to a boundary of the graph , in which case the edge can be defined as ^ ^^, ^^^^ where ^^^is a virtual boundary node (which does not correspond to any detector). In some implementations, e.g., when the graph problem is solved using minimum weight perfect matching, each edge can be assigned a weight, e.g., ^^^ ^^^^ ൌ log^1 െ ^^^ ^^^^ / ^^^ ^^^. Each edge can also be labelled with a set of logical observables that are flipped (also referred to herein as “crossed”, since when an edge is crossed and therefore included in matching, its annotated observable is flipped which Attorney Docket No.: 56113-0484WO1 inverts the corresponding prediction) by the error mechanism, which is denoted either by ^^^ ^^^^ or ^^^ ^^, ^^^ for ^^^ൌ^^^, , ^^^∈ ^^. The distance ^^^ ^^, ^^^ between two nodes ^^ and ^^ in the detector graph is equal to the length of the shortest path between them. Example decoding algorithms include minimum weight perfect matching (MWPM) and union find. MWPM decoding processes determine a most probable physical error consistent with syndromes in the measurement data. Detection events in measurement data are identified and labelled in the detector graph. A minimum weight embedded matching of the detection events in the detector graph is then determined, where an embedded matching of a set of detection events is a set of edges in the detector graph where each node corresponding to a detection event in the set of detection events is incident to an odd number of edges in the set of edges and each node that does not correspond to a detection event in the set of detection events is incident to an even number of edges in the set of edges. In conventional implementations of MWPM decoding processes, Edmond’s blossom algorithm is used to determine the embedded matching, e.g., by seeding clusters of nodes in the detector graph using the detection events and growing, shrinking, or freezing the clusters until the minimum weight embedded matching is obtained. The embedded matching is used to determine a prediction of which logical observable measurements were flipped, which can in turn be used to determine a correction operator that, when applied to the quantum error correcting code 106, corrects the errors. Union find decoding processes can be viewed as an approximation of minimum weight perfect matching decoding processes. A union find decoding process identifies detection events in measurement data and seeds clusters of nodes in the detector graph using the detection events. The clusters are then iteratively grown in the detector graph until the parity of the cluster changes. A so-called peeling step is then performed. A spanning tree for each grown cluster is generated and estimations of error are computed by traversing the spanning trees in reverse order. A correction operator that, when applied to the quantum error correcting code 106, corrects the errors is then determined. The decoding process 114 implemented by the decoder 112 is referred to herein as a sparse blossom decoding process 114. The sparse blossom decoding process 114 directly solves the minimum-weight embedded matching problem. Sparse blossom does not have a separate Dijkstra step for constructing edges in the path graph. Instead, shortest path information is recovered as part of the growth of alternating trees themselves. An edge in the path graph are discovered and stored exactly if and when it is needed by the blossom process - the edges that are tracked at any point in the process correspond exactly to the subset of Attorney Docket No.: 56113-0484WO1 tight edges in the path graph being used to represent an alternating tree, a blossom, or a match. This leads to large speedups relative to the sequential approach, where all edges in the path graph are found using Dijkstra searches, despite the vast majority never becoming tight edges in the blossom process. The decoder 112 includes multiple components: a matcher 302, a flooder 304, and a tracker 306. These components performs different operations to implement the sparse blossom decoding process 114. The matcher 302 is configured to manage the structure of alternating trees and blossoms (which are defined below with reference to FIG.2), without knowledge of the underlying structure of the detector graph. The flooder 204 is configured to handle how graph fill regions grow and shrink in the detector graph, as well as determine when a region collides with another region or the boundary. When the flooder 204 identifies a collision involving a region, or when a region reaches zero radius, the flooder 204 is configured to notify the matcher 302, which then modifies the structure of the alternating trees or blossoms. The tracker 306 is configured to determine when the different events occur, and ensures that the flooder 204 handles events in the correct order. The tracker 306 uses a single priority queue, and informs the flooder 204 when every event should be handled. Example operations performed by components of the decoder 112 are described in more detail below with reference to FIGS.2-6. After the decoder 112 has completed the decoding process 114, the classical processor 104 is configured to output a correction operator 118. The correction operator 118 can be applied to the quantum error correcting code 106 to correct the errors identified by the decoder 112. FIG.2 is an illustration that shows key concepts in the sparse blossom decoding process. A graph fill region, e.g., region 202, of radius ^^ is an exploratory region of the detector graph 200. In this disclosure, a graph fill region is sometimes referred to simply as a “region”. A graph fill region contains the nodes and edges (or fractions of edges) in the detector graph 200 which are within distance ^^ of its source. The source of a graph fill region is either a single detection event, e.g., detection event 204, or the surface of other graph fill regions that form a blossom 206. For the case that a graph fill region ^^ has a single detection event ^^ as its source, every node or fraction of an edge that is within distance ^^ of ^^ is contained in ^^. A graph fill region 202 in sparse blossom is analogous to a node or blossom in the conventional blossom process, and the radius of the graph fill region is analogous to a Attorney Docket No.: 56113-0484WO1 node or blossom’s dual variable in the conventional blossom algorithm. The sparse blossom process proceeds along a timeline, and the radius of each graph fill region can have one of three growth rates: +1 (growing 216), -1 (shrinking 218) or 0 (frozen 212). Therefore, at any time ^^ the radius of a graph fill region can be represented using an equation ^^ ൌ ^^ ^^ ^ ^^, where ^^ ∈ ^െ1, 0, 1^. When a graph fill region contains only one single detection event, the region is referred to as a trivial region. A region can contain multiple detection events if it has a blossom as its source. As well as its radius equation, each graph fill region also stores its blossom children and blossom parent. It also stores its shell area as a stack. The shell area of a graph fill region is the set of detector nodes it contains, excluding the detector nodes contained in its blossom children. A graph fill region is referred to as active if it does not have a blossom parent. A compressed edge 208 represents a path through the detector graph 200 between two detection events, or between a detection event and the boundary. Given a path ^^௨,௩⊆ ℰ between ^^ and ^^, where ^^ is a detection event and ^^ is either a detection event or denotes the boundary, the compressed edge ^^^ ^^௨,௩^ associated with ^^௨,௩is the pair of nodes ^ ^^, ^^^ at the endpoints of ^^௨,௩, as well as the set of logical observables ^^൫ ^^௨,௩൯:ൌ⊕^∈^ೠ,ೡ^^^ ^^^ flipped by flipping all edges in ^^௨,௩. The compressed edge ^^^ ^^௨,௩^ is therefore a compressed representation of the path ^^௨,௩containing all the information relevant for error correction and, for a given detector graph, can be stored using a constant amount of data (independent of the path length). In the present disclosure, when the choice of path ^^௨,௩⊆ ℰ for some given pair of detection events ^ ^^, ^^^ is clear from context, the compressed edge ^^^ ^^௨,௩^ may instead be denoted by ^ ^^, ^^^ and the set of logical observables ^^൫^^௨,௩൯may be denoted by ^^^ ^^, ^^^. The length of a compressed edge is defined to be the distance ^^^ ^^, ^^^ between its endpoints ^^ and ^^. Each compressed edge ^^൫ ^^௨,௩൯ in sparse blossom corresponds to a shortest path ^^௨,௩between ^^ and ^^. edge can be used to represent any path between ^^ and ^^, and when used in a union-find setting, the path ^^௨,௩need not be minimum weight. Compressed edges are used in the representation of several data structures in sparse blossom (alternating trees, matches and blossoms), as described below with reference to data store 326 of FIG.3. A pair of graph fill regions that are matched to each other are referred to as a match 210. Matched graph fill regions must be touching, assigned a growth rate of zero (they are frozen 212), and must be joined by a compressed edge which is referred to as a match edge. Attorney Docket No.: 56113-0484WO1 Initially, all graph fill regions are unmatched, and once the process terminates, every region (either a trivial region or a blossom) is matched either to another region or to the boundary. An alternating tree 214 is a tree in the detector graph 200 where each node in the tree corresponds to an active graph fill region and each edge corresponds to a compressed edge. Two regions can be connected by a compressed edge in an alternating tree only if their regions are touching. If region A is connected to region B in the alternating tree by a compressed edge ^ ^^, ^^^, and if A and B are both trivial regions, then ^^ is the source of A and ^^ is the source of B. If A and B each contain multiple detection events (in a blossom), then the compressed edge joining them is always a shortest compressed edge between a source in A and a source in B (a shortest compressed edge is a compressed edge with minimum length). An alternating tree 214 contains at least one growing region, can also contain shrinking regions, and always contains exactly one more growing region than shrinking region. Each growing region can have any number of children, all of which must be shrinking regions, and can have a single parent, also a shrinking region. Each shrinking region has a single child, a growing region, as well as a single parent, also a growing region. When two growing graph fill regions from within the same alternating tree hit each other they form a blossom 206, which is an odd-length cycle of regions. The regions in the odd length cycle forming a blossom cycle are called its blossom children, e.g., blossom child 220, and the cycle of blossom children is referred to as the blossom cycle. If a blossom B has region b as one of its blossom children, B is said to be the blossom parent of b. Neighbouring regions in a blossom cycle must be touching (but cannot overlap), and must also be connected by a compressed edge. Blossoms can also be nested; each blossom child can itself be a blossom, with its own blossom children. A blossom descendant of a blossom B is a region that is either a blossom child of B or is recursively a descendant of any blossom child of B. Similarly, a blossom ancestor of B is a region that is either the blossom parent of B or (recursively) an ancestor of the blossom parent of B. The radius of a blossom 222 is the distance it has grown since it formed (the minimum distance between a point on its surface and any point on its source). A detector node ^^ is contained in a region ^^ if ^^ is in the shell area of ^^. A detector node can only be contained in at most one region (shell areas are disjoint). If a detector node is not contained in a region the node is referred to as empty, and otherwise it is occupied. A Attorney Docket No.: 56113-0484WO1 detector node ^^ is said to be owned by a region ^^ either if ^^ is contained in ^^, or if ^^ is contained in a blossom descendant of ^^. The process proceeds along a timeline with the time t increasing monotonically as different events occur and are processed. Examples of events include a region arriving at a node, or colliding with another region. The time that each event occurs is determined based on the radius equations of the regions involved, as well as the structure of the detector graph. The process terminates when there are no more events left to be processed, which happens when all regions have been matched, and have therefore become frozen. FIG.3 is a block diagram 300 of an example sparse blossom decoder 112. The sparse blossom decoder 112 can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible non-transitory storage medium for execution by, or to control the operation of, a data processing apparatus. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them. As described above with reference to FIG.1, the sparse blossom decoder 112 includes a matcher 302, a flooder 304, and a tracker 306. The components of the sparse blossom decoder 112 can be connected via a network, e.g., a local area network (LAN), wide area network (WLAN), the Internet, or a combination thereof, which can be accessed over a wired and / or a wireless communications link. The matcher 302 is configured to manage the structure of alternating trees and blossoms during execution of the sparse blossom decoding process. At the initialization stage of the sparse blossom process, each detection event in the measurement data is initialized as the source of a growing region (a trivial alternating tree). As these regions grow and explore the detector graph during execution of the sparse blossom decoding process, the regions can hit other (growing or frozen) regions, as well as the boundary, until eventually all regions are matched and the process terminates. A growing region cannot hit a shrinking region, since shrinking regions recede as quickly as growing regions expand. When the flooder 304 determines that a growing region ^^ has hit another (growing or frozen) region ^^′ or the boundary, it identifies the corresponding collision edge and provides data specifying the collision edge 318 to the matcher 302. The collision edge is a compressed edge that represents the shortest path between a detection event in ^^ and a detection event in Attorney Docket No.: 56113-0484WO1 ^^′ (or, if ^^ hit the boundary, then the shortest path between a detection event in ^^ and the boundary). The collision edge can be constructed by the flooder 304 from local information at the point of collision. The collision edge it is used by the matcher 302 when handling events that change the structure of the alternating tree. These events are referred to as alternating tree events and described below with reference to FIG.4. The matcher 302 is configured to handle alternating tree events and recover pairs of matched detection events once all regions have been matched 310. FIG.4 illustrates example types of alternating tree events that the matcher 302 of FIG. 3 is configured to handle. In example (a), a growing region R in an alternating tree T can hit a region M1 that is matched to another region M2. In this case, the matcher 302 performs operations such that M1 becomes a child of R in T (and starts shrinking as indicated by the minus sign), and M2 becomes a child of M1 in T (and starts growing as indicated by the plus sign). The collision edge 400 becomes the alternating tree edge between R and M1 and the match edge 402 becomes the alternating tree edge between M1 and M2. In example (b), a growing region R in an alternating tree T hits a growing region R′ in a different alternating tree T′. In this case, the matcher 302 performs operations such that R is matched to R′ and the remaining regions in T and T′ also become matched. The collision edge 404 between R and R′ becomes a match edge, and a subset of the alternating tree edges also become match edges. All the regions in T and T′ are frozen. In example (c), a growing region R in an alternating tree T can hit another growing region R′ in the same alternating tree T. This leads to an odd-length cycle of regions which form the blossom cycle C of a new blossom B. The compressed edges (blossom edges) in the blossom cycle are formed from the collision edge 406, as well as the edges along the paths from R and R′ to their most recent common ancestors in T. The newly formed blossom becomes a growing node in T. When forming the cycle C, we define the orphans to be the set of shrinking regions in T but not C that were each a child of a growing region in C. The orphans become alternating tree children of B in T. The compressed edge connecting B to its parent in T is just the compressed edge that had connected the most recent common ancestor to its parent. Similarly, the compressed edges connecting the each orphan to its alternating tree parent remains unchanged (even though its parent region becomes B). In example (d), a blossom B in an alternating tree T shrinks to a radius of zero, instead of the radius becoming negative the blossom must shatter. When the blossom shatters, the odd-length path through its blossom cycle from the alternating tree child of B to Attorney Docket No.: 56113-0484WO1 the alternating tree parent of B is added to T as growing and shrinking regions. The even length path becomes matches. The endpoints of the compressed edges joining B to its parent and child in the alternating tree are used to determine where and how the blossom cycle is cut into two paths. In example (e), a trivial region R shrinks to a radius of zero, instead of the radius becoming negative a blossom forms. If R has a child C and parent P in the alternating tree T, when R has zero radius it must be that C is touching P (it is as if C has collided with P). The newly formed blossom has the blossom cycle ^ ^^, ^^, ^^^. If the compressed edge connecting ^ ^^, ^^^ is ^ ^^, ^^^, and the compressed edge connecting ^ ^^, ^^^ is ^ ^^, ^^^, then the compressed edge connecting ^ ^^, ^^^ is ^ ^^, ^^^ with logical observables ^^^ ^^, ^^^ ⊕ ^^^ ^^, ^^^. In example (f), a growing region R in an alternating tree T hits the boundary, R matches to the boundary and the collision edge becomes the match edge. The remaining regions in T also become matches. In example (g), a growing region R in an alternating tree T hits a region M that is matched to the boundary, then M instead becomes matched to R (and the collision edge becomes the match edge), and the remaining edges in T also become matches. Returning to FIG.3, some of the above described alternating tree events involve changing the growth rate of regions (for example, two growing regions both become frozen regions when they match to each other). Therefore, when handling each alternating tree event, the matcher 302 is configured to inform the flooder 304 of any required changes to region growth 312. The sparse blossom decoding process terminates when all regions have been matched to other regions or to the boundary. However, some of these matched regions may be blossoms (not trivial regions). To extract the compressed edge representing the match for each detection event instead, the matcher 302 is configured to shatter each remaining blossom and match its blossom children 314. For example, suppose a blossom B, with blossom cycle C, is matched to some other region R with a compressed edge ^ ^^, ^^^ between a detection event u in B and v in R. The matcher 302 identifies the blossom child c ∈ C of B which contains the detection event u. The matcher 302 then shatters B and matches c to R with the compressed edge (u, v). The matcher then splits the remaining regions in the blossom cycle C into neighbouring pairs, which become matches. The matcher 302 is configured to repeat this process recursively until all matched regions are trivial regions. Attorney Docket No.: 56113-0484WO1 The flooder 304 is configured to manage graph fill modifications 316, e.g., how graph fill regions grow, shrink or collide in the detector graph. Events handled by the flooder are referred to herein as flooder events. Broadly speaking, flooder events can be categorized into four different types of flooder events. A first type is an ARRIVE type, where a growing region R can grow into an empty detector node u. A second type is a LEAVE type, where a shrinking region R can leave a detector node u. A third type is a COLLIDE type, where a growing region can hit another region, or the boundary. A fourth type is an IMPLODE type, where a shrinking region can reach a radius of zero. Neither ARRIVE nor LEAVE events change the structure of the alternating trees or blossoms, so the flooder 304 does not need to notify the matcher 302 when these flooder events occur. Instead, the flooder 304 is configured to schedule new flooder events (which are inserted into the tracker priority queue) after the events have been processed. When a region grows into a node u, the flooder 304 is configured to reschedule the node u, by notifying the tracker 306 of the next flooder event that can occur along an edge adjacent to u (either an ARRIVE or COLLIDE event). When a shrinking region leaves a node, the flooder 304 checks the top of the shell area stack and schedules the next LEAVE or IMPLODE event. The flooder 304 only needs to notify the matcher 302 of a COLLIDE or IMPLODE event, and when a collision occurs the flooder passes the compressed edge representing the collision (the collision edge 318) to the matcher as well. When either of these types of events occur, the matcher 302 can change the growth rate of some regions when updating the structure of alternating trees or blossoms. The matcher 302 then notifies the flooder of any change of growth rate, which may require the flooder to reschedule some flooder events. For example, if a region R was shrinking, but then becomes frozen or starts growing, the flooder 304 reschedules all nodes contained in R (including blossom children, and their children etc.), to check for new ARRIVE or COLLIDE events. When the flooder 304 reschedules a node, it identifies an ARRIVE or COLLIDE event along each neighboring edge. There will be an ARRIVE event along an edge if one node is occupied by a growing region and the other is empty. There will be a COLLIDE event if both nodes are owned by active regions (R1,R2) with growth rates (1, 1), (0, 1) or (1, 0), or if one region is growing towards a boundary, for a half-edge. In order to calculate when an ARRIVE or COLLIDE event will occur along an edge, the local radius of each node is used. The local radius ^^^௩^ ^^^ of a node ^^ is the amount that regions owning ^^ have grown beyond ^^. The radius of arrival ^^^௩for an occupied node ^^ Attorney Docket No.: 56113-0484WO1 contained in a region R is the radius that R had when it arrived at ^^. The radius of a region ^^ is denoted by ^^^^ ^^^ and let ^^^ ^^^ be the set of regions that own a detector node ^^ (the region that ^^ is contained in, as well as its blossom ancestors). The local radius is then defined as^^^௩^^^^ൌ െ ^^^௩^∑^∈ை^௩^ ^^^^^^^. Both the local radius and radius of arrival of a node v aredefined to be zero if ^^ is Therefore, for an edge ^ ^^, ^^^ with weight ^^, the time of an found by solving ^^^௨^^^^^ ^^^௩^^^^ൌ ^^ for t. The onlysituation in which this involves division is when the local radius of both nodes are growing (have gradient / growth rate one), in which case the collision occurs at time ^^^^^^^ௗ^ൌ ^ ^^ െ ^^^௨^0^ െ ^^^௩^0^^ / 2. However, provided all edges are assigned even integer weights all flooder events, including these collisions between growing regions, occur at integer times. As another example, when a region starts shrinking, the flooder 304 informs the tracker 306 of the next LEAVE or IMPLODE event by checking the top of the shell area stack. When a region is shrinking, the flooder 304 determines the time of the next LEAVE or IMPLODE event by inspecting the shell area stack of the region. If the stack is empty, or if the region has no blossom children and only a single node remains on the stack (the region’s source detection event), then the next event is an IMPLODE event. Otherwise, the next event is a LEAVE event, with the node u at the top of the stack leaving the region. The correct ordering of the flooder events is ensured by the tracker 306, and a growing region is instantiated for each detection event simultaneously at time t = 0. The implementation therefore uses an alternating tree growth strategy. Whenever a collision occurs between two regions A and B, the flooder 304 is configured to construct a compressed edge 320 corresponding to the shortest path between a detection event in A and a detection event in B. By storing relevant information on nodes as regions grow, the compressed edge can be constructed efficiently using local information at the point of collision (e.g. using only information stored on the edge (u, v) that the collision occurs on, and on the nodes u and v). This is illustrated and described below with reference to FIG.5. As a region R reaches an empty node v by growing along an edge (u, v) from a predecessor node u, a pointer to the detection event S(v) it was reached from (which can simply be copied from u) is stored on v. S(v) is referred to herein as the source detection event of v. An observables bitmask corresponding to the observables crossed during the region growth (e.g. the observables crossed along the shortest path from d to v) is also stored on v. This bitmask can be efficiently computed from the XOR of the observables bitmask on u and the observables bitmask on the edge (u, v). When a collision occurs between regions Attorney Docket No.: 56113-0484WO1 along an edge (p, q), the endpoints of the collision edge can then be determined from the source detection events stored on p and q, and the observables bitmask can be computed from the XOR of the observables bitmasks on p and q and on the edge (p, q) itself. The tracker 306 is configured to schedule flooder events 322 such that the flooder events occur in the correct order. In some implementations the tracker 306 can schedule flooder events by placing each flooder event in a priority queue 324. However, many of the potential flooder events are chaff, i.e., irrelevant or worthless. For example, when a region R is growing, a flooder event would be added to the queue for each of its neighboring edges. An edge (u, v) is said to be a neighbor of a region R if u is in R and v is not (or vice versa). Along each neighboring edge, there will be an event either corresponding to the region growing into an empty node, or colliding with another region or boundary. However, if the region becomes frozen or shrinking, then all of these remaining events will be invalidated. To reduce this chaff, rather than adding every flooder event to the priority queue 324, the tracker 306 can be configured to add look-at-node and look-at-region events to a priority queue. The flooder 304 finds the time of the next event at a node or region, and queries the tracker 306 for a reminder to look back at that time. As a result, at each node, only the next event needs to be added to the priority queue 324. The remaining potential flooder events along neighboring edges will not be added if they have become invalidated. When the flooder 304 reschedules a node, it identifies the time of the next ARRIVE or COLLIDE event along a neighboring edge, and queries the tracker 306 for a reminder to look back at that time (a look- at-node event). The flooder 304 finds the time of the next LEAVE or IMPLODE event for a shrinking region by checking the top of the shell area stack, and asks the tracker 306 for a reminder to look back at the region at that time (a look- at-region event). To further reduce chaff, the tracker 306 only adds a look-at-node or look-at- region event to the priority queue if it will occur at an earlier time than an event already in the queue 324 for the same node or region. Once the tracker 306 reminds the flooder 304 to look back at a node or region, the flooder 304 checks if it is still a valid event by re-computing the next event for the node or region, processing it if so. The sparse blossom decoder 112 further includes a data store 326 that stores data structures for the sparse blossom decoding process. Each detector node ^^ in the detector graph for the sparse blossom decoding process stores its neighbouring edges in the detector graph as an adjacency list. For each neighbouring edge ^ ^^, ^^^, the follow data is stored: its weight, e.g., as a 32-bit integer, the observables it flips (as a 64-bit bitmask), and the Attorney Docket No.: 56113-0484WO1 neighbouring node ^^ as a pointer (or as nullptr for the boundary). Edge weights can be discretized as even integers, which ensures that all events (including two growing regions colliding) occur at integer times. Each occupied detector node ^^ stores a pointer to the source detection event it was reached from, a bitmask of the observables crossed along the path from its source detection event, and a pointer to the graph fill region ^^^ ^^^ it is contained in (the region that arrived at the node). In some implementations, some properties can be cached on each occupied node whenever the blossom structure changes, in order to speed up the process of finding the next COLLIDE or ARRIVE event along an edge. This includes storing a pointer to the active region the occupied detector node ^^ is owned by (the topmost blossom ancestor of the region it is contained in) as well as its radius of arrival ^^^௩, which is the radius that the node’s containing region ^^^ ^^^ had when it arrived at Additionally, the wrapped radius ^^௪௩of each detector node ^^ is cached whenever its blossom structure (if a blossom is formed or shattered). The wrapped radius of an occupied node ^^ is the local radius of the node, excluding the (potentially growing or shrinking) radius of the active region it is owned by. If ^^^^ ^^^ is the radius of the active region that owns ^^, the local radiuscan be recovered from the wrapped radius with ^^^௩^^^^ൌ ^^௪௩^ ^^^^ ^^^.Each graph fill region ^^ has a pointer to its blossom parent and its topmost blossom ancestor. Its blossom cycle is stored as an array ^^ of cycle edges, where the cycle edge ^^^ ^^^ stores a pointer to the i-th blossom child or ^^, along with the compressed edge joining child ^^ to child ^^ ^ 1 mod ^^^, where ^^^is the number of blossom children of ^^. Its shell area stack is an array of pointers to the detector nodes it contains (in the order they were added). For its radius ^^ோ^ ^^^ ൌ ^^ ^^ ^ ^^, 62 bits can be used to store the y-intercept ^^ and with 2 bits used to store the gradient / growth rate ^^ ∈ ^െ1, 0, 1^. Each region also stores its match as a pointer to the region it is matched to, along with the compressed edge corresponding to the path between the matched regions. Finally, each growing or shrinking region has a pointer to an AltTreeNode. An AltTreeNode is used to represent the structure of an alternating tree. Each AltTreeNode corresponds to a growing region in the tree, as well as its shrinking parent region (if it has one). Each AltTreeNode has a pointer to its growing graph fill region and its shrinking graph fill region (if it has one). It also has a pointer to its parent AltTreeNode in the alternating tree (as a pointer and a compressed edge), as well as to its children (as an array Attorney Docket No.: 56113-0484WO1 of pointers and compressed edges). The compressed edge corresponding to the shortest path between the growing and shrinking region is also stored in the AltTreeNode. Each detector node and graph fill region can also have a tracker field, which stores the target time the node or region should next be looked at, as well as the time (if any) it is already scheduled to be looked at as a result of a look-at-node or look-at-region event already in the priority queue (called the queued time). The tracker 306 therefore only needs to add a new look-at-node or look-at-region event to the priority queue 324 if its target time is set to be earlier than its current queued time. A property of the process is that each event de-queued from the priority queue must have a time that is greater than or equal to all previous events de-queued. This allows use of a radix heap, which is an efficient monotone priority queue with good caching performance. Since the next flooder event can never be more than one edge length away from the current time, a cyclic time window for the priority can be used, rather than the total time. 24, 32 and 64 bits of integer precision can be used for the edge weights, flooder event priorities and total time, respectively. FIG.5 illustrates an example construction of a compressed edge. As illustrated in part (a) of FIG.5, as a region R expands, each detector node it contains stores the detection event it was reached from (represented by the Voronoi-style fill of the blossom B). When a collision occurs, this allows the endpoints of the corresponding compressed edge (the collision edge) to be determined from local information at the point of collision. As illustrated in part (b) of FIG.5, each detector node also stores (e.g., as a 64-bit bitmask) the observables that were crossed to reach it from the detection event it was reached from. This allows the observables bitmask of the compressed edge to be recovered efficiently, also from local information at the point of collision. FIG.6 is a flowchart of an example process 600 for decoding measurement data received from a quantum computer that performs a quantum computation using compressed edges. For convenience, the process 600 will be described as being performed by components of a classical computing system. For example, a classical decoder, e.g., decoder 112 of FIGS.1 and 3, appropriately programmed, can perform example process 600. The system initializes detection events that occur in the measurement data as source nodes of respective graph fill regions in a detector graph (step 602). The system then performs the presently described sparse blossom decoding process on the detector graph (step Attorney Docket No.: 56113-0484WO1 604). Performing the sparse blossom decoding process includes modifying the regions in the detector graph until the sparse blossom decoding process terminates. The sparse blossom decoding process terminates when each region in the detector graph is matched to another region in the detector graph or to a boundary of the detector graph. Modifying the one or more regions in the detector graph can include growing, shrinking, or freezing the regions. For example, as described above, e.g., with reference to FIGS.3-5, in some implementations the system can grow a region of the detector graph by expanding the region in the detector graph to include an empty node in the detector graph and to include an edge that connects the empty node to the region (step 604a). Such modifications are referred to herein as ARRIVE events. In response to expanding the region to include the empty node in the detector graph and the edge that connects the empty node to the region, the system stores data at the empty node (step 604b). The stored data includes a pointer to a source detection event of the empty node and logical observables crossed during expansion of the region. The logical observables crossed during expansion of the region represents the logical observables crossed along a shortest path from the source detection event to the empty node. The logical observables can be stored as bitmasks with a fixed size, e.g., 64-bit bitmasks. The system can compute the logical observables crossed during expansion of the region from a XOR of: a bitmask stored at the node in the region that is connected to the empty node and a bitmask stored at the edge that connects the empty node to the region, where the bitmask stored at the node in the region that is connected to the empty node represents the logical observables crossed to reach the node from the source detection event and the bitmask stored at the edge that connects the empty node to the region represents the logical observables crossed by the edge. As another example, in some implementations the system can grow a region of the detector graph by expanding the first region in the detector graph to include a second region in the detector graph, where an edge in the detector graph connects a first node in the first region to a second node in the second region (step 604c). Such modifications are referred to herein as COLLIDE events. In response to expanding the first region to include the second region, the system determines and stores endpoints of a collision edge for the expansion using pointers to source detection events stored at the first node and at the second node (step 604d). The collision edge is a compressed edge that represents a shortest path between a first detection event in the first region and a second detection event in the second region. The system also computes and stores the set of logical observables crossed during expansion of the first region using Attorney Docket No.: 56113-0484WO1 numbers of observables stored at the first node, second node, and the edge that connects the first node to the second node (step 604e). For example, the system can compute a XOR of an observables bitmask stored at the first node, an observables bitmask stored at the second node, and an observables bitmask stored at the edge that connects the first node to the second node. The system can store the set of logical observables computed at step 604e at the collision edge, e.g., as a 64-bit bitmask. Other types of data computed and stored in a data structure during the decoding process is described in more detail above with reference to FIG.3. The system computes a decoding output of the decoding process using stored numbers of observables crossed during expansion of the region (step 606). The decoding output predicts an occurrence of errors in the quantum computation. To compute the decoding output of the decoding process, the system can identify, for each pair of connected detection events in the detector graph, a shortest path between the pair of pair of connected detection events. Then, for each shortest path, the system can retrieve, from a compressed edge on the shortest path, the crossed logical observables for the path. The system can then combine the retrieved crossed logical observables to obtain the decoding output. The decoding output is a prediction of which logical observables were flipped during the quantum computation (rather than the physical errors themselves). FIG.7 is a plot 700 that shows results of benchmarked decoding times per round for an implementation of the presently described sparse blossom decoding process compared to other, conventional decoding processes, e.g., PyMatching v0.7 and a NetworkX. For distance d, the time to decode d rounds of a distance d surface code circuit is determined and this time is divided by d to obtain the time per round. A circuit-level depolarising noise model is used where the probability p = 0.1% sets the strength of two-qubit depolarising noise after each CNOT gate, the probability that each reset or measurement fails, as well as the strength of single-qubit depolarising noise applied before each round. The threshold for this noise model is around 0.71%. The plot 700 shows an almost-linear running time of the presently described sparse blossom decoding process. Further, the plot 700 shows that the presently described sparse blossom decoding process processes both X and Z bases of distance-17 surface code circuits in less than one microsecond per round of syndrome extraction on a single core, which matches the rate at which syndrome data is generated by superconducting quantum computers. Attorney Docket No.: 56113-0484WO1 At low physical error rates, the roughly linear scaling of the presently described sparse blossom decoding process is a quadratic improvement over the empirical scaling of implementations that use a reduction to the traditional MWPM problem by constructing a complete graph on the detection events. For 0.1%-1% physical error rates and distance 29 and larger, the presently described sparse blossom decoding process is > 100, 000× faster than a pure Python implementation that uses the exact reduction to MWPM. Compared to local matching approximations of the MWPM decoder, the presently described sparse blossom decoding process has a similar empirical scaling but is around 100× faster near threshold (error rates of 0.5% to 1%) and almost 1000× faster below threshold (p = 0.1%). Embodiments and all of the functional operations described in this specification may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium may be a machine- readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term “data processing apparatus” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus may include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus. A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. Attorney Docket No.: 56113-0484WO1 A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program may be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network. The processes and logic flows described in this specification may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and apparatus may also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit). Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer may be embedded in another device, e.g., a tablet computer, a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry. To provide for interaction with a user, embodiments may be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, Attorney Docket No.: 56113-0484WO1 feedback provided to the user may be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, speech, or tactile input. Embodiments may be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user may interact with an implementation, or any combination of one or more such back end, middleware, or front end components. The components of the system may be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet. The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. While this specification contains many specifics, these should not be construed as limitations on the scope of the disclosure or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this specification in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination may in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems may Attorney Docket No.: 56113-0484WO1 generally be integrated together in a single software product or packaged into multiple software products. In each instance where an HTML file is mentioned, other file types or formats may be substituted. For instance, an HTML file may be replaced by an XML, JSON, plain text, or other types of files. Moreover, where a table or hash table is mentioned, other data structures (such as spreadsheets, relational databases, or structured files) may be used. Thus, particular embodiments have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims may be performed in a different order and still achieve desirable results.
Claims
Attorney Docket No.: 56113-0484WO1 CLAIMS What is claimed is:
1. A computer implemented method for decoding measurement data received from a quantum computer that performs a quantum computation, the method comprising: initializing detection events that occur in the measurement data as source nodes of respective regions in a detector graph; performing a decoding process on the detector graph, comprising modifying the regions in the detector graph until the decoding process terminates, wherein modifying the regions in the detector graph comprises, for each of one or more of the regions: expanding the region in the detector graph to include an empty node in the detector graph and to include an edge that connects the empty node to the region; and in response to expanding the region to include the empty node in the detector graph and the edge that connects the empty node to the region, storing, at the empty node: a pointer to a source detection event of the empty node and logical observables crossed during expansion of the region; and computing a decoding output of the decoding process using one or more of the stored logical observables, wherein the decoding output predicts an occurrence of errors in the quantum computation.
2. The method of claim 1, wherein the logical observables crossed during expansion of the region represent logical observables crossed along a shortest path from the source detection event to the empty node.
3. The method of claim 1 or claim 2, wherein logical observables crossed during expansion of the region are stored at respective empty nodes as bitmasks.
4. The method of claim 3, wherein the bitmasks comprise a fixed size, optionally wherein the size is 64 bits.
5. The method of claim 3, wherein the method further comprises computing, for the empty node, the logical observables crossed during expansion of the region, the computing comprising:Attorney Docket No.: 56113-0484WO1 computing a XOR of a bitmask stored at the node in the region that is connected to the empty node and a bitmask stored at the edge that connects the empty node to the region, wherein: the bitmask stored at the node in the region that is connected to the empty node represents the logical observables crossed to reach the node from the source detection event, and the bitmask stored at the edge that connects the empty node to the region represents the logical observables crossed by the edge.
6. The method of any one of the preceding claims, wherein modifying the regions in the detector graph further comprises, for each of one or more first regions: expanding the first region in the detector graph to include a second region in the detector graph, wherein an edge in the detector graph connects a first node in the first region to a second node in the second region; and in response to expanding the first region to include the second region: determining endpoints of a collision edge for the expansion using pointers to source detection events stored at the first node and at the second node, wherein the collision edge represents a shortest path between a first detection event in the first region and a second detection event in the second region; computing a set of logical observables crossed during expansion of the first region using logical observables stored at the first node, second node, and the edge that connects the first node to the second node; and storing the computed set of logical observables at the collision edge.
7. The method of claim 6, wherein sets of logical observables crossed during expansion of the first region are stored as observables bitmasks.
8. The method of claim 7, wherein the bitmasks comprise a fixed size, optionally wherein the size is 64 bits.
9. The method of claim 7 or claim 8, wherein computing the set of logical observables crossed during expansion of the first region using logical observables stored at the first node, second node, and the edge that connects the first node to the second node comprises:Attorney Docket No.: 56113-0484WO1 computing a XOR of an observables bitmask stored at the first node, an observables bitmask stored at the second node, and an observables bitmask stored at the edge that connects the first node to the second node.
10. The method of any one of the preceding claims, wherein the pointer to the source detection event of the empty node and the logical observables crossed during expansion of the region are stored in a data structure, wherein the data structure stores dynamic data for each node in the detector graph, the data for each node comprising, at a time t during the decoding process: current neighboring edges of the node at the time t; and for each current neighboring edge of the node: a current weight of the neighboring edge; current logical observables flipped by the neighboring edge; a current neighboring node connected by the neighboring edge.
11. The method of claim 10, wherein modifying the regions in the detector graph comprises updating respective data stored in the data structure.
12. The method of claim 10 or claim 11, wherein the data structure further stores, for each node in the detector graph that is included in one or more of the regions: a pointer to an active region the node is contained in; and a radius of arrival for the node.
13. The method of any one of the preceding claims, wherein predictions of the occurrence of errors in the quantum computation comprises a prediction of crossed logical observables.
14. The method of any one of the preceding claims, wherein the decoding process terminates when each region in the detector graph is matched to another region in the detector graph or to a boundary of the detector graph.
15. The method of any one of the preceding claims, wherein computing a decoding output of the decoding process using one or more of the stored logical observables comprises: identifying, for each pair of connected detection events in the detector graph, a shortest path between the pair of connected detection events;Attorney Docket No.: 56113-0484WO1 for each shortest path, retrieving, from a compressed edge on the shortest path, stored crossed logical observables for the path; and adding the stored crossed logical observables.
16. A system comprising: one or more data processing apparatuses; and non-transitory computer readable storage media in data communication with the one or more data processing apparatuses and storing instructions that, when executed by the data processing apparatuses, cause the one or more data processing apparatuses to perform operations for decoding measurement data received from a quantum computer that performs a quantum computation, the operations comprising: initializing detection events that occur in the measurement data as source nodes of respective regions in a detector graph; performing a decoding process on the detector graph, comprising modifying the regions in the detector graph until the decoding process terminates, wherein modifying the regions in the detector graph comprises, for each of one or more of the regions: expanding the region in the detector graph to include an empty node in the detector graph and to include an edge that connects the empty node to the region; and in response to expanding the region to include the empty node in the detector graph and the edge that connects the empty node to the region, storing, at the empty node: a pointer to a source detection event of the empty node and logical observables crossed during expansion of the region; and computing a decoding output of the decoding process using one or more of the stored logical observables, wherein the decoding output predicts an occurrence of errors in the quantum computation.
17. A computer-readable storage medium comprising instructions stored thereon that are executable by a processing device and upon such execution cause the processing device to perform operations for decoding measurement data received from a quantum computer that performs a quantum computation, the operations comprising: initializing detection events that occur in the measurement data as source nodes of respective regions in a detector graph;Attorney Docket No.: 56113-0484WO1 performing a decoding process on the detector graph, comprising modifying the regions in the detector graph until the decoding process terminates, wherein modifying the regions in the detector graph comprises, for each of one or more of the regions: expanding the region in the detector graph to include an empty node in the detector graph and to include an edge that connects the empty node to the region; and in response to expanding the region to include the empty node in the detector graph and the edge that connects the empty node to the region, storing, at the empty node: a pointer to a source detection event of the empty node and logical observables crossed during expansion of the region; and computing a decoding output of the decoding process using one or more of the stored logical observables, wherein the decoding output predicts an occurrence of errors in the quantum computation.
18. A computer implemented method for decoding measurement data received from a quantum computer that performs a quantum computation, the method comprising: initializing detection events that occur in the measurement data as source nodes of respective regions in a detector graph; performing a decoding process on the detector graph to determine a plurality of compressed paths between pairs of connected detection events that occur in the measurement data, wherein the detector graph stores, for each compressed path, data specifying endpoints of the compressed path and logical observables flipped by the compressed path; and computing a decoding output of the decoding process using the data stored by the detector graph, wherein the decoding output predicts logical observables that were flipped during the quantum computation.
19. A system comprising: one or more data processing apparatuses; and non-transitory computer readable storage media in data communication with the one or more data processing apparatuses and storing instructions that, when executed by the data processing apparatuses, cause the one or more data processing apparatuses to perform operations for decoding measurement data received from a quantum computer that performs a quantum computation, the operations comprising: initializing detection events that occur in the measurement data as source nodes of respective regions in a detector graph;Attorney Docket No.: 56113-0484WO1 performing a decoding process on the detector graph to determine a plurality of compressed paths between pairs of connected detection events that occur in the measurement data, wherein the detector graph stores, for each compressed path, data specifying endpoints of the compressed path and logical observables flipped by the compressed path; and computing a decoding output of the decoding process using the data stored by the detector graph, wherein the decoding output predicts logical observables that were flipped during the quantum computation.
20. A computer-readable storage medium comprising instructions stored thereon that are executable by a processing device and upon such execution cause the processing device to perform operations for decoding measurement data received from a quantum computer that performs a quantum computation, the operations comprising: initializing detection events that occur in the measurement data as source nodes of respective regions in a detector graph; performing a decoding process on the detector graph to determine a plurality of compressed paths between pairs of connected detection events that occur in the measurement data, wherein the detector graph stores, for each compressed path, data specifying endpoints of the compressed path and logical observables flipped by the compressed path; and computing a decoding output of the decoding process using the data stored by the detector graph, wherein the decoding output predicts logical observables that were flipped during the quantum computation.
Citation Information
Patent Citations
Quantum computing error correction method, code, and system
US20230071000A1