Simulating Probability with Simple Code

What a simulation does

A probability simulation replaces a calculation with an experiment. Instead of working out a chance with algebra, you describe the random process to a computer, run it many times, and count how often the outcome you care about appears. The share of runs that succeed is your estimate.

This is useful for two reasons. It lets you tackle questions that are awkward to solve by hand, and it gives you an independent check on answers you did solve by hand. If your algebra says 52% and a simulation of a million runs says 40%, one of them has a mistake in it, and finding which is often instructive.

The idea behind this is formalised in Monte Carlo simulation, but you do not need any of the formal machinery to start. A loop, a random number function and a counter are enough.

The basic recipe

Almost every simulation follows the same five steps:

1. State the question precisely, including what counts as a success.
2. Write code that performs one run of the random process.
3. Repeat it many times, counting successes.
4. Divide successes by runs to get an estimate.
5. Compare the estimate with an exact answer or a sensible expectation.

The second step is where most of the thinking happens. You have to decide exactly what is random, what is fixed, and in what order things occur. That discipline is a benefit in itself.

A worked example: at least one six in four rolls

Take a question with a known answer. What is the chance of rolling at least one six in four rolls of a fair die? The complement rule gives the exact value: the chance of no six on one roll is 5/6, so the chance of no six in four rolls is (5/6)^4 = 625/1296, and the chance of at least one six is 1 - 625/1296 = 671/1296, which is about 0.518.

A simulation of the same question looks like this in Python:

import random

def one_run():
    for _ in range(4):
        if random.randint(1, 6) == 6:
            return True
    return False

runs = 100_000
successes = sum(one_run() for _ in range(runs))
print(successes / runs)

Each run rolls up to four dice and reports whether a six appeared. The printed number will typically land close to 0.518, but not exactly on it, and it will differ a little each time you run the program. That wobble is normal and is the main thing to understand about simulations.

Why estimates are never exact

A simulation gives an estimate with random error. Run it twice and you get two slightly different answers. The error generally shrinks as the number of runs grows, but slowly: to cut the typical error to a tenth, you need roughly a hundred times as many runs. This is a consequence of the law of large numbers combined with how sampling error behaves, and it means a simulation can tell you a chance is “about 52%” far more easily than it can tell you whether it is 51.8% or 51.9%.

So report estimates with sensible rounding, and treat the last digit with suspicion. If two options differ by less than the simulation’s noise, the simulation has not told you which is better.

Using simulations to check hand calculations

A simulation is most valuable when it disagrees with you. A few habits make that useful:

• Start with a case you can solve exactly. Reproduce a known result first, so you trust the code before using it on something new.
• Change one thing at a time. If you alter the rules and the result moves, you learn what the rule contributes.
• Run it several times. If the answers scatter more than you expected, increase the runs or check for a bug.
• Look at extreme cases. Set a probability to 0 or 1 and confirm the code gives the obvious answer.

Many worked probability examples are easier to trust once a simulation has reproduced them. Classic puzzles are a good testing ground, because the correct answer is known and the intuitive answer is often wrong.

What simulations cannot do

A simulation is only as good as the model inside it. If your code assumes each draw is independent when the real process removes items as they are drawn, the output will be precise and wrong. Cards dealt from a deck are the standard case: drawing without replacement makes later draws depend on earlier ones, and the code has to reflect that.

Other limits are worth knowing:

• A simulation estimates; it does not prove. A million agreeing runs are strong evidence, not a mathematical certainty.
• Very rare events need a very large number of runs before you see any at all, so simulating a one-in-millions chance can be slow or misleading.
• The random numbers themselves come from a deterministic algorithm, which is fine for estimating chances but is the reason a poorly built generator or shuffle can bias results.

Simulating games without drawing the wrong conclusion

Simulations are a natural fit for dice, cards, coins and loot tables. They are good at showing that casino games carry a house edge, since the average result over many plays drifts toward a negative figure. They are not a way to find a method that beats the game. A simulation of a betting pattern shows the pattern’s behaviour under the assumed rules, and since each outcome is independent of the last, past results do not change future odds. Any apparent success in a short simulated run is variance, not a discovery. Gambling can be harmful, and anyone who finds it hard to stop can contact a local support service.

Where to go next

Once the basic loop feels comfortable, the natural next steps are to simulate specific things: a puzzle with a surprising answer, a set of dice, a shuffled deck, a running total of coin tosses, or the drop chances in a game. Each teaches a different habit. Dice teach you to compare against exact frequencies, shuffles teach you that a plausible-looking algorithm can be subtly wrong, and long runs teach you how much randomness varies between samples.

A spreadsheet can do a surprising amount of this without any programming, and plotting your results as a histogram turns a column of numbers into a shape you can read. Start small, check against a known answer, and be honest about how much noise the estimate carries.