Why your results look wrong

A circuit can run without an error and still return a result you did not expect. Four things cause that: too few shots, a transpiler that rewrote the circuit, hardware noise, and readout error.

If your run failed instead, see the Error reference.

Not enough shots

This is the cheapest cause to rule out, and the most common one.

A single run of a circuit returns one bitstring, not a distribution. A distribution only appears once you run the circuit many times, and each individual run is called a shot.

Try it yourself: run the same circuit at shots=1, then again at shots=1000, both on the built-in simulator. The tally goes from a single spike to a stable distribution, and both runs are free and return instantly.

See Understanding Quantum Measurement for why the results spread out the way they do.

The transpiler rewrote your circuit

Hardware backends only execute a fixed set of native gates. Before your circuit runs, it gets translated into that gate set, so what actually executes on the hardware is not always the circuit you submitted.

That translation can add gates, and more gates means more error. So the same circuit can come out noisier after translation, even when it runs perfectly with no error and no failed job.

A translated circuit that blows past a backend's gate limit outright is the loud version of the same cause. You would see it as TooManyGates or UnsupportedGate in the Error reference. The quiet version still runs, just noisier.

Try it yourself: transpiling happens locally, so it submits no job and costs nothing. Compare your circuit before and after:

from qiskit import transpile

tqc = transpile(qc, backend=backend)
print(qc.count_ops(), qc.depth())
print(tqc.count_ops(), tqc.depth())

The second line is what gets submitted, not what you wrote. IonQ then compiles again on its own side, so treat this as a lower bound on the gate count rather than a transcript of the run. For the specifics of which gates a given backend supports natively, see IonQ's Compilation and native gates.

Hardware noise

Real quantum hardware is noisy. A circuit that runs cleanly, with no error, can still return a distribution that does not match what you expected. The machine executing it is imperfect, not your circuit or your shot count.

The Playground's Select QPU dialog groups your options into three kinds. For this comparison, only two matter, and both sit inside the same locally run simulators group: the built-in simulator and the simulators that carry IBM's noise models. Both are free and run in your browser. See Compute backends for the full list, including what runs on IonQ's cloud and what runs on real IonQ hardware.

Try it yourself: run the same circuit on the built-in simulator, then on an IBM noise-model simulator, then on an IonQ remote simulator, then optionally on IonQ hardware. The first three are free, so you can watch noise appear in the distribution without spending anything.

Be plain about what that middle run is: a noise-model simulator is a model of that machine, not the machine. It executes locally in your browser. No IBM cloud service is contacted at any point, and you are not running on IBM hardware.

Readout error

The last cause is different in kind from the other three. Readout error happens after your circuit has already run: it corrupts the record of the measurement, not the quantum state itself.

That distinction makes it fixable. The aggregate distribution can be corrected, because ordinary classical arithmetic can estimate the true counts from the measured ones. It does not recover which individual shots were flipped, and the correction carries statistical noise of its own.

Try it yourself: drag error sliders on a five-qubit GHZ state in Readout mitigation and watch three histograms, ideal, raw, and corrected, update together. It runs in your browser on a free simulator by default, so opening it costs you nothing. For the underlying idea, see Understanding Quantum Measurement.

Related

• Error reference
• Compute backends
• Troubleshooting and FAQ