Solitaire, Sickness, and the Invention of Monte Carlo

The technique quants use to stress-test everything was invented by a physicist who was bored, sick in bed, and losing at solitaire.

Share
Monte Carlo estimation of pi with random points and a convergence chart

Most of the quantitative methods we rely on have origin stories that nobody remembers. Regression traces back to astronomers arguing over comet observations, and Bayesian inference spent long stretches of the last two centuries out of fashion before computers made it practical. Monte Carlo simulation, the technique used today to stress-test everything from portfolios to power grids, has one of the better ones: it was invented by a physicist recovering from an illness, passing the time with a deck of cards. I recently wrote about this story in another article and realized it deserved its own post.

The Solitaire Problem

In 1946, the mathematician Stanislaw Ulam was recovering from encephalitis and playing a lot of Canfield solitaire. At some point he started wondering what the odds of winning a hand actually were. He tried to work it out properly with combinatorics, and the calculation turned out to be hopeless: the number of possible card arrangements was simply too large to reason through exactly.

The idea that followed sounds almost too simple. Instead of calculating the odds, he could just play a hundred hands and count how many he won. The counted frequency would approximate the true probability, and playing more hands would sharpen the estimate. That substitution, replacing an intractable exact calculation with repeated random sampling, is the core of the entire method.

From Cards to Bombs

Ulam brought the idea back to Los Alamos, where he and John von Neumann were working on a problem with the same basic shape: how neutrons travel through material in a weapon core. Each neutron scatters, gets absorbed, or escapes with known probabilities, but the combinations multiply beyond any closed-form answer. Their solution was to simulate thousands of individual neutron journeys on ENIAC, the first general-purpose electronic computer, and read the answer off the resulting distribution.

The work was classified, so it needed a code name. Their colleague Nicholas Metropolis suggested Monte Carlo, after the casino in Monaco where Ulam's uncle liked to gamble with borrowed money. The name fits: the method really is just gambling, run deliberately and at scale, with the randomness put to work instead of bet against.

Why Counting Works

The reason this works at all is the law of large numbers: sample enough times and your average converges toward the truth. The classic demonstration is estimating π by throwing random darts at a square with a circle inscribed in it. The fraction of darts that land inside the circle, multiplied by four, approximates π, and no geometry is required beyond counting.

Scatter plot of 3,000 random points estimating pi, next to a convergence chart showing the estimate settling toward 3.14159 as samples increase
Three thousand darts get you to 3.14. The right panel shows the estimate settling as the sample count grows.

The convergence chart is worth a closer look, because it shows the method's main limitation. The estimate improves quickly at first and then slows down considerably: precision scales with the square root of the sample count, which means each additional digit of accuracy costs about a hundred times more samples. Monte Carlo is best suited to problems that are too tangled for exact methods, where a decent approximation of the whole distribution beats a precise answer you can never actually compute.

The Takeaway

What stays with me from the story is the permission Ulam gave himself to stop solving and start counting. When a system has too many interacting parts to reason about exactly, repeated honest sampling is often the more productive path. This resonates with me personally. I have always struggled with the urge to nail the precise answer, and the corporate world keeps teaching me that precision often matters far less than directional speed. The same goes for personal projects, where moving quickly keeps motivation up, and at the dollar amounts an individual works with, the extra digits rarely change the decision. Rocket science would be another matter.

That is the same instinct behind simulating a portfolio instead of predicting it: rather than asking for the answer, ask for the distribution of answers, and plan against that.


Feature image: "Why did you roll your dice, show your cards..." by Alex Bellink, licensed under CC BY 2.0.