QWE AI Academy By the end of this post you’ll be able to spot – and fix – the exact class of Python bug that a University of St Andrews researcher says wrecked Microsoft’s headline-grabbing quantum result. It’s a five-line fix. You don’t need a dilution refrigerator. You just need to understand the difference between an array’s position and its value.
In June 2025, a peer-reviewed Nature critique argued that Microsoft’s February 2025 Majorana quantum-computing breakthrough is fundamentally flawed. Dr Henry Legg, a lecturer at the University of St Andrews, says the claims were undermined by omitted data, selective plotting, and basic Python errors that concealed alternative results. Microsoft is pushing back. But forget the politics – the underlying mistake is something any beginner can (and does) make. Here’s what actually happened in the code.
The Microsoft quantum Python error in one sentence
The code antisymmetrized bias voltage based on array index rather than physical value. Microsoft’s researchers evaluated the number identifying a value’s position in an array, when the physics demanded they use the value itself.
Think of it like this: you have a list of voltage measurements from -1.0V to +1.0V. To check for a certain quantum signature, you compare each voltage with its mirror (-0.3V vs +0.3V, for instance). If you do that by position in the list instead of actual voltage value, the math only works if the list is perfectly symmetric and sorted. The moment it isn’t, you’re subtracting the wrong pairs – and your “discovery” is noise. The worst part: Python won’t tell you. No exception, no warning. Wrong numbers, served silently.
Watch out: Any time your code does
x[::-1]on scientific data, ask yourself: am I sure the coordinate axis is symmetric and sorted? If you’re not 100% sure, you’re already wrong – and you won’t see a traceback to prove it.
The actual buggy pattern (from the Hacker News thread)
A snippet matching the description was shared in the Hacker News discussion. It looks roughly like this:
import xarray as xr
# BUGGY: reverses by position, not by voltage value
antisymmetrized = xr.apply_ufunc(
lambda x: (x - x[::-1]) / 2,
conductance,
input_core_dims=[dims],
output_core_dims=[dims],
vectorize=True,
)The x[::-1] is the smoking gun. In NumPy and xarray, that reverses the array by position. According to the xarray indexing documentation, the library supports two entirely separate systems: positional indexing (where array[i] gives you the i-th element regardless of what coordinate value lives there) and label-based indexing (where .sel() looks up the element whose coordinate matches what you asked for). The bug uses the first when the physics demands the second – and xarray will not raise an error when you mix them. It just returns different numbers.
Five lines to fix it
Start from where you want to be – a function that antisymmetrizes by actual voltage value, not array index – then work backwards through the steps.
- Make the bias voltage an explicit coordinate. If your data is a raw NumPy array, you can’t fix this. Convert to an
xarray.DataArraywith named coords first. - Use
.sel()with the negated coordinate, not[::-1]. This reverses by value, not by position. - Reset the coordinate after the lookup so the result aligns with the original axis – otherwise xarray broadcasts against the flipped labels and you get NaNs.
- Assert symmetry up front. If your sweep isn’t symmetric, fail loudly instead of returning bad numbers.
- Plot every region your protocol flags, not just the largest. (More on this below.)
import numpy as np
import xarray as xr
def antisymmetrize_by_value(conductance, bias_dim="bias"):
v = conductance[bias_dim]
assert np.allclose(v, -v[::-1]), "Bias sweep is not symmetric - bug-prone!"
mirrored = conductance.sel({bias_dim: -v}).assign_coords({bias_dim: v})
return (conductance - mirrored) / 2The .sel({bias_dim: -v}) is the whole fix: “give me the data at the negative of each voltage value,” not “give me the data at the mirror position in the array.” If a researcher sampled +0.31V but not -0.31V, this raises instead of silently pairing it with whatever happens to sit at the mirrored index.
Why this matters even if you’ll never touch a qubit
Climate reanalysis scripts flip latitude arrays by position when the grid wraps. Financial backtests reverse time series without checking the timestamp. Neural network pipelines apply image augmentations that assume centered coordinates. The bug class is everywhere – any labeled axis plus a careless [::-1] gets you there.
And here’s the thing that makes it genuinely nasty: on a symmetric, perfectly sorted test sweep, the buggy version and the correct version produce identical output. The bug only fires on real, slightly-imperfect lab data – the kind you only get after months of expensive experiment time. Invisible in unit tests. Invisible in code review. Shows up exactly when it costs the most.
The catch here: common pitfalls when you try to fix it
- Forgetting the
assign_coordsstep. After.sel({bias_dim: -v}), xarray relabels the axis with negative values. Subtracting that from the original broadcasts against mismatched coords – you get NaNs, or worse, silent reindexing. - Testing only on symmetric data. Generate an intentionally asymmetric sweep in your tests – say -1.0V to +0.8V in 21 steps. The buggy and correct implementations must produce visibly different results. If they don’t, your test is wrong. Then lock that case into CI so a future refactor can’t quietly bring the bug back.
- Trusting your plot. The second bug Legg flagged was in visualization, not math. According to the Nature critique, the TGP plotting code was set to highlight only the largest purportedly topological region – other regions that passed the protocol were simply not shown. If your plotting function has an “only show the biggest” default, change it.
- Letting an AI assistant write the indexing for you without checking. Forum commenters are openly speculating that Copilot-generated code may be involved here. Whether or not that’s true in this case, the lesson stands: positional vs label-based indexing is exactly the kind of distinction LLMs blur.
Index-based vs value-based: pick the right tool
| Operation | Reverses by position | Reverses by coordinate value |
|---|---|---|
NumPy arr[::-1] |
Yes | No |
xarray da[::-1] |
Yes | No |
xarray da.isel({d: slice(None, None, -1)}) |
Yes | No |
xarray da.sel({d: -da[d]}) |
No | Yes |
pandas df.loc[::-1] |
Yes (positional within label range) | No |
For physics, finance, geosciences – anywhere the axis means something – default to .sel() with explicit values. Reserve [::-1] and .isel() for cases where you genuinely don’t care about the coordinate.
The wider context
This isn’t Microsoft’s first Majorana stumble. A 2018 Microsoft-funded Nature paper was retracted in 2021 after independent physicists raised concerns; the authors apologized for “insufficient scientific rigor.” Then, in February 2025, Microsoft unveiled the Majorana 2 processor – a big enough result that the company moved its commercial quantum supercomputer target from 2035 to 2029. Microsoft’s position on the new critique: the bugs were minor, and they stand by their findings and roadmap.
Whether the physics community accepts that response is genuinely open. What’s not contested is that the code Legg reviewed used positional indexing where value-based indexing was required. Fix that pattern in your own work and you’re already ahead of where this multi-billion-dollar program apparently was.
FAQ
Is Python actually a problem for scientific computing?
No. The bug here has nothing to do with Python’s speed or safety. The developer reached for positional indexing on data with a meaningful coordinate axis – the same mistake is possible in MATLAB, Julia, or R. Wrong tool, not wrong language.
How do I write a test that catches this bug?
Build a synthetic conductance array on an asymmetric bias sweep. Run both implementations – the [::-1] version and the .sel() version. They must produce different outputs. If they match, you accidentally made the sweep symmetric and your test proves nothing. Once you have a failing case, add it to CI. Future refactors can’t silently reintroduce the bug if a test is watching for it.
Does this affect Microsoft’s actual Quantum Development Kit that I might use?
Different layer entirely. The reported bug lives in a research paper’s data-analysis pipeline, not in the public QDK SDK. That said, as of mid-2025 (this may have changed), Microsoft is moving quantum resource estimation into a Python-based module – qdk.qre, installed via pip install --upgrade "qdk[qre]" – while deprecating the equivalent VS Code extension. More of their stack is shifting into Python, so the general lesson about positional vs label-based indexing applies whether you’re a quantum researcher or writing pandas at your day job.
Your next move: open the last NumPy or xarray script you wrote. Search for [::-1]. For every hit, ask: does this axis have a meaningful coordinate? If yes, rewrite it with .sel() and explicit values. Then write the asymmetric-input test. Ten minutes of work, one fewer career-ending bug.