Computation Is Physical

A bit is a thing, not a symbol

Computation is a controlled physical process that represents and transforms information. A bit is not the symbol 0 or 1 floating free of the world. It is a physical state — charge in a circuit, a magnetic domain, a voltage level — that we agree to read as 0 or 1. The agreement is arbitrary; the physics is not.

Classical engineering spent fifty years making the physics disappear. A modern laptop's bits are so stable that programmers can forget they are physical at all. Quantum computing offers no such luxury. The state is fragile, the control signals are analog, and the act of measurement changes what is left to measure. The physics is present from the first line of every quantum program, which is why this book starts here rather than with notation.

The first accurate sentence about quantum computing is not that it is strange. It is that it uses a different physical state space, and different allowed transformations, than an ordinary digital machine.

Four questions define a computer

Every computational model, classical or quantum, answers the same four questions:

1. State space. What configurations can the system be in?
2. Allowed transformations. What operations can be applied to those configurations?
3. Input and output rule. How does a problem get in, and how does an answer come out?
4. Cost and error model. What does each operation cost, and what goes wrong?

For one classical bit, the state space is the set $\{0,1\}$. For a register of $n$ bits it is the $2^n$ basis states, and a deterministic gate maps each basis state to another. Add randomness and you get probability distributions over basis states — still a classical model.

A quantum register keeps the same basis states but describes its condition with amplitudes over them. That is a richer description, and it is the source of everything quantum computing can do — but it comes with a catch that no amount of enthusiasm removes: you cannot read the amplitudes out. Measurement produces one classical record, drawn according to rules the amplitudes determine. The computation lives in the transformation; the answer you keep is classical.

So the physical version of the four questions becomes: What stores the state? Which transformations can you actually apply, at what error rate? What does the environment do to the state while you work? And what classical data does measurement produce? A claim that cannot answer these is not yet an engineering claim — it is a hope.

Worked example: reading a pitch

A company deck says: "Our processor has many qubits, so it can evaluate many possibilities at once." Translate the slogan into physics:

• State. What is a qubit in this machine — a superconducting circuit, an ion, a photon? What is its two-level system made of?
• Control. Which gates can be applied, and with what measured error rates?
• Coupling. Which qubits can interact, and how long does an interaction take?
• Time. How long does the state stay coherent compared to the circuit you want to run?
• Measurement. What classical record comes out, and how often is it wrong?
• Algorithm. Which amplitude pattern is the computation trying to create?
• Baseline. What does the best classical method do on the same problem?

Now the claim is inspectable. A machine with many qubits but poor control, short coherence, sparse connectivity, and no algorithm mapped to its strengths has not demonstrated useful computation — it has demonstrated a large number. A smaller machine with excellent control and a credible error-correction path may be far more relevant. The lesson is not that qubit counts are meaningless. It is that a qubit count is one physical input to a computation claim, never the claim itself.

Where the intuition fails

The most common failure is to treat computation as something that happens in an abstract cloud, and to mention physics only when the conversation turns to hardware. For quantum computing that order is backwards. The state space, the legal transformations, the reversibility, the measurement rules, and the noise all come from the physical model. Skip the physics and you are left with vocabulary.

The second failure is quantum as a branding layer on ordinary software. Software matters — Part V of this book is devoted to it — but a quantum program must eventually compile to operations a physical device can execute. An elegant circuit with no credible hardware path is not a product, and a hardware milestone with no algorithmic use is not an application.

The engineering view

If you come from software, read this chapter as a reminder that abstraction is earned. Classical computing gave you stable layers — transistor, gate, instruction set, language, service — each hiding the one below. Quantum computing is still fighting to stabilize the bottom layers, so the hiding does not work yet.

A useful mental model: a qubit is an API with unusually harsh implementation constraints. It exposes operations, but those operations come with latency, noise, topology restrictions, calibration drift, and readout limits. A quantum algorithm is not pseudocode; it is a request for a physical process that may or may not survive compilation and noise. And every serious quantum claim must end where it began — classical input, classical output, and a classical baseline to beat.

What this buys you in diligence

When you evaluate a quantum company, the first question is whether the team owns a real physical bottleneck, a defensible abstraction over one, or only a story about future capability. A hardware company must show state preparation, control, measurement, scaling, and reliability. A software company must show its output survives real device constraints. An application company must show that a physical quantum process improves a real workflow against a named baseline.

A strong diligence memo therefore starts with the computation stack, not the press headline. The headline tells you what the company wants you to feel; the stack tells you what it can do.

Exercise

Deconstruct one claim. Find one current statement about a quantum device — from a company page, a talk, or a paper abstract — and write a one-page analysis answering the seven questions from the worked example. Use one classical computing example and one quantum hardware example.

• Submit: the one-page analysis, with the original claim quoted at the top.
• Check: underline every sentence that makes a claim about speed or scale. Next to each, write the physical evidence that would be required to believe it.
• Repair: if your analysis says or implies that a quantum computer works by trying all answers at once, redo it after Chapter 4, which dismantles that idea directly.

Check your understanding

Answer without notes: why is a quantum computer not just a faster classical computer?

A passing answer names the physical state, the allowed transformations, the role of measurement, the effect of noise, and the need for a classical baseline. It does not describe qubits as ordinary bits that hold more values, and it does not use the word "parallel" as an explanation.

Oral defense: explain a qubit to a smart colleague without reaching for a myth — no "0 and 1 at the same time," no "tries everything at once."

If you get stuck

If your answers lean on vague speed language, hide what measurement does, ignore the hardware, or treat the number of basis states as readable output, work through Chapter 4 (Qubits Without Mysticism) and Chapter 5 (Measurement and What It Does Not Mean) before going further. Those two chapters exist to repair exactly these failure modes.