Part II. Mathematical Core

Vectors, Bases, and Amplitudes

A statevector is not the state — it is the state's coordinates in a basis somebody chose, and half of all beginner quantum bugs live in the gap between those two things. This chapter closes that gap for good, with one state written two ways as the proof.

Listen to this chapter

Every number in a quantum calculation is basis-relative. An amplitude is a coordinate, not a physical quantity, and the unglamorous discipline of naming your basis, your ordering, and your normalization before computing prevents more real errors than any cleverness applied afterward.

By the end of this chapter you will be able to move a one-qubit state between ket notation and column vectors, verify it is a legitimate state, compute its measurement probabilities in a named basis, and spot the ordering-convention bugs that break multi-qubit code.

Core concepts: state vectors, the computational basis, coordinates, ordering conventions, the Born rule.

One state, two coordinate systems One state, two coordinate systems |0> |1> 1/sqrt(2) 1/sqrt(2) state Z basis: [ 1/sqrt(2), 1/sqrt(2) ] |+> |-> 1 0 X basis: [ 1, 0 ]
Notice that the arrow never moves — only the ruler does. In the Z basis the state spreads across both outcomes; in the X basis it sits exactly on one axis. The basis decides what the coordinates say, never what the state is.

Coordinates, not things

A quantum state vector is not merely a list of numbers. It is a list of coordinates relative to a basis — a chosen set of reference states — and changing the basis changes every number in the list while the physical state stays exactly what it was. Confusing the coordinates with the state is the root error this chapter exists to prevent.

The computational basis for one qubit is and . A state then has the coordinate vector : the amplitudes are the coordinates, one per basis state. Probabilities arrive only later, through the Born rule, after someone names a measurement basis.

This is why Part I could speak loosely and stay correct: every time a chapter said "the amplitude of ," it was naming a coordinate against the computational basis. From here on, the naming becomes your job.

Two rules every coordinate list must satisfy

First, normalization: . A coordinate list that fails this is not a quantum state, no matter how suggestive it looks — it is a scaling error waiting to contaminate a calculation. Check it before using a state, and again after constructing one.

Second, the Born rule, applied per basis: the probability of outcome is the squared magnitude of the amplitude on basis state . The rule is identical in every basis — what changes is the coordinate list you feed it. To measure in a different basis, re-express the state in that basis first, then square. Chapter 5's two-basis experiment is exactly this procedure, run twice on one state.

Worked example: one state, read two ways

Take . Legitimacy first: , so it is a valid pure state. In the computational basis its coordinate vector is , and the Born rule reads off , .

Now hold those numbers at arm's length. is not a property of the universe; it is a coordinate in one chosen basis, useful because the computational basis is what most hardware actually measures. A simulator stores the statevector under a basis convention; an honest explanation names the convention before quoting the numbers.

The figure pushes the point further with : coordinates in the Z basis, but in the X basis. Same state, same physics, two lists — and anyone who quotes you amplitudes without a basis has told you less than nothing, because the wrong assumed basis makes the numbers actively misleading.

Where the intuition fails

The first trap is speaking of "the amplitude of the state" without saying which basis state it belongs to. Amplitudes attach to basis vectors; an unattached amplitude is a number in search of a question. The fix is grammatical and costs nothing: always say "amplitude on " or "coordinate along ."

The second trap is ordering. A coordinate vector depends on the order you listed the basis states, and for multi-qubit systems the conventions differ across textbooks and SDKs. Swapping and in a four-entry vector is a real, shipped, production bug — the calculation runs, the numbers look plausible, and the answer is wrong. Pictures mislead here too: an arrow or a Bloch sphere builds intuition, but the calculation still needs coordinates, a named basis, and a normalization check.

The engineering view

For a computer scientist, a basis is a serialization scheme for state. Two systems with different ordering conventions encode the same abstract object differently, and quantum SDKs make concrete choices — basis ordering, qubit endianness, memory layout — that you cannot debug around without knowing. Reading another framework's statevector dump without checking its convention is parsing a file without its spec.

Statevector simulation itself is direct: store a complex array indexed by basis states, apply gates as matrix multiplications. What is not direct is readout — measurement samples according to squared magnitudes, and printing the array is a simulator privilege real hardware never grants. Keep the two mental APIs separate: the array for computation, the samples for answers.

The professional habit is three labels written before every calculation: basis, ordering, normalization status. It looks slow for one qubit. At eight qubits, with someone else's SDK and a deadline, it is the difference between a bug you find in a minute and one you find in a review.

What this buys you in diligence

When a software company claims better simulation, compilation, or debugging, this chapter supplies the questions. What representation does the tool store? Which basis and ordering conventions does it expose, and which does it hide? How does it keep users from confusing amplitudes, probabilities, and sampled results — three objects that look identical in a badly designed printout?

Good developer tools make the mathematical model inspectable; great ones make the conventions loud. A team that answers these questions crisply understands what its software actually manipulates, and a team that finds them surprising has been shipping coordinates without naming the basis.

Exercise

One state, two notations. Choose a normalized one-qubit state — if you want a clean one — and write it as a ket expression and as a column vector, then compute both measurement probabilities.

  • Submit: both notations, the normalization check, and the two probabilities — with the basis and coordinate ordering stated before the first number appears.
  • Check: re-read your answer and confirm every amplitude is attached to a named basis state and every probability names its measurement basis.
  • Repair: if you wrote probabilities without naming a basis, pick a second basis, re-express the state, and watch the coordinates change while the state stays put — that discomfort is the lesson.

Check your understanding

Without notes: write a one-qubit state in a named basis, verify normalization, compute the measurement probabilities, and explain what each coordinate means.

A passing answer treats the coordinate vector as a description rather than the state itself, names the basis before computing, and can say in one sentence why and can describe the same physical object.

Oral defense: a colleague shows you a two-entry vector and asks what the qubit "really is." Explain why the question is unanswerable until they tell you the basis — and why that is a feature of the notation, not a gap in it.

If you get stuck

If coordinates, normalization, and probabilities are blurring together, return to Chapter 8 (Complex Numbers for Quantum Computing) for the conjugate arithmetic that makes each step mechanical, and to Chapter 3 (Probability vs Amplitude) for the boundary between the two kinds of number. The rest of Part II assumes all three labels — basis, ordering, normalization — come naturally to you.