SwiftQuantum IDE
Stabilizer Simulation of Clifford Circuits, Explained Without the Maths Wall
Why some quantum circuits can be simulated on a classical computer far more cheaply than others: which gates are Clifford, how a stabilizer tableau works, what you give up, and where it is useful.
Two circuits that look alike but cost very different amounts
Draw two circuits of the same width and depth. In the first, every gate is a Hadamard, a CNOT or a phase gate S. In the second, one of those S gates is replaced by a T gate. On screen they are nearly identical. To a classical simulator they are completely different problems: the first can be simulated cheaply even when it is very wide, and the second cannot.
The reason is a result known as the Gottesman–Knill theorem. It explains why some quantum circuits are easy for a classical computer and others are not, and it is the idea behind every stabilizer simulator. If you have read our overview of how a quantum circuit simulator works, this page goes one level deeper into the Clifford case.
Which gates are Clifford
The Clifford gates are a specific, small family:
- The Pauli gates X, Y and Z.
- Hadamard (H), which turns the zero state into an equal superposition.
- The phase gate S, a quarter-turn about the Z axis.
- The two-qubit gates CNOT, CZ and SWAP.
Measurement in the standard basis is also allowed. Everything you can build from these is a Clifford circuit.
What these gates share is a property about Pauli operators. If you take a Pauli operator (a product of X, Y, Z and identity across the qubits) and push it through a Clifford gate, you get another Pauli operator, possibly with a sign. Clifford gates shuffle Paulis among themselves and never produce anything outside that set.
Gates that are not Clifford include the T gate (an eighth-turn about Z), rotations by arbitrary angles, and the Toffoli and Fredkin gates. Push a Pauli through a T gate and you get a combination of Paulis, not a single one. That one difference is what breaks the shortcut.
Describing a state by what leaves it unchanged
The usual way to describe a quantum state is to list its amplitudes. For a register of qubits there is one amplitude per possible outcome, and the list doubles with every qubit.
A stabilizer simulator uses a different description. For many states, there is a set of Pauli operators that leave the state exactly as it is. These are its stabilizers. For example, a Bell pair is unchanged by applying X to both qubits, and unchanged by applying Z to both qubits. Those two facts pin the Bell state down completely.
For a register of qubits, you need one such generator per qubit. Each generator is just a row of Pauli letters and a sign, so the whole description is a table whose size grows with the square of the qubit count, not a list that doubles. This table is called a stabilizer tableau.
Simulating a gate then becomes bookkeeping. Because a Clifford gate maps every Pauli to another Pauli, applying it means rewriting the letters and signs in each row of the table. No amplitude is ever computed. Measurement is the one step that needs more work, but it too can be done on the table, at a cost that is still a power of the qubit count. That is the content of the Gottesman–Knill theorem: Clifford circuits, started from the zero state and measured in the standard basis, can be simulated efficiently on a classical computer.
What you give up
The efficiency comes with three firm limits.
- No non-Clifford gates. A single T gate or arbitrary rotation means the state no longer has a short stabilizer description. A stabilizer simulator has to refuse the circuit, or a different method has to take over.
- No amplitude vector. The amplitudes are exactly what the method avoids building. You cannot inspect phases, and you cannot draw a single-qubit Bloch sphere from the result.
- Results are measurement samples. What the tableau supports cheaply is measurement. The output is a set of sampled outcomes, which you read as a histogram, rather than an exact list of probabilities.
It also matters what the method does not show. The gates it leaves out are the ones that make quantum computation hard to simulate classically. A large Clifford result is real, but it is not a sign that a simulator can handle general circuits of the same size.
Where stabilizer simulation is the right tool
Clifford circuits are narrow in one sense and very common in another. Several workhorse circuits are Clifford:
- GHZ states. A Hadamard on the first qubit followed by a chain of CNOTs produces a state where every qubit is measured as all zeros or all ones together. It is a standard test of entanglement across a register, and it is entirely Clifford, so it can be simulated at widths no state-vector simulator could hold.
- Bell pairs and teleportation-style entangling steps, before any non-Clifford correction.
- Error-correction syndrome rounds. The circuits that check stabilizer codes, such as the surface code, use Hadamards, CNOTs and measurement to read out which checks fired. Studying how errors show up in those syndromes is one of the main practical uses of stabilizer simulation.
If your question is about measurement statistics in circuits like these, a stabilizer simulator is the natural choice. If your question needs amplitudes, phases or non-Clifford gates, it is not.
How SwiftQuantum IDE uses stabilizer simulation
SwiftQuantum IDE is a circuit editor and simulator that runs its simulation engines in your browser, on classical hardware. Alongside its state-vector engines, it has a stabilizer engine based on a stabilizer tableau, available on the Team and Enterprise plans; plan details are on the pricing page.
- Clifford-only, checked explicitly. The stabilizer engine accepts only an allowlist of Clifford gates: H, X, Y, Z, S, CNOT, CZ, SWAP and measurement. A circuit containing anything else is rejected by that engine with a message naming the gates to remove.
- A sampled result, labelled as such. A stabilizer run returns a sampled measurement histogram. The IDE states that there is no state vector or Bloch sphere for that result, instead of showing empty or invented panels.
- Automatic routing that respects the limit. With engine choice left on automatic, a circuit uses a state-vector engine whenever it fits that engine's cap. A Clifford-only circuit that is too wide for those engines goes to the stabilizer engine where your plan includes it. Add one non-Clifford gate, such as a T gate, and the circuit is a general circuit again: only the state-vector engines can take it, under their lower limit, and a general circuit beyond that limit is not run.
- You can choose. You can also pick an engine yourself, and the engine picker shows the cap that applies to it on your plan.
A good way to see the difference is to build a GHZ circuit, run it on a state-vector engine and look at the amplitudes, then run the same circuit on the stabilizer engine and compare the sampled histogram. The public gallery includes a GHZ state and a surface-code syndrome round to start from, and circuits move in and out as text through the OpenQASM editor.
Summary
Stabilizer simulation works because Clifford gates map Pauli operators to Pauli operators, so a state can be tracked as a compact table of stabilizer generators instead of an exponentially long list of amplitudes. That makes wide Clifford circuits, including GHZ states and error-correction syndrome rounds, cheap to simulate classically. The price is strict: no T gates or arbitrary rotations, no amplitude vector, and results that come as measurement samples. Knowing which side of that line a circuit falls on tells you which kind of simulator to use.
You can create an account to try the editor, and see which plan includes which engine on the pricing page.
Open SwiftQuantum IDE, build a GHZ circuit, and compare a state-vector run with a stabilizer run.
Get started