Problem. Three doors: one hides a car, two hide goats. You pick a door. The host — who knows where the car is — opens one of the other two doors, always revealing a goat. You may switch. Should you?

The answer

Yes. Switching wins with probability ; staying wins with probability .

Why

Your initial pick is right with probability and wrong with probability . The host’s action gives you no information about your own door — he can always open a goat door regardless.

  • If you initially picked the car (), switching loses.
  • If you initially picked a goat (), the host is forced to reveal the other goat, so the remaining door has the car — switching wins.

So switching wins exactly when your first pick was wrong: probability .

The clearest intuition: 100 doors

Pick 1 of 100 doors. The host opens 98 goat doors, leaving yours and one other. Your door is still the you originally chose; the other holds the remaining .

The host’s knowledge has concentrated all the probability mass onto that single door.

The assumption that does all the work

The host must know and must always open a goat door

If the host opens a door at random and it happens to reveal a goat, the probabilities become / and switching gains nothing. If the host only offers a switch when you picked the car, switching is a disaster.

The puzzle is famous less for the answer than for how much it depends on an unstated assumption about the host’s protocol.

Host behaviour
Always opens a goat door (standard)
Opens a random door; it happened to be a goat
Offers a switch only when you picked the car
Offers a switch only when you picked a goat
Opens a goat, but prefers the lower-numbered door when free or depending on which he opened

Bayes’ theorem, formally

Let be “the car is behind door ”, and suppose you pick door 1 and the host opens door 3.

The asymmetry is entirely in the likelihoods: the host had a free choice when the car was behind your door, and no choice otherwise.

Simulation

When intuition and algebra disagree, simulate:

int wins = 0;
for (int t = 0; t < 1000000; t++) {
    int car = rng() % 3, pick = rng() % 3;
    int open;                                       // host opens a goat, not the pick
    do { open = rng() % 3; } while (open == car || open == pick);
    int other = 3 - pick - open;
    if (other == car) wins++;                       // switching
}
// wins / 1e6 -> 0.667

Ten lines, and it settles the argument. Simulating a probability puzzle before trusting an argument is a good habit generally — see stress testing.

PuzzleTwist
Monty Hallthe host’s knowledge changes the posterior
Boy or girl paradox”at least one boy” gives ; “the older is a boy” gives
Bertrand’s boxthree boxes of coins; the answer is , not
Sleeping Beautythe reference class is genuinely ambiguous
Two envelopesthe naive switching argument is flawed
Base rate fallacya rare disease with an accurate test still yields mostly false positives
Prosecutor’s fallacy

The boy-or-girl pair is the sharpest illustration of the same lesson as Monty Hall: how the information was obtained changes the conditioning, even when the stated fact is identical.

Why it is worth knowing

Monty Hall is the standard warning that conditional probability depends on the process that generated the information, not just on the information itself. In algorithmic terms: when a problem describes an observation, read carefully how the observation was produced — random sampling and adversarial (or informed) selection give different posteriors, and the difference is often the whole problem.

See also: Probability · Expected Value · Randomized Algorithms