64. Quantum Computing from a Laptop
64.1State-Vector Simulators
The workhorse tier (Ch. 17 built yours): exact amplitudes, full observability, ~30-qubit ceiling on a well-equipped laptop, ~50 on a fat workstation or HPC node. What it uniquely gives: ground truth — exact probabilities, exact expectation values, exact circuit unitaries — making it the arbiter for every other method. Professional patterns: Statevector/Operator checks as assertions in test suites (Ch. 16.15), exact reference curves that noisy and hardware results are compared against (Ch. 54.2's baseline ladder), and amplitude-level debugging (inspecting phases, not just probabilities — Ch. 16.14). Limits to respect: exponential memory, zero noise (a feature and a lie — your "results" lack the physics that makes hardware hard), and silent swapping-to-disk death past n≈32. Treat it as your laboratory's cleanroom: where perfect things are measured.
64.2Tensor-Network Simulators
The reach extender: represent states as contracted tensor networks (MPS/PEPS — Ch. 17.15 introduced, here operationalized) and simulate circuits whose entanglement stays bounded, regardless of qubit count. Tools: quimb (Python, excellent), ITensor (Julia), Aer's method="matrix_product_state". What this unlocks on a laptop: 50–100+ qubit shallow circuits (the VQE/QAOA-scale ansätze of Part XIII, random shallow circuits, QEC syndrome-extraction circuits — Ch. 35's d=3,d=5 demos fit comfortably), time evolution of 1D spin chains (the physics of Ch. 47, at sizes state-vector can't touch). What it costs: bond dimension grows with entanglement — deep circuits on all-to-all problems hit the wall and fail honestly (memory blowup) rather than inaccurately; set the bond dimension consciously and report it. Rule of thumb: if your circuit has structure (locality, symmetry, low depth), try tensor networks before assuming infeasibility.
64.3Stabilizer Simulators
The Clifford tier (Ch. 17.14's theory, deployed): simulate {H, S, CX, measurement} circuits on thousands of qubits in microseconds — the tool that makes error correction laptop-accessible. The engine: stim (Google's, the field standard — tableau simulation with sampling rates of millions of shots/second on circuits of thousands of qubits). What it unlocks: the entire QEC curriculum of Part X as hands-on experimentation — surface-code memory experiments, threshold studies (Ch. 37's project runs d=3→d=15 with full statistics in minutes), syndrome-circuit optimization, decoder evaluation against exact circuit-level noise. The boundary: no non-Clifford gates (T breaks it — Ch. 27's structure again), so algorithm-scale circuits need the other tiers. Your laboratory's accelerator: stim plus your Ch. 37 decoder is a genuine research instrument, worth more than most university labs had a decade ago.
64.4Noisy Simulators
The realism tier: simulate the physics that makes hardware hard — decoherence, gate errors, readout error — with known ground truth to compare against. Engines: Aer with NoiseModel (depolarizing, thermal relaxation, readout error per qubit/gate; from_backend imports real-device snapshots — Ch. 54.6's calibration-based tier), and stim's circuit-level noise (Pauli channels with measurement errors — the QEC-standard model). The experimental discipline this enables: predicted-vs-actual gap analysis (ideal → noisy-sim → hardware; the two gaps quantify "noise effects" and "model mismatch" separately — Ch. 54.5's decision tree realized), error-mitigation validation (does ZNE help on the noisy simulator before you spend hardware shots — Ch. 31), and noise-sensitivity studies (sweep error rates, watch algorithms degrade — Ch. 49.8's plateau experiments). Your lab's wind tunnel: nothing flies here that hasn't survived it.
64.5Circuit Visualization
The laboratory's instruments include its eyes: circuit drawings (Ch. 16.12 — draw('mpl'), layout overlays, timeline views), state visualizations (Bloch, QSphere, cityscape — Ch. 16.13), and the QEC-specific views you'll grow into (stim's detector-error-model diagrams, decoder match graphs rendered as figures). Professional practice: visualization is debugging, not decoration — draw before running (the 30-second rule), and visualize distributions over parameters (the fringes and oscillations of Ch. 16.13) rather than single shots. For your lab reports (Ch. 62.4's notebooks): every figure states its regime (ideal/noisy/hardware), shot count, and error bars — a figure without error bars is a sketch, not a measurement. Matplotlib defaults are fine; honesty conventions (Ch. 54's) are the professionalism.
64.6Numerical Experiments
The simulator tiers assembled into methodology — Ch. 54's discipline, simulator-native. The patterns that make laptop studies publishable-grade: parameter sweeps with fixed seeds and reported distributions (never a single trajectory); scaling analyses (fit observables vs. n; exponents with confidence intervals — Ch. 55.4's scale-cliff detector); regime maps (the same experiment across noise models — depolarizing → calibration-based → circuit-level — results that hold across regimes earn their claims); and compute-budget accounting (report CPU-hours like hardware papers report device-hours — it's the field's honesty currency for simulation work). Tooling: the Ch. 54.10 tracking stack (SQLite/MLflow log, every run hashed); Jupyter for exploration, scripts for production runs — and the two stay separated, because notebooks that ran the paper are reproducible only if the script regenerates every figure.
64.7Cloud Quantum Computers
The real thing, from your desk: IBM Quantum's open access (free tier, real superconducting processors, queue-based — the singular resource most open to the Iran-based reader; no payment rails required), AWS Braket and Azure Quantum (pay-per-use platforms hosting IonQ, Quantinuum, Rigetti, Pasqal hardware — payment requires the Ch. 63.10 workarounds, but free credits programs exist), and QuEra/Quantinuum direct-access programs for research. What cloud access gives you that simulation cannot: drift (calibration data changes daily — your circuit's results are a function of time), crosstalk and correlated errors (the physics Ch. 54.6's models miss), real queue economics (batch design matters — Ch. 16.9), and the professional skill of extracting signal from an uncooperative machine. Treat every cloud device as a remote colleague: brilliant, moody, documented only approximately.
64.8Remote Hardware
Working with real processors, professionally: the workflow disciplines that convert queue time into results. Pre-flight everything — ideal sim, noisy sim, small-n hardware validation before committing the big job (Ch. 54.5's tree, enforced by quotas); batch ruthlessly — many circuits per job, parameter sweeps packed together, because queue overhead dominates; pin everything — transpilation seeds, layout choices, calibration snapshot dates (pull backend.properties() with each run — Ch. 45.9's drift awareness); over-sample — shots are cheap relative to queue waits; archive raw — every job's raw counts + metadata to your log, because cloud data expires (results purge after days; the calibration data that explains them purges too). The remote-hardware researcher's edge is metadata discipline: the engineer who can explain why Tuesday's results differ from Friday's is doing metrology; everyone else is collecting souvenirs.
64.9Benchmarking Remote Hardware
Measure the machine yourself — the highest-value laptop-and-cloud skill, because published benchmark numbers age fast and vendor metrics game (Ch. 57.7's caution applies to devices). Your toolkit, executable on free tiers: randomized benchmarking (interleaved RB for per-Clifford error rates — the standard protocol, implementable in a day), readout-error matrices (prepare-measure each basis state; invert in post-processing — immediately useful mitigation), T1/T2 estimation (delay-scan experiments — inversion recovery and Ramsey; Ch. 30's theory, measured), GHZ decay vs. separation (entanglement quality as a function of qubit distance — a crosstalk probe), and Deutsch–Jozsa/QAOA-micro sanity circuits (known answers, measuring the machine against theory). Run the suite on your allocated device before trusting it with experiments — an afternoon of benchmarking saves weeks of confounded results, and the resulting calibration report is a portfolio piece (Ch. 62.2) almost nobody has.