The basic idea
Some probabilities can be written down exactly. Others, such as the chance of a certain outcome in a long, branching game with many rules, are painful to calculate by hand. A Monte Carlo method sidesteps the algebra: it plays the situation out many times with random numbers, counts how often the event happens, and uses the frequency as an estimate.
The name refers to a famous casino district, but the technique is not about gambling. It is a general-purpose way to approximate answers in physics, finance, engineering and games.
The steps are always the same:
- Write rules that describe one random trial.
- Run the trial many times, each with fresh random numbers.
- Count the trials where the event of interest occurred.
- Divide that count by the number of trials.
A trial you can check
To see the method work, pick a case where the exact answer is known. The chance of rolling a total of 7 with two dice is 6/36 = 1/6, about 0.1667.
Imagine rolling two virtual dice 1,000 times. You would typically see 7 come up around 167 times, but not exactly 167. A run might give 158, another 173. Each estimate is a little different, and the variation is itself informative: it shows how much to trust a single run.
This check is worth doing with any simulation you build. If it cannot reproduce a known answer, it cannot be trusted on an unknown one.
A case where exact maths is awkward
Suppose a game shuffles a deck, deals 7 cards, and rewards some complicated combination of suits and ranks that depends on the order and the replacements allowed afterwards. Writing a formula could take pages and be easy to get wrong. A simulation can shuffle, deal, apply the rules mechanically and tally the result, a few lines of code repeated a million times.
Another well-known example: the chance that a shuffled deck leaves no card in its starting position. Exact methods exist (it relates to derangements), and the answer is close to 1/e, about 0.368. A simulation of a few thousand shuffles gets near that figure without any of the theory, and it is a nice cross-check.
How accurate is the estimate
The estimate is a frequency, and it wobbles from run to run. A standard rule of thumb for the size of that wobble, called the standard error, is:
standard error ≈ √( p × (1 − p) / n )
where p is the true probability and n is the number of trials. The worst case is p = 0.5, which gives √(0.25 / n) = 0.5 / √n.
Applying it for p = 0.5:
| Trials (n) | Standard error | Rough 95% margin (about 2 standard errors) |
|---|---|---|
| 100 | 0.05 | ±10 percentage points |
| 10,000 | 0.005 | ±1 percentage point |
| 1,000,000 | 0.0005 | ±0.1 percentage point |
Two practical consequences follow.
- Quadrupling the number of trials only halves the error. Going from 10,000 to 40,000 trials takes the margin from about ±1 point to about ±0.5.
- Rare events need many more trials. If the true probability is 1 in 1,000, then 1,000 trials will on average see just one success, and the estimate could easily be 0 or 3 in a given run. The relative uncertainty is large. Estimating tiny chances reliably can require millions of runs.
These margins are approximate guides based on a standard formula. They describe typical behaviour, not a guarantee for any individual run. The law of large numbers is why accuracy improves with more trials, and the topic of choosing a sensible number of trials is a subject of its own under number of trials.
Where simulations go wrong
- Bugs. If the rules in the code do not match the real rules, the estimate answers a different question. Test against cases with known answers.
- Poor randomness. Computers use pseudo-random generators, which are generally good enough for these purposes but can misbehave if used carelessly, for instance by reseeding with the same value every trial.
- Biased shuffles. An incorrect shuffling routine can quietly favour certain orders. The Fisher-Yates shuffle is the standard correct method.
- Too few trials. An answer from 50 runs is a hint, not a result.
- Overinterpreting. A simulation estimates a probability under assumed rules. It cannot tell you whether those rules match a game you cannot see inside.
Doing it without programming
You do not need a programming language to try the idea. A spreadsheet can generate random numbers and count outcomes, and physical simulation also counts: shuffling a real deck and dealing 100 times is Monte Carlo by hand. The practical how-to belongs to the guides on probability simulation, Python dice simulation and spreadsheet simulation.
What simulation can and cannot tell you
A simulation can show what a game’s mathematics implies about frequencies. It can confirm that a casino game has a negative expected value for the player, with the average result per bet drifting toward a loss as the number of simulated bets grows. It cannot change that outcome or find a loophole in a fair-random game; random numbers do not remember. It can also illustrate how wide short-run swings are, which is a good reminder that single sessions are uncertain.
If gambling is affecting you or someone you know, local support services are available. Simulation is a learning tool, not a way to find an advantage.