The technical details

Because quantum mechanics, for all its strangeness, is exactly predictable arithmetic. Physics says the complete state of n qubits is a list of 2ⁿ numbers, one for each possible outcome: two qubits is a list of four numbers, and my 22-qubit test problem is a list of about 4 million. The simulator stores that list in memory. Each quantum gate is a matrix, and running the circuit means multiplying the list by one matrix after another, ordinary arithmetic. So my laptop imitates a quantum computer the way a weather model imitates a storm: nothing quantum happens inside the machine.

Interference is not faked either; it falls out of the arithmetic. The numbers in the list can be negative, so when two paths lead to the same outcome they can reinforce (+0.5 and +0.5) or cancel (+0.5 and -0.5). That canceling is interference, and QAOA's whole job of making cheap schedules likely is, on the simulator, additions where some terms carry minus signs. Measurement is just as plain: square each number to get a probability, then roll dice by those probabilities. The 4,096 draws in my results were 4,096 dice rolls.

The catch is the size of the list. Every qubit doubles it. My 6-qubit test problems need only 64 numbers, but each round of tuning updates the whole list again and again, which is why the 22-qubit simulation took about 20 to 40 minutes. At about 30 qubits, roughly a billion numbers, the list outgrows my laptop's memory. At 50 it outgrows every classical computer on Earth. At the 156 qubits of ibm_fez, the list would need roughly as many numbers as there are atoms in all of Earth's oceans. A real quantum chip never stores this list at all: its qubits simply are the physical state the list describes, and nature carries the bookkeeping for free. That doubling is the wall, and it is also the entire reason quantum computers might someday matter.

One more consequence: because the simulation is exact arithmetic, its qubits are perfect and noise free, the ideal machine. Real qubits are not, which is exactly why the simulator and hardware results differed, and why running on ibm_fez was the actual test.

Yes, and that is the right first instinct. Different homes just mean different inputs to the same easy problem, and my program solves any one of them in a tenth of a millisecond. Ten thousand independent homes is ten thousand independent solves, no quantum computer required. Any pitch that jumps from “many households” straight to “therefore quantum” is skipping something.

What it skips is that at scale the homes stop being independent. A neighborhood transformer can only carry so much charging at once, and every battery reading the same price schedule reaches the same conclusion at the same moment: charge now, it is cheap. Two hundred individually perfect plans can add up to a physically impossible one, and enough batteries chasing the same cheap hours reshape the very demand pattern the prices were built on, creating a new spike at the exact moment the cheap rate begins. Once your best plan depends on what your neighbors' batteries do, the problem couples, and coupled planning is where exact classical methods hit their own exponential wall, the same doubling that stopped my laptop, now on the classical side.

Even then, classical computing does not simply give up: clever decomposition methods keep a fast per-house solver as the inner engine and coordinate the fleet around it, and they work well. The quantum bet lives at the far end, on problems so tightly coupled that even the clever classical tricks degrade, and whether quantum methods will ever win there is an open question. My one-house problem is a scale model of that giant, small enough that I know the exact answer, so I can measure how far today's quantum methods actually stand from the goal. Right now, the measured distance is large.

Measured, not guessed: the study is committed to the repo (docs/results) as a CSV and four plots, all produced on the noise-free Aer simulator. Across instances from 2 to 6 time slots (6 to 22 qubits once slack variables are counted), with up to 3 QAOA layers, 4,096 shots, and multiple restarts: at 6 qubits QAOA returns the exact optimum on every instance, by 14 qubits only sometimes, and at 18 to 22 qubits, with this few layers, never.

The yardstick for sampling quality is the exact probability that a single uniformly random bit-string is optimal, computed by counting the optimal states (the formula the Monte Carlo regression test guards). Against it, the 6-qubit results were mixed: the best runs put 2 to 4.5 times more probability on optimal schedules than chance, the single-layer circuit roughly doubled the odds averaged across instances, and several deeper runs fell well below the random baseline. Beyond about 14 qubits the optimal mass drops below what 4,096 shots can resolve, so only upper bounds remain.

The exact dynamic program answers every one of these instances in a fraction of a millisecond. So on today's setup the quantum method is measurably better than guessing and far slower and less accurate than the classical solver, and there are now numbers that say precisely by how much. The chart further down this page shows the headline comparison.

The short answer: at my problem sizes, not for the answers. The simulator computes them instantly, exactly, for free. If the goal were just the result, real hardware would add only queue time and noise.

I need it for three other things. First, to turn a prediction into an experiment. Everything from the simulator is theory: the exactly calculated forecast of what an ideal quantum computer would do. The hardware run is the moment this project stops saying “quantum mechanics implies these statistics” and starts saying “I sent these circuits to actual superconducting qubits near absolute zero, and here is what came back.” Second, to measure the one thing the simulator cannot contain: noise. Real qubits drift, gates misfire slightly, readouts flip, and how much depends on the specific chip, the specific day, and my specific circuits. The gap between the ideal distribution I already have and the hardware distribution I can only measure is a number that exists nowhere except in the experiment. It also probes a real tension: deeper circuits should be sharper in theory but are noisier in practice, and I compared one layer against two on the real machine (the outcome did not settle it cleanly; the ordering reflected how well each circuit had been tuned more than its depth). Third, because the simulator is a dead end and hardware is the road. My own scaling study walked up to that wall: past about 30 qubits my laptop cannot even hold the list, and past about 50 no classical computer on Earth can. Any future where quantum optimization matters runs on hardware by necessity. So I am doing what you should do with any vehicle before trusting it past the last checkpoint you can verify: driving it on the stretch of road where I still know the right answer.

In one line: the simulator tells me what a perfect quantum computer would do. The last question is what a real one does, and that can only be measured, not simulated.

Three gated stages, so nothing reaches the real machine by accident:

1. Tune. Set the QAOA angles on the local simulator and save them. This is done, and the parameters are committed to the repo.
2. Dry run. Print the chosen backend, the transpiled circuits, the shot count (4,096), and the estimated seconds of QPU time, without submitting anything.
3. Submit. Send it for real, only behind an explicit confirmation flag, so IBM's roughly ten free minutes a month cannot be spent by accident.

An analysis notebook then compares the sampled schedules from three sources (exact solver, simulator, and hardware), including the total variation distance between the distributions, to measure how much real-device noise changes the answer.

The run is also pre-registered: a document committed before any hardware results exist records the circuits (four tuned QAOA circuits, 6 to 10 qubits, on an IBM Heron device), the metrics, the interpretation rules for each possible outcome, and a falsifiable prediction: the shallower reps=1 circuit should retain at least as much optimal-state mass as the deeper reps=2 circuit, because extra two-qubit gates add device noise. The analysis pipeline was rehearsed end to end on synthetic counts, so when the real counts came back from ibm_fez they dropped into a finished report. The results are on the project page.

Three loaders, all real and mutually coherent for Golden, Colorado:

• Solar comes from NREL's PVWatts model through its public API: given a location and a panel setup, it returns a physically modeled hourly generation profile, which I validate with sanity checks (no generation at night, plausible daytime peaks) and test offline against saved responses, so the test suite never depends on the network.
• Prices come from the OpenEI Utility Rate Database entry for Xcel Energy's Colorado Residential Energy TOU tariff (Schedule RE-TOU), flattened into an hourly $/kWh series using all-in prices, with the tariff snapshot and its caveats documented in the repo.
• Household load comes from NREL's ResStock End-Use Load Profiles: a representative Colorado single-family-detached summer-weekday profile, about 30.5 kWh per day, packaged as a local CSV with no network calls and its derivation documented.

On the real summer-weekday instance (PVWatts solar, RE-TOU prices, ResStock load), the house with no solar and no battery pays $6.11 for the day; with solar and an idle battery, $1.43; with the DP-optimal battery schedule, -$0.50, slightly ahead. Solar alone accounts for $4.68 of the saving; optimal scheduling adds $1.93 of pure price arbitrage, a figure independent of the load level, since arbitrage only moves energy across prices. The schedule is also required to end the day with the battery at its starting level, so the saving cannot come from secretly spending down charge that tomorrow would have to buy back.

Three caveats before extrapolating from this one day:

• The RE-TOU weekend schedule is flat, so arbitrage is worth $0 two days a week.
• Winter TOU prices are lower, so an annual figure needs representative days across seasons.
• The model currently assumes net metering at the retail rate with no round-trip battery losses.

Both refinements are on the roadmap.