Topics

Randomness and what it looks like

Covers AS91585

What randomness means

Randomness is named as a method in its own right in the explanatory notes, and questions on it ask for explanation rather than calculation.
An outcome is random if:
- the individual outcome is unpredictable, but
- the long-run pattern is predictable.
Both halves matter. A process that is unpredictable and has no stable long-run pattern is not something probability can describe at all.

The two properties, applied

Individually unpredictable. You cannot know whether the next customer will buy. Nothing about the previous customers tells you.
Predictable in aggregate. Over 10 000 customers, the proportion who buy will be close to a stable value.
This is why insurers, airlines and supermarkets can plan precisely while knowing nothing about any individual.

What random variation actually looks like

Real randomness contains clusters and runs. In 40 coin tosses, a run of five heads is common — it occurs more often than not.
People asked to invent a random sequence produce something too regular: they alternate too often and avoid long runs, because runs feel non-random.
Consequences you should be able to explain:
- A cluster of events — three house fires in one street in a month, four rainy Saturdays in a row — is not evidence of a cause. Clusters are what randomness looks like.
- Conversely, a sequence that looks too even is evidence that something is not random.

The gambler's fallacy

The gambler's fallacy is believing that a run of one outcome makes the other "due".
After five heads, the probability of a head on the sixth toss is still 0.5. The coin has no memory.
Why it feels wrong: the law of large numbers says the proportion settles down over the long run — but it does so by dilution, not by compensation. Later tosses do not correct earlier ones; there are simply so many later tosses that the early imbalance stops mattering.
The reverse fallacy also appears: assuming a run means the process is "hot" and will continue.

Independence and randomness are not the same

Random describes a single outcome being unpredictable with a stable long-run pattern.
Independent describes a relationship between two events — one occurring does not change the probability of the other.
Random events can be dependent. Drawing cards without replacement is random at every step, and each draw changes the probabilities for the next.

Generating randomness

A process is random only if the mechanism makes it so:
- Drawing numbered balls from a well-mixed drum.
- Assigning each unit a random number from a calculator or spreadsheet and sorting.
Common failures that look random and are not:
- Choosing "at random" by hand — humans avoid adjacent numbers, favour middle numbers, and avoid repeats.
- Taking whoever is available — convenience, not randomness.
- Using a pattern such as every 10th — systematic, and non-random if the list has structure.

Simulation

A simulation models a random situation using a random mechanism, runs it many times, and uses the resulting relative frequency as an experimental estimate.
Steps you may be asked to describe:
- Define the model and the assumption it makes.
- Assign random digits or outcomes to represent each event in the correct proportion.
- Run many trials.
- Count and divide to get the estimate.
A simulation's answer is an experimental estimate, so it varies between runs and improves with more trials.

Worked ExampleRecognising randomness and its consequences

A hardware chain's website reports a fault on some days and not others. Over the last 30 days the faults occurred on days:

$3,\; 4,\; 5,\; 11,\; 17,\; 18,\; 25,\; 26,\; 27,\; 28$

The IT manager says: "Faults are clustered — days 3–5 and days 25–28 both had runs. Something must be causing them in groups, so this is not random. Also, we've had four days in a row of faults, so we're due a quiet spell."

(a) Calculate the experimental estimate of the probability that a given day has a fault. (b) Comment on the manager's claim that the clustering shows the faults are not random. (c) Comment on the "due a quiet spell" claim. (d) What evidence would genuinely show the faults are not occurring at random?

(a) Experimental estimate

There were 10 fault days out of 30:

$\frac{10}{30} = 0.333...$

(b) Does clustering disprove randomness?

Step 1 — State what random data look like. Random events cluster. If each day independently has a fault with probability $\tfrac{1}{3}$ , then runs of consecutive fault days are not merely possible but expected. The probability of a fault on any three specific consecutive days is $\left(\tfrac{1}{3}\right)^3 \approx 0.037$ — and across 30 days there are 28 places such a run could start, so seeing at least one run of three is unsurprising.

Step 2 — Address the psychology. People expect randomness to look evenly spread, so genuinely random data appear "clustered" to the eye. An evenly spaced pattern — faults on days 3, 6, 9, 12, 15… — would be far stronger evidence against randomness than what was observed.

Step 3 — Conclude.

Note this does not prove the faults are random — only that this particular observation gives no reason to think otherwise.

(c) The "due a quiet spell" claim

Step 1 — Name the error. This is the gambler's fallacy.

Step 2 — Explain why it is wrong. If days are independent, the probability of a fault tomorrow is $\tfrac{1}{3}$ regardless of what happened on the previous four days. The system has no mechanism for tracking its recent history and compensating.

Step 3 — Address the intuition behind it.

Step 4 — Note the assumption.

(d) What would show the faults are not random?

Not a visual impression of clustering, but a comparison against what randomness predicts:

Compare the observed runs with the expected distribution of runs. Simulate 30 days with $p = \tfrac{1}{3}$ independently, thousands of times, and record the longest run each time. If runs of four occur in most simulations, the observed data are unremarkable; if they occur in very few, the independence assumption is in doubt.
Look for an association with an external variable. Do faults coincide with high traffic days, with deployment dates, with month-end batch processing, or with a particular weekday? A relationship with something identifiable is real evidence of a cause, whereas clustering alone is not.
Check for dependence between consecutive days. Estimate $P(\text{fault today} \mid \text{fault yesterday})$ and compare it with $P(\text{fault today})$ . If the conditional probability is substantially higher, days are not independent — which is very plausible here, since an unresolved fault can persist across days, and that mechanism would produce genuine clustering.

The contextual point. The manager's instinct that something causes faults in groups may well be right — but for a reason he has not stated. A fault that takes two days to fix produces a run of two automatically, and that is dependence between days rather than a hidden external cause. Distinguishing "one fault lasting four days" from "four separate faults" would be the first thing to establish.