Does the speedup survive a harder option?
Quantum Amplitude Estimation beats classical Monte Carlo on a vanilla option — I proved that already, on real IBM hardware. A swing option is a different animal: several exercise dates, all fighting over one shared limit, so no single decision stands alone. Nobody had pointed QAE at that. Two literature searches came back empty. So I built it and found out.
Vanilla options, baskets, Bermudan options — all published, all covered. Swing options: nothing. That gap is real, not assumed; I checked it twice. Every number on this page gets checked against a second, independently-built method before I trust it enough to write it down. Whatever it says is what goes on the page — including the version (v2, below) that looked like a clear win until I actually measured its total cost and found out it wasn't.
Why a swing option is a harder problem
Common in gas and power contracts: the holder gets several exercise dates, and at each one may take a unit at a fixed strike or skip — but the total taken across every date must stay within a floor and a ceiling.
That shared limit is the whole problem. Price a strip of independent options one date at a time — fine, easy. A swing option won't let you: whether today's worth taking depends on how many you've already taken and how many chances are left. The dates are stuck to each other. Toy version here: 3 dates, take 1 or 2 units total, same market numbers as the earlier vanilla-option study (S₀=2.0, vol 40%, rate 5%, strike 1.896) — so the two sit next to each other honestly.
Caught by disagreement, not inspection
The first version of the classical pricer had a real bug: it chose each date's exercise decision before that date's price was actually known, then applied the same decision no matter what price came in — quietly deleting the one thing that makes an option valuable.
The tell
It passed its own test. Of course it did — the test was built on the same wrong assumption, checking the bug's homework with the bug's own rulebook. What actually caught it: a second, separately-built Monte Carlo pricer kept coming back higher. Higher is backwards. A worse decision process can only lose value, never gain it. That contradiction is what made me stop and go looking.
Buggy price, at increasing precision
Simplified to one date so I could check it by hand. It doesn't just miss — notice more precision made it miss with more confidence. Wrong, and getting surer of it.
After the fix
Move the decision to after the price shows up — the only order that actually makes sense — and the same pricer lands at $0.1508, matching two separate outside checks (Monte Carlo, and a numerical integration built from scratch, no shared code) to a fraction of a percent. Every brute-force check in the rebuilt version passes clean now.
It survived its own test suite. It didn't survive a second method disagreeing with it.
Encoding a path-dependent payoff exactly
With the classical policy verified correct, the quantum circuit encodes every possible discretized price path's payoff under that fixed policy, then lets amplitude estimation extract the expected value.
At this resolution there are 64 possible price paths. Instead of approximating, I encoded all 64 exactly — one rotation per path, each carrying that path's real payoff under the verified policy. Exact, but not cheap: a vanilla option's payoff collapses into a handful of comparator gates. A path-dependent, multi-decision payoff doesn't obviously collapse into anything small. Finding out how is the real open question — this version answers a different one first: is it even right?
The classical exact answer lands inside the circuit's own confidence interval. It's measuring the right thing.
The circuit and the (now-fixed) classical model agree.
The speedup law survives. The cost doesn't, yet.
Same measurement as the vanilla-option study: sweep target precision, count how the required work actually scales for each method.
Result
At the tightest precision I tested: about 20,000 classical samples against something like 1.6 billion quantum gate-operations for the same accuracy. Each quantum query here just costs a lot more than each classical sample does.
What that actually means
The part that matters theoretically is real: fewer queries needed as precision tightens, on a payoff nobody had pointed this at before. That's a genuine result. But this version's circuit makes every query so expensive that the total cost loses to classical at every precision I could actually test, and since both curves grow at almost the same rate, that gap isn't closing on its own. The advantage is real. Making it matter is a different, harder problem — an open one, not a solved one.
A real result either way: the advantage isn't automatically killed by path-dependency, but this encoding isn't the one that makes it practical.
A real structural insight, spent the wrong way
v1's circuit is exponential because it treats every one of the 64 price paths as its own separate case. Two facts, both checked before I trusted them, say it doesn't have to be that way.
What actually makes it cheaper
First: the optimal decision at any date only depends on the current price and how many units are already taken — never on how you got there. I didn't assume that, I checked it, by grouping every decision in the policy by price instead of by path and confirming zero disagreements. Second: the price grid turned out to be evenly spaced, which means the current price is just a running sum of small numbers — something a quantum circuit can add up cheaply, instead of needing to look at every qubit of every date at once.
Rebuilt the circuit around that: one small lookup per date instead of one giant lookup for the whole path. Verified correct again, matching the exact price to within a millionth of a dollar.
Per-query cost — a real win
Cheaper per oracle call than v1, and the gap explodes as the contract gets longer — this part of the story is real.
The part I got wrong at first
This version accumulates each date's payoff by nudging a single qubit's rotation a little at a time — a small, deliberately gentle nudge, because the technique only stays accurate if the nudges stay small. But amplitude estimation's query count is governed by how small a change it has to resolve. Gentler nudges mean it has to work proportionally harder to notice them. Redoing the full cost comparison — queries needed times cost per query, not just cost per query alone — that extra cost turned out to be bigger than the savings at every precision and every calibration I tried. This version is worse than the original, not better.
The per-date decomposition is genuinely cheaper. Nudging one qubit to add up the payoffs erases that gain and then some — caught only by finishing the actual math instead of stopping at the flattering number.
Keeping the real insight, fixing the accumulation
The per-date decomposition was never the problem. The nudging was. So keep the first part exactly as it was, and replace only how the payoffs get added up.
The fix
Instead of nudging a qubit's rotation, add each date's payoff into an actual running-total register, using the same kind of addition circuit that computes the price sums — verified separately first that it really does add onto an existing value rather than overwrite it, and that its own scratch qubits clean themselves up automatically. Only at the very end does the circuit convert that final total into a rotation, using v1's original exact method, just applied once to a small accumulated number instead of once per raw path.
Verifying it — the honest version
Direct simulation of this circuit hit a real wall: it hung for long stretches on circuit sizes that should have been fast, and I never fully root-caused why, even after ruling out several specific explanations. Rather than force it, I verified the formula the circuit is supposed to compute directly in plain code — no quantum simulator involved — and confirmed it converges cleanly to the exact price as precision increases. Then I checked it against the one circuit run that did complete: the two numbers matched exactly. Formula converges to the true price, circuit matches the formula — together that's a complete verification, just assembled from two directions instead of one straight line.
Cost vs. v1 — the gap that was actually there
Barely ahead of v1 at toy scale — the accumulation step adds its own real cost back — but the gap grows exactly the way the per-date decomposition predicted, without v2's query penalty dragging it down.
Does it finally beat classical?
No. And the reason is the actual finding here: whether quantum beats classical on this problem is decided by how the precision target scales — the same quadratic-vs-linear gap from the vanilla-option study — not by how long the contract is. Classical Monte Carlo's own cost grows too, as longer contracts mean noisier payoffs, so the ratio between the two stays roughly the same enormous order of magnitude whether the contract has 3 dates or 10. Building a cheaper circuit made the quantum side better relative to itself (v1, v2) by six orders of magnitude. It didn't touch the actual contest.
The efficient decomposition works once paired with the right accumulation method — a real, six-order-of-magnitude improvement over the first attempt. Beating classical needs a different kind of improvement than either attempt found.
Small enough to check, too deep to trust
The vanilla-option version of this project survived real IBM hardware cleanly. So does swing v3 — at least the part of it that fits on a single date — hold up the same way?
Checking before spending queue time
Before submitting anything, I checked how deep v3's circuit transpiles on a real 156-qubit device, against the vanilla-option circuit that already ran clean on hardware once.
| Circuit | Qubits | 2-qubit gates | Depth |
|---|---|---|---|
| Vanilla option (already validated on hardware) | ~10 | 157 | 463 |
| Swing v3, toy scale (3 exercise dates) | 43 | ~53,000 | ~102,000 |
| Swing v3, smallest possible (1 exercise date) | 26 | ~5,100 | ~10,000 |
Even the smallest swing option — one date, take it or don't — needs about 33× more two-qubit gates than the circuit that already survived hardware. At real device error rates, that many sequential two-qubit gates should wash out into noise well before the measurement means anything. I said so before running it, then ran it anyway to find out for real instead of stopping at the estimate.
What came back
| P(payoff = 1) | Implied price | |
|---|---|---|
| Exact price, from the formula (no simulator) | 0.2176 | 0.1327 |
| Noiseless simulator, independent check | 0.2229 | 0.1360 |
| Real IBM hardware | 0.4277 | 0.2609 |
| Pure noise (a coin flip) | 0.5000 | — |
The hardware number sits 0.21 away from correct but only 0.07 away from a coin flip — closer to decoherence than to signal. That's the depth estimate confirmed with a real chip instead of left as arithmetic. It also comes with a small bonus: the noiseless simulator run is a second, independent confirmation that v3's exact encoding is actually correct, at a size I hadn't checked before.
Where I almost overstated it
My first draft of this section said the same simulator wall from verifying v3 also blocked the noiseless baseline here, on both simulation methods. That was half right: one method genuinely stalls at this size too. The other one didn't — it just needed four and a half minutes instead of a few seconds, and I'd stopped watching it before it finished. I caught it by waiting for the slow job instead of trusting the assumption, and fixed the writeup before calling this done. "Looks stuck" and "verified stuck" aren't the same claim.
Swing v3's exact encoding is too gate-expensive for today's hardware to trust, even at the smallest contract it can price — a second, independent reason (depth, not just query count) this doesn't reach practicality yet.
What it means
This isn't a "quantum wins" story or a "quantum loses" one. It's finding out which, on a question nobody had checked, through three actual builds instead of one, and saying plainly what each one found — including the one that made things worse.
- A gap in the literature is a starting line, not a result. Confirming nobody had tried this was the easy part. The actual findings — the query law holds, a plausible optimization can quietly lose more than it wins, fixing that gets most of the way back — only showed up once I built each version and measured it.
- A win on paper isn't a win until you finish the math. v2 looked like a clean improvement on the metric I checked first (cost per query). It wasn't an improvement at all once I checked the metric that actually mattered (total cost). Reporting the first number and stopping there would have been a real, avoidable mistake — the only reason it isn't in this study is that I went back and finished the comparison instead of trusting the flattering half of it.
- The bug and the tooling wall got the same treatment. A quiet, self-consistent mistake that passed its own test only got caught by a second, independent method disagreeing with it. An unexplained performance wall in verifying v3 got worked around with an independent argument instead of either ignored or used as an excuse to stop. Same discipline both times: don't claim more certainty than what was actually checked.
- Cost shows up in more than one currency. The total-cost finding above is about how many queries the oracle needs. Real hardware validation found a second, independent bill: how many physical gates the oracle itself costs, and whether a real chip stays coherent long enough to pay it. Even the smallest possible swing contract doesn't — a different way of confirming the same conclusion, not a repeat of it.