Probability Rules

By the end of this lesson, you should be able to: use the addition rule without double counting, check whether two events are independent instead of assuming it, turn any "at least one" question into a complement, and count the ways something can happen.

Events and the basic rules

Probability starts with a sample space, the set of everything that could happen, and events, the parts of it you care about. For one user's visit to an app, the sample space is every possible visit. "Used search" is an event. So is "made a purchase".

The probability of an event, written $P(A)$, is a number from 0 to 1. Three rules cover most of what you'll need.

Everything adds to 1. If a set of outcomes covers every possibility, with no overlaps, their probabilities add up to exactly 1. It sounds trivial, but it's a useful check: if your categories are meant to cover everything and they don't add to 1, a case is missing or counted twice.

The complement. The chance that $A$ doesn't happen is

$P(\text{not } A) = 1 - P(A)$

The addition rule. The chance that $A$ or $B$ happens, or both, is

$P(A \cup B) = P(A) + P(B) - P(A \cap B)$

The last term is the overlap. Without it, everyone who did both gets counted twice.

Say, for illustration, that 30% of an app's users used search last month, 20% used the saved-items list, and 8% used both. The share who used at least one of the two is 30% + 20% − 8% = 42%, not 50%. A report that adds the two shares straight overstates the reach of the two features by 8 points.

Independence

Two events are independent if knowing that one happened tells you nothing about the other. Formally, $P(A \mid B) = P(A)$: the chance of $A$ given that $B$ happened is the same as the chance of $A$ overall. Conditional probability covers the notation in full.

When events are independent, and only then, the chance of both happening is the product:

$P(A \cap B) = P(A) \times P(B)$

That "only then" is where people get hurt. Independence is a claim about the world, and it has to be checked.

A British court case shows what happens when it isn't. Sally Clark was convicted of murdering her first two babies, who had both died suddenly in infancy. A medical expert witness estimated that for a family like hers, the chance of one sudden infant death was about 1 in 8,500. He squared it to get the chance of two: 1 in 73 million.

The Royal Statistical Society wrote to the Lord Chancellor to object.1 Squaring the figure, its president wrote, "would only be valid if SIDS cases arose independently within families", an assumption that would need to be justified, and "there are very strong reasons for supposing that the assumption is false". Brothers share genes and a home. If something in a family raises the risk of one sudden death, it raises the risk of a second, and the chance of two is much higher than the product.

The same thing turns up in engineering data. Google studied memory errors across its server fleet over two and a half years.2 If a memory module had an error one month, the chance of an error the next month went up by a factor of 35 to more than 200, compared with a module that had no error the month before. Errors cluster in faulty hardware. Treat each month as independent and you badly underestimate how often a module that has failed once will fail again.

Whenever you multiply probabilities, ask what could make the events depend on each other. Services that share a data centre, users from the same company, and days for the same user all share causes.

One more trap: independent isn't the same as mutually exclusive. Mutually exclusive events can't both happen, so $P(A \cap B) = 0$. Knowing one happened tells you the other didn't, which makes them strongly dependent.

"At least one": compute "none" and subtract

Say a checkout bug fires on 1 in 10,000 orders, and a store takes about 25,000 orders a week. What's the chance it hits at least one?

Working it out directly means adding the chance of exactly one hit, exactly two, and so on up to 25,000. The complement is much shorter. The opposite of "at least one" is "none", and if orders are independent, "none" is a single multiplication:

$P(\text{none}) = (1 - p)^n \qquad P(\text{at least one}) = 1 - (1 - p)^n$

Here that's $1 - 0.9999^{25{,}000}$, about 92%. The bug that "only" affects 1 in 10,000 orders almost certainly hit somebody this week.

The default shows the bug: 1 in 10,000, about 25,000 tries, a 91.9% chance of at least one hit. Move the chance to 1 in 100,000 and it drops to 22%. Move it to 1 in 1,000 and it's certain long before the week is out. A rare event isn't rare at volume.

Google's memory study shows the same arithmetic at fleet scale. More than 8% of memory modules had at least one error in a year. A machine holds several modules, and about a third of all machines had at least one.2

Notice the expected count in the explorer too. It's just $n \times p$, here about 2.5 hits. The expected count and the chance of at least one answer different questions. Mixing them up is how "we expect 2.5 incidents" turns into "there's a 250% chance of an incident".

Whenever a question says "at least one", compute "none" and subtract. The same formula is behind the multiple testing problem, with $p = 0.05$ and $n$ the number of metrics on a scorecard.

Counting

Some probability questions are counting questions. If one choice has $a$ options and a second, separate choice has $b$, there are $a \times b$ combined outcomes. The rest follows from that.

Permutations count arrangements where order matters:

$P(n, k) = \frac{n!}{(n-k)!}$

Combinations count selections where order doesn't matter:

$C(n, k) = \binom{n}{k} = \frac{n!}{k!\,(n-k)!}$

Ask whether swapping two picks gives a different outcome. If it does, use permutations.

The last row matters most in practice. A dashboard with 40 metrics holds 780 pairs. Test every pair for a relationship at the 5% level and about 39 will look significant by chance alone.

The birthday problem puts counting and the complement together. In a room of 23 people, what's the chance at least two share a birthday? Compute "none share" instead. The first person can have any birthday, the second must avoid one day, the third must avoid two, and so on:

$P(\text{no shared birthday}) = \frac{365}{365} \times \frac{364}{365} \times \cdots \times \frac{343}{365} \approx 0.493$

So the chance of a shared birthday is about 50.7%. Most people guess far lower, because they think of matches with their own birthday. With 23 people there are $\binom{23}{2} = 253$ pairs, and each pair is a chance for a match.

Takeaways

• Subtract the overlap. $P(A \cup B) = P(A) + P(B) - P(A \cap B)$. Adding 30% and 20% gives 42% when 8% did both.
• Multiply only when events are independent. Squaring 1 in 8,500 to get 1 in 73 million assumed that two deaths in one family were unrelated, which the Royal Statistical Society said there were strong reasons to doubt.
• Shared causes break independence. At Google, a memory error one month made an error the next month 35 to 200 times more likely.
• "At least one" means compute "none". $1 - (1-p)^n$: a 1-in-10,000 bug has a 92% chance of hitting 25,000 orders at least once.
• Expected count and probability are different questions. 2.5 expected hits, a 92% chance of at least one.
• Count pairs before you go looking for patterns. 40 metrics make 780 pairs, and 23 people make 253.

Quick check

Practice

Take it further

• Meta: a 60-metric scorecard is the counting argument in this lesson applied to a real experiment readout.
• Facebook: a Feed change spreads between friends is a case where independence fails for a structural reason.
• OpenAI: a safety filter for a rare harm turns on rare events meeting volume, the same shape as the bug above.