Observables, Eigenvectors, and Measurement
An observable is a question you are permitted to ask a quantum state, and its eigenvalues are the only answers that can ever come back. This chapter connects that structure to the statistic everyone quotes: the expectation value.
The expectation value is the most misread number in quantum computing — an average over many identically prepared shots, never something a single measurement can return — and confusing it with an outcome corrupts both homework and benchmarks.
By the end you will read an observable's eigenvectors as its measurement directions, compute an expectation value by hand, and keep three things apart that sloppy writing merges: the average, the individual outcome, and the post-measurement state.
Core concepts: observable, eigenvector, eigenvalue, expectation value, sampling.
A measurable quantity is a matrix
An observable represents a measurable quantity. In the finite-dimensional circuit setting, observables are Hermitian matrices — equal to their own conjugate transpose. That single property buys two guarantees: the eigenvalues are real numbers, so they can serve as physical readings, and the eigenvectors form an orthonormal basis, so they can serve as a measurement basis. The eigenvectors define the measurement directions, and the eigenvalues are the only values a measurement of that observable can return.
For a state and an observable , the expectation value is:
Read that formula carefully. It is not the result of one shot. It is the average you would estimate by preparing the same state many times, measuring each copy, and averaging the outcomes. One number, three ideas — and the chapter hangs on keeping them separate.
Reading the Pauli Z
The canonical example:
Its eigenstructure answers the measurement question completely:
Measure Z and you can only ever get or , landing the qubit on or respectively. So the three objects are: the expectation value (an average, possibly any real number in between), the individual outcome (always an eigenvalue), and the post-measurement state (the eigenvector you landed on). Merge any two and measurement talk turns to mush.
Worked example: ⟨Z⟩ for |+⟩
Let:
Apply Z first:
Then the full sandwich:
The expectation value is , and no measurement ever returns . Each shot yields with probability and with probability ; the average over many shots converges to zero. The expectation told you the center of mass of the distribution — nothing about what one shot will do.
Where the intuition fails
The first trap is treating the expectation value as a possible outcome. For Pauli Z the outcomes are and , while the expectation can be any value in between depending on the state — an average need not be a member of the set it averages.
The second trap is quoting a benchmark without asking which observable was measured. Different observables answer different questions, and a number without its observable is a number without a question.
The engineering view
For a computer scientist, an observable is a query interface over a quantum state — one with physical rules. You never get the whole object back. You choose a measurement, collect samples, and estimate a statistic, and the statistic you get is tied to the observable you chose.
The working loop is: define the observable, prepare the state, measure many times in the appropriate basis (or a transformed one), then estimate. Everything in applied quantum computing runs this loop. A reported energy is usually a sum over many observable terms, each estimated separately. A device calibration metric may measure a convenient proxy rather than the final application target. When a number arrives, the professional reflex is: which quantity was actually estimated, and how many shots bought it?
The shot count is not a detail. Every estimate carries sampling noise that shrinks only like the inverse square root of the number of shots, so a claim of high precision is implicitly a claim about a large shot budget — which on real hardware means time, queue priority, and money. When two results look different, the first question is often not physics but statistics: were they estimated to the same precision?
What this buys you in diligence
When a company claims better fidelity, lower error, stronger optimization, or useful simulation, ask what was measured. State fidelity, an expectation value, a logical error rate, an energy estimate, sample quality, and a business metric are six different claims wearing similar clothes.
Distrust benchmark language that omits the measured observable. A metric can be technically valid and still irrelevant to the claimed use case — measuring the wrong thing precisely is still measuring the wrong thing.
Exercise
Estimate an expectation by hand. Work the Pauli Z example in reverse and then vary it.
- Submit: the expectation value of Z on , computed from the sandwich product, plus a description of the individual outcomes and their probabilities.
- Check: write one sentence each for the expected average, the possible outcomes, and the post-measurement state — three sentences, no overlap.
- Repair: if you treated the expectation value as a single-shot output, redo Chapter 10 (Inner Products, Orthogonality, and Projection) until the Born-rule chain is automatic.
Check your understanding
Answer without notes: compute an expectation value for a simple Pauli observable and compare it with what repeated shots would show.
A passing answer produces the sandwich product, names the eigenvalues as the only possible outcomes, and describes the expectation as the shot average rather than a shot result.
Oral defense: explain why on even though no individual measurement can return .
If you get stuck
If expectation values, eigenvalues, probabilities, and state updates are blending together, return to Chapter 10 (Inner Products, Orthogonality, and Projection). The sandwich product is one inner product wrapped around a matrix — nothing more, but nothing less.