The Prediction Leaderboard

Chapter 7 ranked the twenty clubs. This chapter ranks the four predictors — the user, the BBC expert, the BBC's AI and the week's guests — by how many points their predictions have earned across the season. It is a much smaller sorted set, four members, but it is where the shortcuts taken in Chapter 6 get tested, and one of them turns out to be wrong.

What Gets Ranked

Chapter 6 left two hashes behind. totals holds each source's season points (user, expert, ai, guest_avg_x100), and each fixture's own points sit in fixture:{id}:points. The leaderboard also shows how many correct scores (40-point predictions) and correct results (10-point predictions) each source has made, and those counts don't exist yet. Guests get no counts: their figure is an average of several people's points, so "how many exact scores" has no meaning for it, matching the relational siblings.

Mixed Units: The Problem Hiding in Chapter 6

The obvious leaderboard is ZADD leaderboard <total> <source> using the numbers already in totals. But Chapter 6 stored three of them in whole points and the guest figure in hundredths of a point, to keep HINCRBY exact.

The fix is a single common unit. Everything is ranked in hundredths of a point: the guest value as it is, and the other three multiplied by 100. Fixed, the same data ranks expert 34000, guest 32665, ai 32000, user 18000.

The Score: Points, Then Correct Scores

Ties are decided by who has more correct scores. As in Chapter 7, two numbers become one, most important first, and the result is negated so that ZRANGE lists first place down:

A season has at most 380 fixtures, so the correct-score count can't reach 1,000 and can't carry into the points. The members are just user, expert, ai and guest. Anything still tied after both keys falls back to member-name order, ascending — the same arbitrary-but-deterministic fallback as Chapter 7.

One Script Keeps Everything Consistent

Chapter 6's script already did the hard part — new-minus-old, so a repeated or corrected result never double-counts. This version extends it to also maintain the correct-score and correct-result counts (with the same deltas), rescore the leaderboard member, and announce a change:

The keys are the fixture's points hash, totals, the leaderboard sorted set and a records hash (fields like user:scores). ARGV[1] is the notification channel; the rest are source, points pairs, exactly as Chapter 6 built them. A new season seeds each of the four members at score 0. The route passes the same arguments as before plus the channel name — nothing else in the scoring route changes.

Verified Against an Independent Calculation

Same method as Chapter 7. Sixty fixtures, each with predictions from the user, expert and AI plus one to three guests, all random; a random result for every fixture; then 30 random corrections. The totals, counts and order were then recomputed from scratch in plain Python from the final results:

Note the guest row's correct-score count is never used, which is why its composite is just total * 1000.

Real-Time Updates With Pub/Sub

The script ends with PUBLISH, and only when something actually changed. A browser or another process that subscribes to that channel gets a nudge the moment a result is scored. Verified:

Repeating an identical result stays silent, which comes free from the "only when changed" test. The last line is Pub/Sub's real limitation: it keeps no history. A message is delivered to whoever is subscribed right then and forgotten. So the message can't carry the data — it is only a signal to read again. A client should read the leaderboard when it connects, then subscribe, and re-read on each nudge. (Subscribing first and then reading avoids missing a change in the gap; a re-read is cheap with four members.)

Revisiting Chapter 6: The Guest Average Has a Rounding Error

Chapter 6 rounds each fixture's guest average to hundredths and sums those. That round-then-sum is not the same as summing exactly, and the difference accumulates with the number of fixtures. Averaging three guests who scored 10, 40 and 0 gives 16.6667, stored as 1667 — 0.0033 too high, once per such fixture. The worst case is half a hundredth per fixture: 0.005 × 380 = 1.9 points over a season. What actually happens was measured by simulating 2,000 seasons of 380 fixtures with one to four random guests:

There is an exact alternative. Every prediction is worth 0, 10 or 40 points, so a guest total is a multiple of 10, and 10×60 = 600 divides evenly by 1, 2, 3, 4, 5 and 6. Storing the average in sixtieths of a point makes it an exact integer for any fixture with up to six guests — checked here across 200 random cases for each guest count from one to six. Seven guests is the first count that fails (10/7 is not a whole number of sixtieths). Exercise 3 works it through.

Reading the Leaderboard

Missing fields default to zero, as in Chapter 7. The guest's counts are None, so the client renders a dash rather than a misleading zero.

Hands-On Exercises