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

Too few shots is the cheapest cause to rule out.

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.

Both of those runs happen locally. On an IonQ remote simulator, noise-model simulation is shot-aware: IonQ runs one simulation for every shot you request, so the run gets longer as you raise the count. IonQ notes the extra time generally is not very noticeable unless you are simulating circuits with many qubits and a very large number of shots. Confirm a small shot count works on the remote path before you raise it.

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, and your circuit is rewritten into that set before it runs. Multi-qubit gates are decomposed into two-qubit operations. Standard gates such as RX, RY, RZ and CNOT are converted to native equivalents.

IonQ's compiler then goes further. Gates it treats as extraneous are optimised away, or commuted into different places in the circuit. What remains is transpiled into native gates using special heuristics, then optimised again. The toolchain is proprietary, and IonQ does not publish every transformation it applies.

Decomposition and conversion usually add gates, and more gates means more opportunity for error. The symptom is a distribution noisier than the circuit in your editor would suggest, on a run that reported no error at all.

A rewritten circuit that exceeds a backend's gate limit fails with TooManyGates or UnsupportedGate, both in the Error reference. One that stays under the limit runs and returns a noisier distribution.

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 the circuit that gets submitted. IonQ then compiles again on its own side, so the gate count that runs can be higher or lower than the local transpile reports. How your circuit is compiled has the native gate set and what each transformation does.

Hardware noise

Real quantum hardware is noisy: a circuit that runs with no error can still return a distribution that does not match what you expected.

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.

An IBM noise-model simulator is a model of that machine, not the machine. It executes locally in your browser; no IBM cloud service is contacted, and you are not running on IBM hardware.

The IonQ remote simulators do run on IonQ's cloud, but they are noise models too, and IonQ is explicit about how far to trust one. A noise-model run there uses an approximation of system performance, and IonQ offers no specific guarantee of accuracy. IonQ says the models should not be used to predict whether a given IonQ system will or will not execute a given circuit successfully. Its list of things not to do opens with expecting QPU results to match noisy simulation results quantitatively.

IonQ also rules out a narrower case: investigating or benchmarking a specific error channel. A noise model is a general model, so a circuit built to be sensitive to one particular source of noise is the kind it is most likely to get wrong.

A remote-simulator run shows the direction and rough size of the effect of noise on your distribution; IonQ says not to expect hardware counts to match it quantitatively. If a circuit is already unusable under the noise model, IonQ's own advice is to reconsider the approach rather than run it on the machine.

Readout error

Readout error happens after your circuit has already run: it corrupts the record of the measurement, not the quantum state itself.

Because the state itself is intact, the aggregate distribution can be corrected: ordinary classical arithmetic can estimate the true counts from the measured ones. The correction does not recover which individual shots were flipped, and it 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
• How your circuit is compiled