Read the unit before you read the multiplier
If a quantum program is described as 290 times better, the first question is what got divided by what. It could be a count of operations, a measure of the memory the circuit occupies, or an estimate of elapsed time under a particular hardware design. These are different claims. A reader can appreciate a large improvement without turning it into a prediction about a machine.
A preprint submitted November 6 by researchers from Google DeepMind and Google Quantum AI offers a good example. Its authors used language-model agents to propose quantum programs, then checked formal correctness and resource claims with Lean. For a fixed-point inverse sine routine, called arcsin, the paper reports an improvement of roughly 290-fold in a logical cost metric. That metric multiplies peak logical qubits, including workspace, by the count of T gates, a particular kind of quantum operation. It is a resource comparison, not a measured runtime on hardware.
There is a useful wrinkle. Appendix F says the published baseline configuration has a maximum error of about one millionth, while the new routine targets a maximum absolute error of 0.000000125 across its specified inputs. The authors treat the looser baseline’s cost as a lower bound for the comparison. That is different from running two matched configurations at precisely the same tolerance. A careful summary can preserve both points: the new result has a much lower reported logical cost and meets a stricter stated accuracy target than the quoted baseline configuration.
Source: Shirobokov et al.: Discovering formally verified quantum programs with AI ↗ · Microsoft Learn: What is the Microsoft Quantum resource estimator? ↗
Specify what counts as the same answer
Approximation does not make a program inherently suspect. If your application can tolerate a little error, requiring a more precise result can waste resources. The trouble starts when two programs are compared without saying how much error each is allowed, or how that error was measured. A cheap calculation that supplies the wrong precision is not a cheaper solution to the same problem.
Take a familiar example. A graphic designer requests a converter for an animation whose rotation angle must be accurate to within a tenth of a degree at every supported input. One candidate is within two tenths of a degree at its worst point but is usually much closer. Another stays within a tenth everywhere in the supported range. An average-error column could make the first look excellent. It still does not meet the stated requirement. The numbers here are invented to illustrate the comparison, not results from quantum software or a measurement of an animation tool.
Write the requirement as four short fields: the inputs covered, the desired output, the error metric and the tolerance. In the animation example, decide whether the supported inputs include the endpoints, whether the output is in degrees or radians, and whether you care about the worst case or typical behavior. Ask whether a statement applies to every representable input, a finite set chosen for an evaluation, or a probability distribution. Two claims with the same error number can mean different things when those qualifiers change.
Also distinguish the approximation error of an ideal program from the chance an implementation on a noisy device fails. A calculation can use a mathematically accurate approximation and still encounter hardware errors. Conversely, perfect execution would faithfully deliver a poor approximation if that is what the algorithm specified. Record both when a study reports them. A single label such as “error below 1%” leaves too much work to the reader.
Keep both axes next to the combined score
A combined score helps rank programs when a comparison has many dimensions. It can also hide a trade. Consider a fictional resource table. Program A meets the chosen tolerance with 80 logical qubits and 900 T gates. Program B meets it with 120 logical qubits and 500 T gates. Multiplying gives 72,000 for A and 60,000 for B. The product favors B by a factor of 1.2, even though B needs 40 more logical qubits.
Now suppose your planning exercise assumes a ceiling of 100 logical qubits. B no longer fits, however good the product looks. Under a different scenario, suppose 130 logical qubits are available but the maximum allowed T count is 700. A no longer fits. Neither ceiling describes an existing machine; each exposes a choice that the single score can conceal. If you report the product, keep its component counts and constraints beside it.
A logical qubit is an error-protected unit described by the computation; the physical qubits needed to implement that unit depend on the hardware and error-correction scheme. The T count likewise is not a timer. A count says how many operations are required under a gate accounting convention. It does not, by itself, establish which operations must be performed one after another, how quickly they can be supplied or how many devices would be occupied during the run. That is why the product can be informative as a logical proxy while remaining unsuitable as a stopwatch.
Try reporting a comparison in two sentences. First state the metric, the numerator and the denominator. Then state the main limitation of that metric for your decision. “B costs 60,000 versus A’s 72,000 in this product; B also exceeds our hypothetical qubit cap” carries the information someone needs to choose. Calling B simply “20% better” hides both the basis and the constraint. Even the percent can mislead: A’s product is 20% above B’s, while B’s product is about 16.7% below A’s. Ratios need direction.
Compare a small set of honest rows
A useful paper-reading exercise is to build a comparison with one row for each candidate at each relevant tolerance. Start with the two variants and a single accuracy target. Copy the program version and source location into the notes. Write down the scope of the resource number: a subroutine, a full circuit or the complete scientific workload. If the source does not give a candidate’s cost at the target tolerance, leave the cell blank and say why. An extrapolation deserves a separate row with its assumptions stated.
Add a looser and a stricter target if enough information exists. The preferred approach may change as you demand greater precision. A circuit that performs well at coarse accuracy may require many extra operations to improve it, while a different approach may have a larger initial cost and a gentler rise. Three labeled points tell you more than one universal multiplier. A smooth curve drawn through unknown values can look precise without adding evidence.
Next, check which pieces each count includes. In a full computation, you might need to prepare an input, perform a subroutine repeatedly and recover an output. A source can quote only one of those operations for a perfectly good reason. Comparing that number with another source’s end-to-end total is still unfair. Write a sentence about where each count starts and stops. If both authors count a repeated operation, check whether they assume the same number of repetitions and whether any setup is shared across them.
A blank is especially important when the comparator is already strong at a different setting. In the inverse sine case, the looser baseline number still makes the reported improvement meaningful: the new routine costs less in the stated metric while meeting a tighter bound. But you cannot fill in the missing baseline cell at the stricter setting with a number the paper did not report. Keep the lower-bound interpretation attached to the comparison rather than making the table look more complete than it is.
Ask what it would take to quote a runtime
To move from logical resources to physical estimates, you need another layer of assumptions. Microsoft’s Quantum resource estimator documentation gives an example of that separation: the application description is an input, alongside models for the hardware and error correction, and a maximum error allowance. The outputs include estimated runtime and physical qubits. Changing the hardware or correction model can change the estimate for the same program.
Suppose you want to compare two alternatives for a particular research proposal. Choose a common hypothetical architecture, error model and resource limit. Use the same conventions for mapping both circuits onto it. Record what is held constant and what is allowed to vary, such as whether the estimator may trade additional hardware for less time. If one candidate is given a large parallel budget and another is priced with minimal hardware, the runtime difference reflects those choices as well as the circuits.
For a first comparison, report both the physical qubit estimate and runtime estimate when available, together with the assumed error allowance. A configuration that finishes sooner may use more physical qubits. If a reader’s budget is fixed, those options are not interchangeable. If you compare a second architecture, keep it as a second scenario; avoid averaging away the fact that the preferred candidate may depend on the hardware.
An estimate should carry its own date and configuration. This helps someone reproduce the calculation and see whether a newer error-correction model or a different hardware assumption changes it. It also keeps the result in its proper tense: “The estimator predicts” is a claim about a model, while “The device completed” is a claim about a run. Formal verification of a circuit’s logical properties cannot turn the first sentence into the second.
Turn the headline into a claim you can check
Take a resource claim from the preprint and write it in one line: a named program, compared with a named baseline, on a specified problem, under a stated metric. Below it, write the tolerance and any difference in the inputs or baseline setting. Now underline every word that implies time, hardware or a completed experiment. If the supporting evidence is a logical count or a modeled estimate, make sure those words do not suggest a device was timed.
Then try a small sensitivity exercise on the fictional A and B numbers. Under a 100-qubit ceiling, choose among feasible candidates. Relax the ceiling to 130 and repeat. Finally, hide the combined score and decide which pair of raw numbers you would want to see if the job had a severe operation budget. The arithmetic is deliberately simple. The point is to notice which assumption moves the conclusion, rather than making the spreadsheet elaborate.
This also gives you a way to evaluate what AI contributed. The agents helped find programs within a defined search and verification setup. The evidence for a resource improvement comes from the resulting program, the specification, the checked claims and the comparison to the baseline. The interesting question for a reader is whether that comparison supports the exact sentence they plan to repeat. The fact that an AI helped propose the circuit does not change what should go in the denominator.
The most useful follow-up is usually specific. Ask for a cost at a missing tolerance, a breakdown between peak space and operation count, or a matched physical estimate for both programs. Any of those would make the result easier to use. You can recognize a substantial algorithmic improvement today and still leave future hardware performance to measurements made on the hardware that will actually run it.
Try this, then make it yours.
Take a quantum resource claim and write down its baseline, accuracy target, qubit count and gate count. Mark any missing measurement before repeating the multiplier.
Follow the signal.
Our reporting starts here. Practical suggestions are our analysis, and vendor performance statements are claims unless independently verified. We haven’t hands-on tested this release.
- Shirobokov et al.: Discovering formally verified quantum programs with AI ↗ · 2026-11-06
- Microsoft Learn: What is the Microsoft Quantum resource estimator? ↗
