Worked examples — Precision-recall tradeoff and curves
This is a Deep Dive drill sheet for the parent topic on the precision-recall tradeoff. The parent showed you what precision and recall are and why they oppose each other. Here we do something different: we walk into every corner of the problem space and work each one out by hand — including the weird, degenerate, "wait, what does that even mean?" cases that break naive formulas.
Before we start, two symbols we will lean on constantly. If either feels shaky, re-read the confusion-matrix note.
Notice precision never touches TN and recall never touches TN either. That single fact is the seed of half the surprises below.
The scenario matrix
Every precision-recall problem you will ever meet is one of these cells. Each worked example below is tagged with the cell(s) it covers.
| # | Cell class | What makes it tricky | Covered by |
|---|---|---|---|
| A | Ordinary threshold sweep | move , recompute both metrics | Ex 1 |
| B | Threshold at extremes | (flag everything), (flag nothing) | Ex 2 |
| C | Zero-denominator / degenerate | (precision is ); no positives exist | Ex 3 |
| D | Severe class imbalance | huge TN hides a terrible precision | Ex 4 |
| E | Baseline / lift | is a number actually good vs. random? | Ex 5 |
| F | AUC-PR by hand | trapezoid integration over the curve | Ex 6 |
| G | Real-world word problem | translate a story into the four counts | Ex 7 |
| H | Exam twist: work backwards | given precision & recall, recover the counts | Ex 8 |
| I | Comparing two models on the same point | same recall, tie-break on precision | Ex 9 |
Example 1 — Cell A: an ordinary threshold sweep
Forecast: a high threshold like 0.75 keeps only the most confident flags. Guess: precision high, recall low.
- Apply the rule "flag positive if score ." At the flagged set is . Why this step? The threshold is the classifier here — it's the single knob that turns scores into yes/no decisions (see decision thresholds).
- Sort each flagged email into a bucket. e1 = spam ✔ (TP), e2 = spam ✔ (TP). So , . Why this step? Precision and recall are built purely from these buckets — nothing else matters.
- Count the misses. True-spam emails not flagged: e4, e6 → . Why this step? Recall's denominator needs all real positives, flagged or not.
- Plug in. , . Why this step? We substitute the counts from steps 2–3 into the two definitions — this is the moment the raw buckets turn into the two numbers we actually report. We do both at once because they share the same , so a single count-up feeds both.
Verify: = total true spam ✔. Precision means zero false alarms — consistent with . Forecast confirmed: high precision, half recall.
Example 2 — Cell B: the two extreme thresholds
Forecast: at you flag everything → you catch all spam (recall = 1) but drown in ham. At you flag nothing.
- : flag every email. (all spam), (all ham), . Why this step? is the "shout at everyone" limit — the far-right end of every PR curve.
- Compute. , . Why this step? Recall is always 1 here — you can never miss a positive if you flag all. Precision collapses to the positive fraction . Remember that number; it's the baseline of Cell E.
- : flag nothing. , , . Why this step? This is the "never shout" limit — the far-left end of the curve.
- Compute recall. . Precision is — undefined (). We handle that in Example 3. Why this step? We substitute into recall to show that flagging nothing gives zero recall (every positive is a miss), and we deliberately try precision too so the crash surfaces here rather than surprising us later — it motivates Example 3.
Verify: at is = total emails ✔ (we flagged all). The recall values and bracket the whole curve — every other threshold lives between them. ✔
Example 3 — Cell C: the degenerate and the empty-positive case
Forecast: both are . Math says "undefined"; software has to choose a convention. Guess: they choose whatever keeps curves sane.
- (a) Write the fraction. . Why this step? You must see the zero denominator to know a raw formula will crash.
- Resolve it by convention. The standard (scikit-learn) rule: precision when nothing is flagged. Rationale: "you made no correct positive calls, so your positive-call quality is 0." Why this step? Without a convention the PR curve would have a hole at recall ; the convention plugs it so the curve starts cleanly at by extrapolation or by definition depending on library — always check yours.
- (b) Write recall's fraction. . Why this step? No positives exist to catch, so "fraction caught" is genuinely meaningless.
- Resolve it. Convention: recall (or reported as undefined and the sample excluded). Practically, never evaluate recall on a set with zero positives — the metric can't be defined.
Verify: sanity — if you cannot be penalised for a miss (no positives to miss), recall carries no information, so "undefined / 0" is the honest answer. The key lesson, not a number: always check whether a denominator can be zero before trusting a metric. ✔
Example 4 — Cell D: severe imbalance hides a terrible precision
Forecast: with 9 950 negatives, false alarms barely dent the ROC's FPR, but precision — which ignores those negatives — should expose the problem.
- Fill the four counts. Flagged 250, of which ⇒ . Real cancer , caught ⇒ . Then . Why this step? Every metric below is just a ratio of these four numbers.
- Precision. . Why this step? Precision only sees and — the 9 740 correct passes are invisible to it.
- Recall. . Why this step? We caught 80% of cancers — sounds great in isolation.
- ROC FPR for contrast. . Why this step? The huge in the denominator crushes FPR to ~2%, making ROC look excellent while precision is a dismal 16%.
Verify: counts sum to the total: ✔. The clash — recall 0.80 & FPR 0.02 (rosy) vs. precision 0.16 (grim) — is exactly why imbalanced problems demand PR curves, not ROC.
Example 5 — Cell E: baseline and lift
Forecast: the PR baseline is not 0.5; it's the positive fraction, which is tiny here. So 0.15 might actually be strong.
- Compute the positive fraction. . Why this step? A random classifier's expected precision equals the prevalence of positives — no matter the threshold — so is the baseline AUC-PR.
- Compare against it. Model vs. baseline . Why this step? 0.15 looks small only against the wrong yardstick (0.5). Against 0.005 it's enormous.
- Lift = model / baseline. . Why this step? Lift converts "how good" into "how many times better than guessing" — the honest headline number.
Verify: baseline via a second route — a random classifier flagging fraction of items catches positives and negatives, so precision , independent of ✔. The colleague was wrong: 30× lift is excellent. Compare baseline logic with cost-sensitive learning where the "good enough" bar is set by dollars, not lift.
Example 6 — Cell F: AUC-PR by hand (trapezoid rule)
Forecast: we're integrating precision over recall. Points slope downward, so the area should land somewhere between 0.4 and 1.0 — probably mid-0.6s.

Reading the figure: the four black dots are our known PR points P1–P4, joined by the bold black curve. The dashed black verticals slice the region under the curve into three strips; each strip is a trapezoid (its two vertical sides are the precisions and , its width is ). The red shaded region is the AUC-PR we are about to compute — steps 3–5 below are literally adding up those three red strips, and step 6 gives the total the red label announces.
- Sort by increasing recall. Already sorted (0.00 < 0.40 < 0.70 < 1.00). Why this step? The trapezoid rule marches left→right along the x-axis; out-of-order points would give nonsense (even negative) areas.
- Why trapezoids at all? We only know precision at a few recall values, so we connect adjacent points with straight lines and sum the strip areas. Each strip is a trapezoid — two parallel vertical sides and width .
- Strip P1→P2. width , avg height → area . Why this step? A trapezoid's area = (average of its two parallel sides) × width; here the sides are the two precisions and the width is the recall gap — this is the leftmost red strip in the figure.
- Strip P2→P3. width , avg height → area . Why this step? Same trapezoid formula on the next adjacent pair; we move rightward one strip at a time so no area is double-counted or skipped.
- Strip P3→P4. width , avg height → area . Why this step? The final red strip; because precision has dropped to 0.40 here, this strip contributes the least — you can see it is the shortest region in the figure.
- Sum. . Why this step? The whole area under a piecewise-linear curve is exactly the sum of its strips, so adding the three trapezoids gives the total AUC-PR — the value printed in red on the figure.
Verify: widths add to the full recall span ✔. The result sits inside as forecast, and since precision starts high and only dips late, a value in the mid-0.7s is sensible. ✔ This same number feeds into F1 / Fβ discussions when you pick an operating point.
Example 7 — Cell G: real-world word problem
Forecast: 18 of 32 alerts were real → precision a bit above half. 18 of 20 floods warned → recall high.
- Extract the counts from the story. "32 alerts, 18 real" ⇒ , . "20 real floods, 18 warned" ⇒ . Why this step? Word problems are just the four counts in disguise — always translate first.
- Precision. . Why this step? Precision answers the resident's question "when the siren sounds, how often is it real?" — here 56%, so nearly half the sirens are false alarms.
- Recall. . Why this step? Recall answers "of floods that actually happened, how many were warned?" — 90%, so the city misses 2 in 20.
Verify: = total alerts ✔; = total floods ✔. Trade-off in words: to push recall to 100% (never miss a flood) the city would lower the alert bar and precision would fall further — the classic tension from the parent note.
Example 8 — Cell H: work backwards (exam twist)
Forecast: both formulas share ; if we know we can algebraically invert each ratio.
- Invert precision for . . Why this step? Precision is the only equation containing , so it's our lever for it.
- Invert recall for . . Why this step? Likewise recall is the only equation containing .
- Total real positives. . Why this step? The denominator of recall is the count of all positives in the data.
Verify: plug back. Precision ✔. Recall ✔. Both reproduced from the recovered counts, so , and 50 true positives are all correct — the example closes cleanly.
Example 9 — Cell I: tie-break two models at the same recall
Forecast: same recall means same catches; the winner is whoever raised fewer false alarms → higher precision. Fewer total flags (B) should win.
- Recover each model's . . Model A: . Model B: . Why this step? Total positive predictions ; subtract the known to isolate false alarms.
- Precision A. . Why this step? We substitute Model A's counts into the precision definition to price its false alarms.
- Precision B. . Why this step? At equal recall, precision is the deciding metric — it measures the false-alarm cost of getting the same catches.
Verify: both recalls equal ✔ (confirming a fair comparison). Model B wins, precision 0.80 vs 0.50 — it achieves the identical catch rate with far less collateral. This is exactly the tie-break a PR curve visualises: at a fixed x (recall), the higher curve (precision) is the better model.
Recall Self-check
At (flag everything), what is recall always equal to? ::: Exactly — you cannot miss a positive if you flag every example. Why can precision be a undefined value? ::: When the model flags nothing, , so the fraction has a zero denominator; libraries define it (usually as 0) by convention. What is the no-skill baseline for AUC-PR? ::: The positive-class fraction (prevalence), not 0.5. Two models tie on recall — what breaks the tie? ::: Precision: whoever raised fewer false alarms for the same catches.