Part II. Mathematical Core

Matrices as Gates

Every gate in a quantum program is a matrix, and every matrix is a multiplication you can do by hand in under a minute. This chapter gets you multiplying — X, Z, and H against real state vectors — until gate notation becomes arithmetic instead of vocabulary.

Listen to this chapter

A gate's meaning lives entirely in its matrix: the box on a circuit diagram is a nickname, and the only way to know what a gate actually does is to multiply it against a state.

This chapter drills the three one-qubit workhorses — Pauli X, Pauli Z, and Hadamard — until their action on any input is automatic, and shows why one quiet minus sign can decide what an entire circuit outputs.

Core concepts: Pauli X, Pauli Z, Hadamard, unitarity, relative phase.

Notice the minus sign after Z: no measurement of −|1⟩ can see it, yet the H that follows turns it into a state you can tell apart from the no-minus version. Phase is invisible until a basis change makes it visible.

Gates are matrix multiplication

A one-qubit gate is a $2 \times 2$ matrix, and applying it means multiplying that matrix by the state vector. One hard constraint rides along: a closed-system gate must preserve total probability, which forces the matrix to be unitary — the next chapter makes that condition precise.

The three workhorses, defined by their action:

X ∣0 ⟩ Z ∣0 ⟩ H ∣0 ⟩ H ∣1 ⟩ = ∣1 ⟩ X ∣1 ⟩ = ∣0 ⟩ = ∣0 ⟩ Z ∣1 ⟩ = - ∣1 ⟩ = (∣0 ⟩ + ∣1 ⟩) / 2 = (∣0 ⟩ - ∣1 ⟩) / 2

Each line is a matrix-vector product, not a slogan. X swaps the amplitudes. Z flips the sign of the $∣1 ⟩$ component. H reshapes each basis state into an equal superposition with a specific sign pattern — and that sign pattern is the whole point, as the worked example shows.

The matrices themselves

X = (0110), Z = (10 0 - 1), H = \frac{1}{2} (11 1 - 1)

A candidate gate is checked with the unitarity condition:

U^{†} U = I

which guarantees the matrix preserves the norm of every input state. The Hadamard carries one more identity worth memorizing: $H H = I$ . H is its own inverse, and because it turns computational-basis information into phase-sensitive superpositions, it opens an enormous fraction of the algorithms in this book.

Worked example: catching a phase

Apply H to $∣0 ⟩$ :

H ∣0 ⟩ = \frac{1}{2} (11 1 - 1) (10) = \frac{1}{2} (11) = (∣0 ⟩ + ∣1 ⟩) / 2

Now apply Z:

Z (∣0 ⟩ + ∣1 ⟩) / 2 = (∣0 ⟩ - ∣1 ⟩) / 2

Measure now and you would see fifty-fifty odds — the Z seems to have done nothing. Apply H once more:

H (∣0 ⟩ - ∣1 ⟩) / 2 = ∣1 ⟩

The outcome is certain. The Z changed only a relative phase, and the final H converted that phase into a bit flip you can measure. Three matrices, one lesson: what looks invisible in one basis can be decisive in another.

Where the intuition fails

The first trap is memorizing gate names without ever multiplying. Names are compression; the matrix is the payload, and a reader who cannot expand the compression cannot check anyone's work — including their own.

The second trap is reading a clean circuit diagram as proof of hardware feasibility. The matrix states the ideal operation. Real hardware approximates it with finite fidelity, finite timing, calibration drift, and connectivity limits. And a matrix that shrinks or stretches arbitrary state vectors fails the norm test: whatever it is, it is not a closed-system quantum gate.

The engineering view

Gate matrices are the instruction semantics of the circuit model, and they get interpreted at three distinct layers:

Ideal matrix — what the mathematics says the operation does.
Compiled circuit — what the transpiler emits for a specific device's native gate set and topology.
Physical operation — what calibrated pulses actually execute, with noise.

Debugging means locating the broken layer. If the ideal matrix result is wrong, no transpiler will save the program. If the ideal result is right but the compiled circuit is too deep, you have a resource-cost problem. If both are right but hardware counts are wrong, suspect noise, calibration, or connectivity. This is also why hand calculation keeps its value in the SDK era: it is the only layer you can check with a pencil.

What this buys you in diligence

When a tool claims to optimize circuits, ask which claim it is actually making: does it preserve the ideal unitary, reduce compiled cost, or improve hardware execution? These are different promises with different evidence. A strong tool can demonstrate matrix-level equivalence and a hardware-aware benefit; a weak one waves at speed and hopes you will not ask which layer improved.

Exercise

Multiply the gates by hand. No simulator, no SDK — pencil and column vectors only.

Submit: the products of H, X, and Z against each of $∣0 ⟩$ , $∣1 ⟩$ , and $(∣0 ⟩ + ∣1 ⟩) / 2$ , with every intermediate vector shown.
Check: verify at least one result using $H H = I$ , and confirm every output vector is still normalized, as the unitarity condition requires.
Repair: if the multiplication itself is shaky or you keep treating phase as probability, redo Chapter 10 (Inner Products, Orthogonality, and Projection) first.

Check your understanding

Answer without notes: apply X, Z, and H to both basis states and to $∣ + ⟩$ , and verify each result stays normalized.

A passing answer shows the actual matrix-vector products, keeps signs attached to the correct components, and notices that Z can change a state without changing any immediate measurement probability.

Oral defense: derive $H Z H = X$ directly from the matrices — no pictures, no sphere.

If you get stuck

If the matrix-vector mechanics themselves are the problem, go back to Chapter 9 (Vectors, Bases, and Amplitudes); if the sign and probability rules are the problem, Chapter 10 (Inner Products, Orthogonality, and Projection) is the repair. Then redo the worked example until the minus sign stops surprising you.