Karger’s contraction algorithm finds one by trying not to destroy it.

The problem is the global minimum cut of an undirected graph: split the vertices into two nonempty sides while minimizing the number, or total weight, of crossing edges. There is no distinguished source or sink. This is not the same posture as an s-t max-flow computation. We are asking where the whole graph is easiest to disconnect.

The random contraction algorithm is almost suspiciously short:

while more than two supernodes remain:
    choose a remaining edge uniformly at random
    contract its endpoints
    delete self-loops, keep parallel edges
return the cut between the two final supernodes

The trick is not that one trial is reliable. It is not. The trick is that a particular minimum cut has a quantifiable chance to survive, and independent repetition is cheap to reason about.

The Event Is Survival

Fix one minimum cut \(C\) with \(\lambda\) crossing edges.

If the algorithm never contracts an edge of \(C\), then the two sides of \(C\) are never merged together. Other contractions can collapse vertices inside each side, but they cannot erase the border. When only two supernodes remain, those supernodes must be exactly the two sides of the fixed cut, up to renaming.

So the success event for this fixed cut is:

no edge of C is ever selected for contraction

Karger’s proof prices that event one contraction at a time.¹ Suppose the current contracted graph has \(r\) supernodes and the original cut has survived so far. Contracting vertices only restricts the set of cuts still available, so the current graph’s min-cut is at least \(\lambda\). Therefore every supernode has degree at least \(\lambda\), and the current multigraph has at least \(r\lambda/2\) edges.

Only \(\lambda\) of those edges cross our fixed cut. Thus the probability that the next random edge kills this cut is at most:

The survival probability is at least:

That number is small. For \(n=100\) it is about 0.0202% for one named cut in one run. But it is not astronomically small, and it has no hidden dependence on the number of edges. After \(T\) independent runs, the probability of missing that same fixed cut is at most:

That is the entire shape of the algorithm: a bad one-shot gamble with a clean lower bound becomes useful when repeated.

Lab: Let The Cut Try To Survive

The lab below builds small unweighted multigraphs, computes the exact global min cut by brute force, then runs repeated random contractions against that oracle.

The default graph is two K5 cliques joined by two parallel bridge edges. Its minimum cut is unique: separate the cliques by cutting the two bridge copies. The exact oracle enumerates 511 nonempty cuts, because it fixes one vertex on the complement side to avoid counting each cut twice.

Default run:

The observed rate is much better than the proof bound on this graph. That is normal. The proof is worst-case and follows one named cut. The cycle preset is the opposite lesson: a ten-cycle has 45 canonical minimum cuts, and every contraction result is optimal, even though any one fixed cut still has only the Karger lower-bound chance.

The audit exported by the script gives the randomized experiment a deterministic receipt: 63 audit rows, backed by 365 individual invariant checks.

node - <<'NODE'
const lab = require("./assets/js/karger-mincut-lab.js");
const EXPECTED_GRAPHS = 4;
const EXPECTED_NAMED_CHECKS = 11;
const EXPECTED_GRID_CASES = 48;
const EXPECTED_ROWS = 63;
const EXPECTED_CHECKS = 365;
const EXPECTED_TOTALS = {
  graphRows: EXPECTED_GRAPHS,
  gridSummaries: EXPECTED_GRAPHS,
  gridRows: EXPECTED_GRID_CASES,
  namedChecks: EXPECTED_NAMED_CHECKS,
  passed: EXPECTED_ROWS,
  total: EXPECTED_ROWS,
  passedChecks: EXPECTED_CHECKS,
  totalChecks: EXPECTED_CHECKS
};
const EXPECTED_DEFAULT_SUMMARY = {
  bestValue: 2,
  bound: "0.022",
  exactCount: 1,
  firstSuccess: 13,
  lambda: 2,
  repetitions95: 134,
  successRate: "0.304",
  successes: 73,
  trials: 240
};
const EXPECTED_GRAPH_ROWS = [
  "bridge:10/22:lambda=2:cuts=1:trials=32:optimal=11:survivals=11:checks=47/47:passed=true",
  "cycle:10/10:lambda=2:cuts=45:trials=32:optimal=32:survivals=1:checks=37/37:passed=true",
  "islands:15/36:lambda=3:cuts=2:trials=32:optimal=4:survivals=3:checks=39/39:passed=true",
  "ladder:12/18:lambda=2:cuts=7:trials=32:optimal=20:survivals=3:checks=39/39:passed=true"
];
const EXPECTED_NAMED_ROWS = [
  "bridge-lambda:1/1:true",
  "bridge-mincut-count:1/1:true",
  "bridge-finds-mincut:1/1:true",
  "bridge-best-value:1/1:true",
  "cycle-lambda:1/1:true",
  "cycle-mincut-count:1/1:true",
  "cycle-all-trials-optimal:1/1:true",
  "default-deterministic:1/1:true",
  "default-best-is-exact:1/1:true",
  "n10-repetition-count:1/1:true",
  "grid-size:1/1:true"
];
const EXPECTED_GRID_SUMMARY_ROWS = [
  "bridge:cases=12/12:checks=48/48:success=0.175..0.308",
  "cycle:cases=12/12:checks=48/48:success=1.000..1.000",
  "islands:cases=12/12:checks=48/48:success=0.125..0.300",
  "ladder:cases=12/12:checks=48/48:success=0.550..0.650"
];
const EXPECTED_GRID_CASE_ROWS = [
  "bridge:1:40:lambda=2:best=2:successes=12:rate=0.300:bins=3:checks=4/4:passed=true",
  "bridge:1:120:lambda=2:best=2:successes=37:rate=0.308:bins=3:checks=4/4:passed=true",
  "bridge:1:240:lambda=2:best=2:successes=62:rate=0.258:bins=3:checks=4/4:passed=true",
  "bridge:17:40:lambda=2:best=2:successes=9:rate=0.225:bins=3:checks=4/4:passed=true",
  "bridge:17:120:lambda=2:best=2:successes=31:rate=0.258:bins=3:checks=4/4:passed=true",
  "bridge:17:240:lambda=2:best=2:successes=64:rate=0.267:bins=3:checks=4/4:passed=true",
  "bridge:83:40:lambda=2:best=2:successes=12:rate=0.300:bins=3:checks=4/4:passed=true",
  "bridge:83:120:lambda=2:best=2:successes=27:rate=0.225:bins=3:checks=4/4:passed=true",
  "bridge:83:240:lambda=2:best=2:successes=68:rate=0.283:bins=3:checks=4/4:passed=true",
  "bridge:211:40:lambda=2:best=2:successes=7:rate=0.175:bins=3:checks=4/4:passed=true",
  "bridge:211:120:lambda=2:best=2:successes=34:rate=0.283:bins=3:checks=4/4:passed=true",
  "bridge:211:240:lambda=2:best=2:successes=70:rate=0.292:bins=3:checks=4/4:passed=true",
  "cycle:1:40:lambda=2:best=2:successes=40:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:1:120:lambda=2:best=2:successes=120:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:1:240:lambda=2:best=2:successes=240:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:17:40:lambda=2:best=2:successes=40:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:17:120:lambda=2:best=2:successes=120:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:17:240:lambda=2:best=2:successes=240:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:83:40:lambda=2:best=2:successes=40:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:83:120:lambda=2:best=2:successes=120:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:83:240:lambda=2:best=2:successes=240:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:211:40:lambda=2:best=2:successes=40:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:211:120:lambda=2:best=2:successes=120:rate=1.000:bins=1:checks=4/4:passed=true",
  "cycle:211:240:lambda=2:best=2:successes=240:rate=1.000:bins=1:checks=4/4:passed=true",
  "islands:1:40:lambda=3:best=3:successes=7:rate=0.175:bins=3:checks=4/4:passed=true",
  "islands:1:120:lambda=3:best=3:successes=31:rate=0.258:bins=3:checks=4/4:passed=true",
  "islands:1:240:lambda=3:best=3:successes=59:rate=0.246:bins=3:checks=4/4:passed=true",
  "islands:17:40:lambda=3:best=3:successes=12:rate=0.300:bins=3:checks=4/4:passed=true",
  "islands:17:120:lambda=3:best=3:successes=25:rate=0.208:bins=3:checks=4/4:passed=true",
  "islands:17:240:lambda=3:best=3:successes=42:rate=0.175:bins=3:checks=4/4:passed=true",
  "islands:83:40:lambda=3:best=3:successes=9:rate=0.225:bins=3:checks=4/4:passed=true",
  "islands:83:120:lambda=3:best=3:successes=25:rate=0.208:bins=3:checks=4/4:passed=true",
  "islands:83:240:lambda=3:best=3:successes=45:rate=0.188:bins=3:checks=4/4:passed=true",
  "islands:211:40:lambda=3:best=3:successes=5:rate=0.125:bins=3:checks=4/4:passed=true",
  "islands:211:120:lambda=3:best=3:successes=17:rate=0.142:bins=3:checks=4/4:passed=true",
  "islands:211:240:lambda=3:best=3:successes=41:rate=0.171:bins=3:checks=4/4:passed=true",
  "ladder:1:40:lambda=2:best=2:successes=25:rate=0.625:bins=3:checks=4/4:passed=true",
  "ladder:1:120:lambda=2:best=2:successes=78:rate=0.650:bins=4:checks=4/4:passed=true",
  "ladder:1:240:lambda=2:best=2:successes=141:rate=0.588:bins=4:checks=4/4:passed=true",
  "ladder:17:40:lambda=2:best=2:successes=25:rate=0.625:bins=4:checks=4/4:passed=true",
  "ladder:17:120:lambda=2:best=2:successes=68:rate=0.567:bins=5:checks=4/4:passed=true",
  "ladder:17:240:lambda=2:best=2:successes=140:rate=0.583:bins=5:checks=4/4:passed=true",
  "ladder:83:40:lambda=2:best=2:successes=24:rate=0.600:bins=3:checks=4/4:passed=true",
  "ladder:83:120:lambda=2:best=2:successes=67:rate=0.558:bins=4:checks=4/4:passed=true",
  "ladder:83:240:lambda=2:best=2:successes=132:rate=0.550:bins=5:checks=4/4:passed=true",
  "ladder:211:40:lambda=2:best=2:successes=26:rate=0.650:bins=4:checks=4/4:passed=true",
  "ladder:211:120:lambda=2:best=2:successes=67:rate=0.558:bins=4:checks=4/4:passed=true",
  "ladder:211:240:lambda=2:best=2:successes=137:rate=0.571:bins=4:checks=4/4:passed=true"
];

function sameJson(left, right) {
  return JSON.stringify(left) === JSON.stringify(right);
}

function rowDrifts(actual, expected) {
  const count = Math.max(actual.length, expected.length);
  const drift = [];
  for (let index = 0; index < count; index += 1) {
    if (actual[index] !== expected[index]) {
      drift.push({ index, actual: actual[index], expected: expected[index] });
    }
  }
  return drift;
}

function fixed3(value) {
  return Number(value).toFixed(3);
}

const audit = lab.auditKargerMincutLab();
console.table(audit.byGraph.map((row) => ({
  graph: row.graph,
  lambda: row.lambda,
  minCuts: row.minCuts,
  trialChecks: row.trials,
  optimalTrials: row.optimalTrials,
  survivals: row.survivals,
  checks: `${row.passedChecks}/${row.totalChecks}`
})));
console.table(audit.gridSummary.map((row) => ({
  graph: row.graph,
  cases: `${row.passed}/${row.cases}`,
  checks: `${row.passedChecks}/${row.totalChecks}`,
  minSuccessRate: row.minSuccessRate.toFixed(3),
  maxSuccessRate: row.maxSuccessRate.toFixed(3)
})));
const auditShape = {
  defaultSummary: {
    bestValue: audit.defaultSummary.bestValue,
    bound: fixed3(audit.defaultSummary.bound),
    exactCount: audit.defaultSummary.exactCount,
    firstSuccess: audit.defaultSummary.firstSuccess,
    lambda: audit.defaultSummary.lambda,
    repetitions95: audit.defaultSummary.repetitions95,
    successRate: fixed3(audit.defaultSummary.successRate),
    successes: audit.defaultSummary.successes,
    trials: audit.defaultSummary.trials
  },
  graphRows: audit.byGraph.map((row) =>
    `${row.graph}:${row.nodes}/${row.edges}:lambda=${row.lambda}:` +
    `cuts=${row.minCuts}:trials=${row.trials}:optimal=${row.optimalTrials}:` +
    `survivals=${row.survivals}:checks=${row.passedChecks}/${row.totalChecks}:` +
    `passed=${row.passed}`
  ),
  gridCaseRows: audit.cases.map((row) =>
    `${row.graph}:${row.seed}:${row.trials}:lambda=${row.lambda}:` +
    `best=${row.bestValue}:successes=${row.successes}:` +
    `rate=${fixed3(row.successRate)}:bins=${row.histogramBins}:` +
    `checks=${row.passedChecks}/${row.totalChecks}:passed=${row.passed}`
  ),
  gridSummaryRows: audit.gridSummary.map((row) =>
    `${row.graph}:cases=${row.passed}/${row.cases}:` +
    `checks=${row.passedChecks}/${row.totalChecks}:` +
    `success=${fixed3(row.minSuccessRate)}..${fixed3(row.maxSuccessRate)}`
  ),
  namedRows: audit.namedChecks.map((row) =>
    `${row.name}:${row.passedChecks}/${row.totalChecks}:${row.passed}`
  ),
  totals: {
    graphRows: audit.byGraph.length,
    gridSummaries: audit.gridSummary.length,
    gridRows: audit.cases.length,
    namedChecks: audit.namedChecks.length,
    passed: audit.passed,
    total: audit.total,
    passedChecks: audit.passedChecks,
    totalChecks: audit.totalChecks
  }
};
const graphRowDrifts = rowDrifts(auditShape.graphRows, EXPECTED_GRAPH_ROWS);
const namedRowDrifts = rowDrifts(auditShape.namedRows, EXPECTED_NAMED_ROWS);
const gridSummaryDrifts = rowDrifts(
  auditShape.gridSummaryRows,
  EXPECTED_GRID_SUMMARY_ROWS
);
const gridCaseDrifts = rowDrifts(auditShape.gridCaseRows, EXPECTED_GRID_CASE_ROWS);
const shapeErrors = [
  sameJson(auditShape.defaultSummary, EXPECTED_DEFAULT_SUMMARY) ? null : "defaultSummary",
  sameJson(auditShape.totals, EXPECTED_TOTALS) ? null : "totals",
  graphRowDrifts.length ? "graphRows" : null,
  namedRowDrifts.length ? "namedRows" : null,
  gridSummaryDrifts.length ? "gridSummaryRows" : null,
  gridCaseDrifts.length ? "gridCaseRows" : null
].filter(Boolean);
if (shapeErrors.length) {
  throw new Error(
    `Karger audit shape drifted in ${shapeErrors.join(", ")}:\n` +
    JSON.stringify({
      auditShape,
      expected: {
        defaultSummary: EXPECTED_DEFAULT_SUMMARY,
        totals: EXPECTED_TOTALS
      },
      drifts: {
        graphRows: graphRowDrifts,
        namedRows: namedRowDrifts,
        gridSummaryRows: gridSummaryDrifts,
        gridCaseRows: gridCaseDrifts
      }
    }, null, 2)
  );
}

const failedGraphRows = audit.byGraph.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
const failedNamedChecks = audit.namedChecks.filter((row) => !row.passed);
const failedGridGroups = audit.gridSummary.filter(
  (row) => row.passed !== row.cases || row.passedChecks !== row.totalChecks
);
const failedCases = audit.cases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
if (!audit.ok || failedGraphRows.length || failedNamedChecks.length ||
    failedGridGroups.length || failedCases.length ||
    audit.passed !== audit.total || audit.passedChecks !== audit.totalChecks) {
  throw new Error(JSON.stringify({
    failures: audit.failures,
    failedGraphRows,
    failedNamedChecks,
    failedGridGroups,
    failedCases: failedCases.slice(0, 10),
    shapeErrors,
    auditShape
  }, null, 2));
}
console.log(
  `${audit.passed}/${audit.total} audit rows and ` +
  `${audit.passedChecks}/${audit.totalChecks} checks passed`
);
NODE

It verifies the brute-force oracle on every preset, checks 32 single contractions per graph against the oracle, checks that fixed-cut survival implies an optimal result, confirms that the ten-cycle always returns a min cut, and runs a 48-case grid over graph presets, seeds, and trial counts. The 365 checks count each lower-bound trial, each fixed-cut survival witness, each named regression, and four grid invariants per parameter case.

Keep The Parallel Edges

The line “delete self-loops, keep parallel edges” is not a programming detail. It is the distribution.

If two supernodes have five original edges between them, there should be five ways for the next random edge to choose that pair. Collapsing those five edges into one unweighted edge changes the algorithm. The lab stores parallel edges as separate edge copies for exactly this reason.

The same point explains weighted graphs. Karger’s original paper presents the algorithm for weighted undirected graphs too; integer weights can be viewed as parallel edge copies, and the paper discusses how to avoid making the runtime depend on the numeric sum of weights.¹ The browser lab stays small and integer because it also carries a brute-force exact oracle.

Why This Is Not A Max-Flow Story

Max-flow/min-cut proves optimality through a residual graph and a reachable set. Random contraction proves success by conditioning on a cut not being touched.

Both stories end with a cut, but the evidence is different.

For max-flow, the certificate is:

no residual path remains, and the reachable side has capacity equal to the flow

For random contraction, one successful trial’s certificate is weaker unless we also verify the cut value. The algorithm is Monte Carlo: it has a fixed running plan, and a single run can miss. The standard way to use it is to repeat trials and keep the smallest cut seen. In a production implementation, one would often pair that repeated randomized search with a deterministic or independently checked certificate when exactness matters.

This is why the lab includes the exact oracle even though it is exponential. It lets the small experiment say something honest:

the randomized algorithm returned value 2
the exhaustive oracle says no cut has value below 2

For larger graphs, that oracle is gone. The proof bound is what remains.

Karger-Stein As A Recursion Hint

The basic contraction algorithm repeats all the way down to two supernodes. Karger and Stein’s later algorithm changes the shape: contract partway, branch, and recurse, exploiting the fact that a minimum cut is a small fraction of the edges while avoiding some wasted full descents.² Their JACM paper gave a randomized strongly polynomial algorithm for weighted undirected min cut with high probability in O(n^2 log^3 n) time.

The lab does not implement that recursive version. It stays with the tiny algorithm because the survival event is visible. But the recursive improvement has the same soul: contract aggressively while the fixed cut is unlikely to be hit, then spend branching only when the graph is smaller.

Evidence, Interpretation, Speculation

Evidence. Karger’s 1992/1993 contraction paper defines the random contraction algorithm, proves the fixed minimum-cut survival bound 1 / binom(n, 2), and derives the repeated-trial high-probability result. Karger and Stein later improved the approach with recursive contraction and a faster high-probability algorithm for weighted undirected graphs.

Interpretation. The algorithm is best understood as survival analysis for a certificate that already exists. Randomness is not searching uniformly over all cuts. It is sampling contraction histories, and a good history is one that never touches the cut we care about.

Speculation. Random contraction is a useful antidote to a common engineering instinct: do not assume that a randomized algorithm is mysterious because its steps are locally reckless. Sometimes the right proof object is the event that the reckless step avoided one small forbidden set.

store hash(password)

That line is missing the adversary. The interesting event is not a normal login. The interesting event is a database leak. Once the password table is gone, the attacker is no longer asking your server for permission. They are running an offline search over candidate passwords, comparing each candidate with the stored verifier.

So the stored password verifier is not a checksum. It is a recurring invoice:

one password guess = time + memory + bandwidth + salt-specific work

The verifier has to be cheap enough that a real user can log in, but expensive enough that a leaked table does not become a parallel guessing festival.

That is the small design tension behind memory-hard password hashing.

The Hash Is A Guessing Budget

NIST SP 800-63B says verifiers should store passwords in a form resistant to offline attack; the current SP 800-63-4 text describes a password hashing scheme as taking a password, salt, and cost factor, then making each password guess more expensive for someone who has obtained the hashed password file.¹

That sentence is doing more work than it first appears to do.

First, this is an offline threat. Online rate limits, lockouts, step-up authentication, and anomaly detection matter, but they are not in the hot path after the table leaks. A stolen table turns the defense into arithmetic.

Second, the salt is not meant to be secret. Its job is to keep work from being reused. NIST requires at least 32 bits and says salts should be chosen to minimize collisions among stored hashes; RFC 9106 recommends 16-byte salts for Argon2 password hashing.² In practice, larger random salts are normal because storage is cheap and accidental reuse is embarrassing.

Third, the cost factor is not a moral gesture. It is an operational budget. Set it too low and offline search is cheap. Set it too high and login becomes a self-inflicted denial of service.

The security engineering question is therefore:

what is the largest per-login bill we can afford to hand to honest users?

Why Memory Changes The Attack Shape

Classic iterated hashes mostly charge time. That helps, but offline search is embarrassingly parallel: buy more hardware, run more guesses. Percival and Josefsson’s scrypt RFC makes the hardware economics explicit: if attackers can use custom parallel circuits, the relevant unit is closer to dollar-seconds than to one machine’s wall-clock time.³

Memory-hard schemes try to make parallel guesses rent scarce area too. A design that demands 64 MiB per guess cannot be packed into the same hardware shape as a design that demands 64 bytes per guess. The attacker now has to answer:

how many guesses can I keep resident at once?
what memory bandwidth feeds them?
what happens if I store less and recompute missing blocks?

Argon2 is the modern reference point. RFC 9106 describes Argon2 as a memory-hard function, names Argon2id as the primary variant to support, and gives two notable default recommendations: Argon2id with 2 GiB, 1 pass, 4 lanes, and a 128-bit salt as the first recommended option; and Argon2id with 64 MiB, 3 passes, 4 lanes, and a 128-bit salt when much less memory is available.⁴

Those recommendations are not “64 MiB is always enough” or “2 GiB is always practical.” They are reminders that the password hash has knobs with different physical meanings:

• memory limits parallel resident guesses;
• passes add repeated work over the memory;
• lanes expose parallelism inside one verifier call;
• salt prevents one computation from being spent against many accounts;
• tag and algorithm metadata let you migrate later.

The hash string should carry the algorithm and cost parameters, because tomorrow you may need to rehash at a higher cost after a successful login.

Lab: Spend The Login Budget

The lab below is not an Argon2 implementation and not a hardware benchmark. It is a static economics model with deliberately plain assumptions:

defender latency ~= fixed overhead + passes * memory / effective bandwidth
attacker slots   ~= attacker memory / per-guess memory
attacker rate    ~= min(slot-limited rate, bandwidth-limited rate)

For the time-memory tradeoff control, the lab uses a toy penalty:

penalty(alpha) = alpha^-1.45

where alpha is the fraction of full memory used. That is not a claim about a specific attack on Argon2. It is a visible contract: in this model, cutting memory buys more slots but pays for recomputation. RFC 9106’s security section discusses real time-space tradeoff attacks in terms of time-area product, and real deployments should rely on the scheme’s own analysis and current library guidance rather than this toy exponent.⁵

Default model:

The last two rows are the point of the salt panel. For one target, a salt does not make the chosen password stronger. For a breached table, unique salts stop one candidate word from being checked against every account with one KDF evaluation.

The audit exported by the script runs 12 named critical checks plus 216 generated checks over a 72-row memory/pass/tradeoff/salt grid:

node - <<'NODE'
const lab = require("./assets/js/password-hash-lab.js");
const EXPECTED_CRITICAL_CHECKS = 12;
const EXPECTED_ROWS = 72;
const EXPECTED_CASES = 228;
const EXPECTED_CHECKS = 228;
const EXPECTED_DEFAULT_SHAPE =
  "64:3:4:105.111:384:729.167:10000:128:1";
const EXPECTED_MEMORY_SHAPE = [
  "16:18/54:53.753:195.375:18",
  "64:18/54:113.012:48.844:18",
  "256:18/54:350.049:12.211:18",
  "1024:18/54:1298.198:3.053:0"
];
const EXPECTED_PASSES_SHAPE = [
  "1:24/72:159.926:18.316:18",
  "3:24/72:411.778:6.105:18",
  "6:24/72:789.556:3.053:18"
];
const EXPECTED_TRADEOFF_SHAPE = [
  "full:24/72:453.753:10.392:18",
  "half:24/72:453.753:7.607:18",
  "quarter:24/72:453.753:3.053:18"
];
const EXPECTED_SALT_SHAPE = [
  "shared:36/108:453.753:1.000:1585928.894:27",
  "unique:36/108:453.753:1000.000:1585928894.382:27"
];
const EXPECTED_CRITICAL_SHAPE = [
  "72-case password hash grid completed:1/1",
  "default latency is finite:1/1",
  "quarter-memory tradeoff does not improve total rate in toy model:1/1",
  "raising memory lowers attacker rate in model:1/1",
  "raising memory raises defender latency:1/1",
  "raising passes lowers attacker rate in model:1/1",
  "raising passes raises defender latency:1/1",
  "server concurrency budget is memory divided by per-login memory:1/1",
  "shared salt accelerates breach-wide search:1/1",
  "shared salt lets one KDF cover the breach word:1/1",
  "toy tradeoff penalty is memory-hard shaped:1/1",
  "unique salts force one KDF per account per word:1/1"
];
const EXPECTED_TOTALS = {
  criticalChecks: EXPECTED_CRITICAL_CHECKS,
  rows: EXPECTED_ROWS,
  passed: true,
  passedChecks: EXPECTED_CHECKS,
  total: EXPECTED_CASES,
  totalChecks: EXPECTED_CHECKS
};

function fixed3(value) {
  return Number(value).toFixed(3);
}

function sameJson(actual, expected) {
  return JSON.stringify(actual) === JSON.stringify(expected);
}

function defaultShape(row) {
  return [
    row.params.memory,
    row.params.passes,
    row.params.lanes,
    fixed3(row.latencyMs),
    row.attackerSlots,
    fixed3(row.hashRate),
    row.evalsPerDictionaryWord,
    row.maxConcurrentLogins,
    row.serverBudgetOk ? 1 : 0
  ].join(":");
}

function groupShape(row, key) {
  return [
    row[key],
    `${row.cases}/${row.totalChecks}`,
    fixed3(row.avgLatencyMs),
    fixed3(row.minHashRate),
    row.serverBudgetOk
  ].join(":");
}

function saltShape(row) {
  return [
    row.salt,
    `${row.cases}/${row.totalChecks}`,
    fixed3(row.avgLatencyMs),
    fixed3(row.avgEvalsPerDictionaryWord),
    fixed3(row.avgBreachMedianSeconds),
    row.serverBudgetOk
  ].join(":");
}

const audit = lab.auditPasswordHashLab();
const failed = audit.cases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
const failedCriticalChecks = audit.criticalChecks.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
console.log(audit.defaultResult);
console.table(audit.byMemory);
console.table(audit.byPasses);
console.table(audit.byTradeoff);
console.table(audit.bySalt);
console.table(audit.criticalChecks);
const auditShape = {
  defaultResult: defaultShape(audit.defaultResult),
  totals: {
    criticalChecks: audit.criticalTotal,
    rows: audit.cases.length,
    passed: audit.passed,
    passedChecks: audit.passedChecks,
    total: audit.total,
    totalChecks: audit.totalChecks
  },
  byMemory: audit.byMemory.map((row) => groupShape(row, "memory")),
  byPasses: audit.byPasses.map((row) => groupShape(row, "passes")),
  byTradeoff: audit.byTradeoff.map((row) => groupShape(row, "tradeoff")),
  bySalt: audit.bySalt.map(saltShape),
  criticalChecks: audit.criticalChecks.map(
    (row) => `${row.check}:${row.passedChecks}/${row.totalChecks}`
  ).sort()
};
const shapeErrors = [
  sameJson(auditShape.defaultResult, EXPECTED_DEFAULT_SHAPE) ? null : "defaultResult",
  sameJson(auditShape.totals, EXPECTED_TOTALS) ? null : "totals",
  sameJson(auditShape.byMemory, EXPECTED_MEMORY_SHAPE) ? null : "byMemory",
  sameJson(auditShape.byPasses, EXPECTED_PASSES_SHAPE) ? null : "byPasses",
  sameJson(auditShape.byTradeoff, EXPECTED_TRADEOFF_SHAPE) ? null : "byTradeoff",
  sameJson(auditShape.bySalt, EXPECTED_SALT_SHAPE) ? null : "bySalt",
  sameJson(auditShape.criticalChecks, EXPECTED_CRITICAL_SHAPE) ? null : "criticalChecks"
].filter(Boolean);
if (shapeErrors.length) {
  throw new Error(
    `audit grid drifted in ${shapeErrors.join(", ")}:\n` +
    JSON.stringify(auditShape, null, 2)
  );
}
if (
  failed.length ||
  failedCriticalChecks.length ||
  !audit.ok ||
  !audit.passed ||
  audit.passedChecks !== audit.totalChecks
) {
  throw new Error(JSON.stringify({
    failed,
    failedCriticalChecks,
    shapeErrors,
    auditShape,
    passed: audit.passed,
    passedChecks: audit.passedChecks,
    totalChecks: audit.totalChecks
  }, null, 2));
}
console.log(`${audit.passedChecks}/${audit.totalChecks} checks passed`);
NODE

It verifies monotone behavior for memory and passes, the salt accounting, the time-memory tradeoff shape, the server memory budget calculation, and a 72-case grid over memory, passes, tradeoffs, and salt modes (228 checks total).

Read The Knobs As Constraints

Raise Memory per hash from 64 MiB to 256 MiB. The lab’s defender latency goes from about 105 ms to about 318 ms, and the attacker’s modeled hash evaluation rate drops by roughly 4x. That is the trade: the honest server spends more memory and latency so the leaked-table attacker gets fewer resident guesses and less bandwidth headroom.

Now set Memory tradeoff to 1/4 memory. The attacker gets four times as many resident slots, but the toy recomputation penalty is larger than that slot gain, so the total modeled evaluation rate falls. This is the intuition memory hardness is trying to buy. It is not a proof about the real scheme.

Finally change Salt model to shared salt. The one-target line does not move. The breach-wide line collapses, because one candidate password can be tested against every account after one KDF evaluation. That is why salt uniqueness is table hygiene, not only cryptographic decoration.

What The Lab Leaves Out

The lab does not model GPUs, ASICs, cache hierarchy, library implementation details, side channels, or actual Argon2 indexing. The constants are knobs in a toy economy, not published benchmark numbers.

It also does not decide whether a password is good. A 40-bit search space in the plot is a simplified entropy ledger, not a statement about human password choice. Real password systems need blocklists for common and compromised passwords, online rate limiting, phishing-resistant recovery paths, MFA where appropriate, and careful handling of password managers and Unicode input. NIST’s password section is explicit about blocklists, rate limiting, full-password verification, and authenticated protected channels.¹

The password hash is the part that keeps working after the online controls have been bypassed by a table leak. It is necessary, not sufficient.

Evidence, Interpretation, Speculation

Evidence. NIST SP 800-63B requires salted, offline-resistant password storage and says cost factors should be as high as practical without hurting verifier performance. RFC 9106 describes Argon2 inputs, operation, Argon2id, and recommended parameter sets. RFC 7914 explains scrypt’s motivation in custom hardware economics.

Interpretation. The right mental model is budget accounting. A verifier cost is a production SLO for the defender and a search tax for the attacker. Memory is useful because it changes how many guesses can be parallelized under a fixed hardware budget.

Speculation. Many weak deployments survive because the password hash is reviewed like a library choice instead of a capacity plan. I would rather see a short table with measured p50/p95 login latency, memory pressure under burst, stored parameter strings, and rehash migration policy than a bare claim that “we use Argon2.”

Deployment Checklist

For a production password verifier, I want these questions answered:

1. Which scheme and exact parameter string is stored with each password?
2. What are p50, p95, and overload login latencies on production-shaped hardware?
3. How much memory is reserved for authentication under peak login and recovery traffic?
4. Are salts randomly generated, unique in practice, and stored per password?
5. Is there a server-side secret pepper or keyed post-processing step, and where is that key isolated?
6. What triggers rehashing to newer parameters?
7. Does account recovery meet at least the same offline-resistance standard?
8. Are chosen passwords checked against common, expected, and compromised password blocklists?

A password hash rents memory so an attacker has to rent it too. The invoice should be visible before the breach, not discovered afterward.

build a hash table from the smaller input
scan the larger input
probe the table for matching keys

That is the pleasant case. It is also the case that hides the interesting engineering.

The executor does not always receive a build side that fits in memory. Cardinality estimates are wrong. Tuple widths are larger than expected. A key distribution is not uniform. Several queries are competing for memory. At that point the hash join needs a spillway: a way to turn one too-large join into many smaller joins without changing the answer.

The trick is to partition both relations by the join key.

If a build tuple r and a probe tuple s can join, then their join keys are equal, so a deterministic partition hash sends them to the same batch:

Therefore:

join(R, S)
=
union over batches i of join(R_i, S_i)

The hash table only has to hold one build batch at a time.

Two Hashes, Two Jobs

It helps to separate two hashes that are often blurred together.

The partition hash decides which batch a tuple belongs to. It is the spillway contract. Corresponding build and probe tuples must go to the same batch.

The lookup hash is used inside one resident batch to find matching build tuples quickly.

These are conceptually different jobs. The first bounds memory by cutting the problem into files. The second avoids comparing every tuple inside a file.

Shapiro’s 1986 paper describes three hash-based join strategies: simple hash, GRACE hash, and hybrid hash.¹ The shared idea is partitioning. If the smaller relation cannot fit in memory, partition both inputs into corresponding subsets, then join matching subsets. The hybrid algorithm keeps one partition resident while spilling the rest, so it degrades from an in-memory hash join toward GRACE-style partitioning as memory becomes scarce.

That is the shape modern systems still expose. PostgreSQL’s EXPLAIN ANALYZE shows Buckets, Batches, and hash memory usage on hash nodes; its docs note that more than one batch implies disk space is involved even when the display does not show the disk amount.² PostgreSQL also makes the memory budget for hash operations depend on work_mem * hash_mem_multiplier.³

So the line:

Buckets: 65536  Batches: 8  Memory Usage: 4096kB

is not decoration. It is a field report from the spillway.

Lab: Batches Are a Memory Promise

The lab below builds deterministic synthetic key-count tables for a build input and a probe input. It estimates the batch count from the build-side memory budget, partitions both sides by the same hash, then doubles the batch count until every build batch fits or a single key is too large to split.

It does not simulate PostgreSQL tuple headers, cache misses, executor state machines, parallel barriers, filesystem behavior, or output materialization. The purpose is narrower:

• show why build and probe sides must be partitioned together;
• show why Batches > 1 means extra temporary writes and reads;
• show why skew can make the original batch estimate grow;
• show the degenerate case where one hot key is larger than memory.

The Default Run

The default run has:

• 240,000 build rows;
• 620,000 probe rows;
• 12,000 distinct keys;
• memory for 42,000 build rows;
• a long-tail key distribution with skew exponent 0.95.

The initial estimate is:

rounded up to 8 power-of-two batches. Under the actual key distribution, one of those batches is too large, so the executor model doubles to 16 batches. The largest build batch then has 35,434 rows, below the 42,000 row memory budget.

The hybrid spill ledger reports:

The last number is a separate warning. A spill strategy controls memory. It does not make a high-multiplicity join small. If many build and probe tuples share a key, the output can still be enormous.

The exported audit grid is reproducible from Node:

const lab = require("./assets/js/hash-join-spill-lab.js");
const EXPECTED_CASE_SHAPE = [
  "1:uniform:120000/260000:mem=40000:4->4:growth=0:fits=true:30853:570148:12:11/11",
  "2:zipf:240000/620000:mem=42000:8->16:growth=1:fits=true:35434:1638784:14233:11/11",
  "3:hot:220000/500000:mem=35000:8->8:growth=0:fits=false:65129:1295540:42592:11/11",
  "4:burst:360000/700000:mem=56000:8->8:growth=0:fits=true:47659:1858390:148:11/11"
];
const EXPECTED_BY_PROFILE_SHAPE = [
  "uniform:4->4:fits=true:1/1:11/11",
  "zipf:8->16:fits=true:1/1:11/11",
  "hot:8->8:fits=false:1/1:11/11",
  "burst:8->8:fits=true:1/1:11/11"
];
const EXPECTED_CHECK_NAMES = [
  "build rows preserved",
  "probe rows preserved",
  "batch count power of two",
  "partition build rows preserved",
  "partition probe rows preserved",
  "temp accounting nonnegative",
  "hybrid does not spill more than grace",
  "fits or has skew explanation",
  "top key count agrees",
  "uniform case fits after batching",
  "hot key can exceed memory"
];
const EXPECTED_CHECK_ROWS = [
  "1:uniform:build rows preserved=true|probe rows preserved=true|batch count power of two=true|partition build rows preserved=true|partition probe rows preserved=true|temp accounting nonnegative=true|hybrid does not spill more than grace=true|fits or has skew explanation=true|top key count agrees=true|uniform case fits after batching=true|hot key can exceed memory=true",
  "2:zipf:build rows preserved=true|probe rows preserved=true|batch count power of two=true|partition build rows preserved=true|partition probe rows preserved=true|temp accounting nonnegative=true|hybrid does not spill more than grace=true|fits or has skew explanation=true|top key count agrees=true|uniform case fits after batching=true|hot key can exceed memory=true",
  "3:hot:build rows preserved=true|probe rows preserved=true|batch count power of two=true|partition build rows preserved=true|partition probe rows preserved=true|temp accounting nonnegative=true|hybrid does not spill more than grace=true|fits or has skew explanation=true|top key count agrees=true|uniform case fits after batching=true|hot key can exceed memory=true",
  "4:burst:build rows preserved=true|probe rows preserved=true|batch count power of two=true|partition build rows preserved=true|partition probe rows preserved=true|temp accounting nonnegative=true|hybrid does not spill more than grace=true|fits or has skew explanation=true|top key count agrees=true|uniform case fits after batching=true|hot key can exceed memory=true"
];
const EXPECTED_CASES = EXPECTED_CASE_SHAPE.length;
const EXPECTED_CHECKS = EXPECTED_CASES * EXPECTED_CHECK_NAMES.length;

function sameList(actual, expected) {
  return actual.length === expected.length &&
    actual.every((value, index) => value === expected[index]);
}

function caseShape(row, index) {
  return `${index + 1}:${row.profile}:${row.buildRows}/${row.probeRows}:` +
    `mem=${row.memoryRows}:${row.originalBatches}->${row.actualBatches}:` +
    `growth=${row.growthEvents}:fits=${row.fits}:` +
    `${row.maxBuildBatchRows}:${row.hybridTempRows}:${row.topBuildKeyRows}:` +
    `${row.passedChecks}/${row.totalChecks}`;
}

function byProfileShape(row) {
  return `${row.profile}:${row.batches}:fits=${row.fits}:` +
    `${row.passed}/${row.total}:${row.passedChecks}/${row.totalChecks}`;
}

function checkRow(row, index) {
  return `${index + 1}:${row.profile}:` +
    row.checks.map((check) => `${check.name}=${check.ok}`).join("|");
}

function rowDrifts(actual, expected) {
  return {
    missing: expected.filter((row) => !actual.includes(row)),
    extra: actual.filter((row) => !expected.includes(row))
  };
}

function hasRowDrift(drift) {
  return drift.missing.length > 0 || drift.extra.length > 0;
}

const audit = lab.auditGrid();
const failed = audit.cases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
console.table(audit.byProfile);
const shape = {
  byProfile: audit.byProfile.map(byProfileShape),
  cases: audit.cases.map(caseShape),
  checkRows: audit.cases.map(checkRow)
};
const checkRowDrifts = rowDrifts(shape.checkRows, EXPECTED_CHECK_ROWS);
const shapeErrors = [];
if (!sameList(shape.cases, EXPECTED_CASE_SHAPE)) {
  shapeErrors.push({ name: "cases", actual: shape.cases, expected: EXPECTED_CASE_SHAPE });
}
if (!sameList(shape.byProfile, EXPECTED_BY_PROFILE_SHAPE)) {
  shapeErrors.push({
    name: "byProfile",
    actual: shape.byProfile,
    expected: EXPECTED_BY_PROFILE_SHAPE
  });
}
audit.cases.forEach((row, index) => {
  const names = row.checks.map((check) => check.name);
  if (!sameList(names, EXPECTED_CHECK_NAMES)) {
    shapeErrors.push({
      name: `case ${index + 1} check names`,
      actual: names,
      expected: EXPECTED_CHECK_NAMES
    });
  }
});
if (hasRowDrift(checkRowDrifts)) {
  shapeErrors.push({ name: "check rows", drift: checkRowDrifts });
}

console.table(audit.cases.map((row) => ({
  profile: row.profile,
  batches: `${row.originalBatches}->${row.actualBatches}`,
  fits: row.fits,
  maxBuildBatch: row.maxBuildBatchRows,
  memoryRows: row.memoryRows,
  tempRows: row.hybridTempRows,
  topKeyRows: row.topBuildKeyRows,
  checks: `${row.passedChecks}/${row.totalChecks}`
})));
const summary =
  `${audit.passed}/${audit.total} cases and ${audit.passedChecks}/${audit.totalChecks} checks passed`;
if (
  shapeErrors.length ||
  failed.length ||
  !audit.ok ||
  audit.total !== EXPECTED_CASES ||
  audit.totalChecks !== EXPECTED_CHECKS ||
  audit.passed !== audit.total ||
  audit.passedChecks !== audit.totalChecks
) {
  throw new Error(JSON.stringify({
    summary,
    shapeErrors,
    shape,
    failed,
    totals: {
      total: audit.total,
      passed: audit.passed,
      passedChecks: audit.passedChecks,
      totalChecks: audit.totalChecks
    }
  }, null, 2));
}
console.log(summary);

The hot row is allowed to fail the fit test only because the audit also requires a skew explanation. A spill plan that silently overflows memory is not a valid plan.

The current grid covers four key profiles and 44 named checks. Those checks verify row preservation before and after partitioning, power-of-two batch counts, nonnegative temporary I/O, hybrid-vs-GRACE spill accounting, top-key bookkeeping, and the two regression cases the prose leans on: uniform data fits after batching, while a single hot key can exceed memory even after batch growth.

The Spill Invariant

Let the partition function be:

For each batch i, define:

and

If r.key = s.key, then b(r.key) = b(s.key). Therefore every true join pair appears inside exactly one corresponding pair (R_i, S_i). No valid pair is lost by processing one batch at a time.

This is why the probe side must be spilled too. It is not enough to save the build partitions. The executor also needs the matching probe tuples waiting in the same batch files, or it would have to rescan the entire probe input for every build batch.

The simplified temporary I/O cost for a GRACE-style partitioned hash join is roughly:

temporary rows: write both inputs into partitions, then read them back. A hybrid hash join saves the resident batch. In the default lab run, batch 0 keeps 11,523 build rows and its corresponding 29,085 probe rows out of temporary files, so the hybrid ledger is smaller than the all-partitioned ledger.

When Batches Explode

PostgreSQL’s executor comments describe the modern dynamic version: if the inner side does not fit, hash join can run in multiple batches; if the real hash table grows too large, the executor increases the number of batches, always by powers of two.⁴

That power-of-two detail is not cosmetic. It lets the executor add one more hash bit to split every old batch into two possible new batches:

old batch: h(key) & 0b0111
new batch: h(key) & 0b1111

Uniform data responds nicely. Long-tail data responds imperfectly. A single heavy key does not respond at all, because all rows with that key must stay in the same batch. PostgreSQL’s source comments call out this kind of best-effort edge: if doubling leaves a batch with all or none of its tuples, growth can be disabled globally, and later oversized batches may exceed the nominal budget.⁴

In the lab, switch Key profile to Single hot key and raise Skew exponent. The top-key panel eventually turns red: one key alone is larger than memory. No partition hash on the join key can split that key while preserving the join invariant.

Real engines have more choices than this toy:

• skew optimization for most-common values;
• recursive partitioning;
• bloom filters or semijoins to reduce one side before spilling;
• switching join algorithms;
• increasing memory for this operator;
• parallel work sharing;
• pushing predicates earlier;
• changing the query shape so the build side is genuinely smaller.

The invariant remains the same. If a batch is too large because many distinct keys landed there, more hash bits can help. If a batch is too large because one key is too large, batch count is the wrong lever.

Reading The Plan

For a production PostgreSQL plan, I would read a hash join spill with four questions:

1. Is Batches greater than 1?
2. Did actual batches exceed original batches?
3. Is the build-side row estimate or width estimate badly wrong?
4. Is the join key skewed enough that more batches cannot divide the problem?

The first question says whether the spillway opened. The second says whether the executor had to resize the spillway while running. The third asks whether the optimizer walked into the wrong memory budget. The fourth asks whether the data distribution violated the uniform partition fantasy.

That last phrase is the quiet contract behind hash join:

partitioning is a memory theorem only if the partitions become small enough

Hash join is fast because equality makes a partition proof possible. It is fragile because the proof says where matches go, not how evenly the data will arrive.

Sources

Red-black colors, AVL heights, B-tree page sizes, treap priorities: some extra state says why the next path should be short.

A splay tree makes a stranger bargain. It stores no balance metadata. It lets the shape drift. After every successful access, it rotates the accessed node to the root.

That sounds almost too eager. Why spend rotations on a lookup that already found its key?

Because lookup traces are rarely independent uniform samples. Programs ask for the same object again. They walk around a neighborhood of keys. They change phases. They scan. A splay tree is a binary search tree that bets on this temporal structure by editing the tree after the fact.

The slogan is not “splay trees are faster.” A more honest slogan is:

pay now to make the recent path shallow

Sometimes the bet wins. Sometimes the rotations are just overhead.

The Local Rule

Search as usual. When the key is found, repeatedly rotate it upward until it becomes the root.

The cases are classified by the accessed node x, its parent p, and its grandparent g.

zig      x has no grandparent: rotate x over p
zig-zig  x and p are both left children or both right children:
         rotate p over g, then x over p
zig-zag  x is a left child and p is a right child, or the reverse:
         rotate x over p, then x over g

The important detail is the double rotation. A naive “rotate the accessed node one edge at a time” rule is tempting, but Sleator and Tarjan showed that this simple move-to-root heuristic does not get the same amortized guarantees.¹ The zig-zig and zig-zag steps are the accounting trick. They pull x up while also compressing a chunk of the old search path.

After an access, the last key is at the root. If the exact same key is accessed again, the search is one comparison and no rotations. If nearby keys are accessed next, many of the same ancestors have also been pulled closer.

The Accounting Is Not Stored In The Tree

Splay analysis assigns arbitrary positive weights to items. These weights are not fields in the nodes. They are a proof device.

For a node x, define:

and

The potential of the tree is the sum of ranks:

Sleator and Tarjan’s access lemma says that splaying a node x in a tree with root t has amortized cost at most¹

Equivalently, up to constants, the cost is controlled by

That line is the machine room. Choose all weights equal and the lemma gives the ordinary logarithmic amortized bound. Choose weights proportional to long-run access frequencies and it gives static optimality. Change weights as the access sequence unfolds and it gives a working-set bound.

The algorithm did not change. Only the analysis did.

What The Theorems Say

For a sequence of m accesses on n keys, the original paper proves a balance theorem:

So over a long enough sequence, splaying is within a constant factor of ordinary balanced search trees in total access time.

It also proves a static optimality theorem. If key i is accessed q(i) times, then the total access time is bounded by

assuming every item appears at least once. That resembles an entropy bound: a key that is asked for often is allowed to become cheap without the tree being told its frequency in advance.

The working-set theorem is even closer to a systems intuition. Let t(j) be the number of distinct keys accessed since the previous access to the key requested at time j, or since the beginning of the sequence if this is the key’s first access. Splay trees have total access time

Recent keys are cheap. Stale keys are allowed to be expensive.

There are also important boundaries. Sleator and Tarjan conjectured dynamic optimality: roughly, that splay trees are within a constant factor of any binary search tree algorithm that can also rotate between accesses, even one tailored to the whole sequence. That remains a conjecture. Later work proved pieces of the adaptive picture, including Tarjan’s linear-time theorem for one sequential in-order pass and Cole’s dynamic-finger theorem, which bounds access cost by the rank distance from the previous access.²³

The safe statement is:

Splaying has strong amortized guarantees and several proven locality-sensitive bounds, but not every finite trace beats a well-tuned balanced tree under every cost model.

Lab: Charge The Rotations

The lab below implements a bottom-up splay tree with parent pointers and a fixed balanced binary search tree over the same keys.

For each access, it records:

• splay search comparisons;
• splay rotations;
• splay primitive cost, defined here as comparisons plus rotations;
• fixed balanced-tree comparisons;
• working-set distance in the generated trace.

That cost model is intentionally unsentimental. The theorem is amortized and abstract. Real code still pays for pointer writes, cache behavior, branch prediction, allocator layout, and concurrency constraints. Counting comparisons plus rotations is not a full CPU model, but it keeps the rotation bill visible.

The Default Run

The default local-walk trace has 63 keys and 1,200 accesses. It starts near the middle key and mostly moves by small rank steps, with occasional wider jumps.

The measured result:

The average barely favors splaying under this deliberately simple cost model, but the distribution is different. The splay tree has cheaper repeated and local accesses, and more expensive cold jumps.

Bucketed by working-set distance:

That is the working-set theorem in miniature, not as a proof but as a diagnostic shape. The recent buckets are where the rotations pay rent. The stale buckets are where the tree admits it has been optimized for something else.

Switch to the phase-shift trace and the bill becomes more visible. The tree adapts, but it can spend rotations chasing the new hot region. Switch to the sequential scan and remember that the classic sequential-access theorem is about one sorted pass from an arbitrary starting tree, not about every possible cyclic-scan workload under a comparisons-plus-rotations accounting.

Implementation Notes

The browser code builds the splay tree as an initially balanced tree over 1..n, then uses bottom-up parent-pointer rotations:

while x is not root:
    if x has no grandparent:
        rotate x
    else if x and parent are on the same side:
        rotate parent
        rotate x
    else:
        rotate x
        rotate x

The audit checks that:

• inorder traversal remains exactly 1..n;
• the root has no parent pointer;
• parent pointers agree with child links;
• every accessed key is found;
• every accessed key becomes the root after access;
• rolling averages remain finite;
• rotations are nonnegative;
• the fixed balanced baseline stays within its comparison bound;
• a repeated access costs one comparison and zero rotations.

Those checks do not prove the theorem. They make the visualization less likely to be a decorative lie. The exported sweep reports 51 named checks: ten invariants across each trace, plus one scan-specific generation check.

To reproduce the deterministic audit cases from the repository root:

node - <<'NODE'
const lab = require("./assets/js/splay-tree-lab.js");
const EXPECTED_CASE_SHAPE = [
  "1:hot:keys=31:accesses=300:hot=5:seed=7:5.73/3.37/2.37/3.85:rot=710:repeat=1:10/10",
  "2:phase:keys=63:accesses=1200:hot=8:seed=31:7.47/4.24/3.24/5.07:rot=3885:repeat=1:10/10",
  "3:scan:keys=63:accesses=256:hot=6:seed=11:8.83/4.91/3.91/5.10:rot=1002:repeat=none:11/11",
  "4:walk:keys=127:accesses=1600:hot=12:seed=19:5.03/3.01/2.01/6.02:rot=3223:repeat=1:10/10",
  "5:zipf:keys=127:accesses=2000:hot=10:seed=23:11.89/6.45/5.45/6.27:rot=10890:repeat=1:10/10"
];
const EXPECTED_COMMON_CHECK_NAMES = [
  "inorder key count",
  "inorder sorted",
  "root parent is null",
  "parent pointers",
  "all accesses found",
  "accessed key becomes root",
  "finite averages",
  "nonnegative rotations",
  "balanced comparison bound",
  "repeat access becomes root-cheap"
];
const EXPECTED_SCAN_CHECK_NAMES = EXPECTED_COMMON_CHECK_NAMES.concat([
  "scan generated in order"
]);
const EXPECTED_CASES = EXPECTED_CASE_SHAPE.length;
const EXPECTED_CHECKS =
  EXPECTED_CASES * EXPECTED_COMMON_CHECK_NAMES.length +
  (EXPECTED_SCAN_CHECK_NAMES.length - EXPECTED_COMMON_CHECK_NAMES.length);
const EXPECTED_CHECK_ROWS = EXPECTED_CASE_SHAPE.map((shape, index) => {
  const scenario = shape.split(":")[1];
  const names =
    scenario === "scan" ? EXPECTED_SCAN_CHECK_NAMES : EXPECTED_COMMON_CHECK_NAMES;
  return `${index + 1}:` + names.map((name) => `${name}=true`).join("|");
});

function sameList(actual, expected) {
  return actual.length === expected.length &&
    actual.every((value, index) => value === expected[index]);
}

function repeatCost(value) {
  return value == null ? "none" : String(value);
}

function caseShape(row) {
  return `${row.caseId}:${row.scenario}:keys=${row.keys}:` +
    `accesses=${row.accesses}:hot=${row.hotSet}:seed=${row.seed}:` +
    `${row.splayAveragePrimitive.toFixed(2)}/${row.splayAverageSearch.toFixed(2)}/` +
    `${row.splayAverageRotations.toFixed(2)}/${row.balancedAverageSearch.toFixed(2)}:` +
    `rot=${row.totalRotations}:repeat=${repeatCost(row.repeatedSameKeyCost)}:` +
    `${row.passedChecks}/${row.totalChecks}`;
}

function checkRow(row) {
  return `${row.caseId}:` +
    row.checks.map((check) => `${check.name}=${check.ok}`).join("|");
}

function rowDrifts(actual, expected) {
  return {
    missing: expected.filter((row) => !actual.includes(row)),
    extra: actual.filter((row) => !expected.includes(row))
  };
}

function hasRowDrift(drift) {
  return drift.missing.length > 0 || drift.extra.length > 0;
}

const audit = lab.auditGrid();
const failed = audit.cases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
const shape = {
  cases: audit.cases.map(caseShape),
  checkRows: audit.cases.map(checkRow)
};
const checkRowDrifts = rowDrifts(shape.checkRows, EXPECTED_CHECK_ROWS);
const shapeErrors = [];
if (!sameList(shape.cases, EXPECTED_CASE_SHAPE)) {
  shapeErrors.push({ name: "cases", actual: shape.cases, expected: EXPECTED_CASE_SHAPE });
}
audit.cases.forEach((row) => {
  const names = row.checks.map((check) => check.name);
  const expected =
    row.scenario === "scan" ? EXPECTED_SCAN_CHECK_NAMES : EXPECTED_COMMON_CHECK_NAMES;
  if (!sameList(names, expected)) {
    shapeErrors.push({
      name: `case ${row.caseId} check names`,
      actual: names,
      expected
    });
  }
});
if (hasRowDrift(checkRowDrifts)) {
  shapeErrors.push({ name: "checkRows", drift: checkRowDrifts });
}
console.table(audit.cases.map((row) => ({
  scenario: row.scenario,
  keys: row.keys,
  accesses: row.accesses,
  splayAvg: row.splayAveragePrimitive.toFixed(2),
  balancedAvg: row.balancedAverageSearch.toFixed(2),
  rotations: row.splayAverageRotations.toFixed(2),
  checks: `${row.passedChecks}/${row.totalChecks}`,
  passed: row.passed
})));
const summary =
  `${audit.passed}/${audit.total} cases and ${audit.passedChecks}/${audit.totalChecks} checks passed`;
if (
  shapeErrors.length ||
  failed.length ||
  !audit.ok ||
  audit.total !== EXPECTED_CASES ||
  audit.totalChecks !== EXPECTED_CHECKS ||
  audit.passed !== audit.total ||
  audit.passedChecks !== audit.totalChecks
) {
  throw new Error(JSON.stringify({
    summary,
    shapeErrors,
    shape,
    checkRowDrifts,
    failed,
    errors: audit.errors,
    totals: {
      total: audit.total,
      passed: audit.passed,
      passedChecks: audit.passedChecks,
      totalChecks: audit.totalChecks
    }
  }, null, 2));
}
console.log(summary);
NODE

When Would I Use This?

Splay trees are appealing when:

• access locality is strong and changes over time;
• amortized bounds are acceptable;
• storing balance metadata is unattractive;
• simple split, join, and “move this thing to the top” behavior is useful.

They are less appealing when:

• individual-operation latency must be tightly bounded;
• reads must not mutate the structure;
• concurrent readers are common;
• memory layout and cache behavior dominate pointer-level comparison counts;
• a B-tree, hash table, radix tree, or sorted array better matches the workload.

The most useful lesson is broader than the data structure. A splay tree is an online adaptation rule. It has no model of the future, only a disciplined way to make the recent past cheap. Amortized analysis explains why that discipline does not collapse into arbitrary thrashing.

The tree rotates toward reuse. Whether reuse is actually there is a property of the trace.

Sources

is this key possibly present?

It cannot answer:

which keys are in you?

That second question sounds too much like asking a shadow to produce the object that cast it. Most of the time, that is exactly right. A saturated Bloom filter does not contain a recoverable list.

An invertible Bloom lookup table changes the bargain. It stores a small algebraic receipt per cell: a count, an XOR of keys, and a checksum XOR. If a cell is holding exactly one remaining key, the table can recognize that fact, recover the key, delete it from its other cells, and possibly reveal more single keys.

That makes the structure feel less like a membership filter and more like a peelable puzzle.

The useful systems move is subtraction. If Alice and Bob hold two huge, mostly equal sets, they can build compatible IBLTs, subtract the tables cell by cell, and try to list only the symmetric difference. Shared keys cancel. The residue is the part they need to exchange.

The Problem Is Not Membership

Suppose two replicas each hold file-block IDs, calendar event IDs, routing updates, or content-addressed chunks:

Alice: many keys
Bob:   many keys

The expensive but simple reconciliation protocol is:

exchange sorted lists, diff them

That spends bandwidth proportional to the total set sizes. A log can do better when both sides share prior context, but logs have their own operational price: they have to be maintained, retained, compacted, and interpreted correctly.

Eppstein, Goodrich, Uyeda, and Varghese framed the no-prior-context version cleanly in their Difference Digest paper: compute the set difference in a single round with communication proportional to the size of the difference, not the size of the original sets.¹

That is the shape of the problem:

large sets, small difference, no shared update log

An ordinary Bloom filter is the wrong tool for this particular job. It can help one side guess which of its keys the other might have, but it still communicates information shaped by the full set and it has false positives. Set reconciliation needs a way for common keys to disappear.

The Cell Receipt

In the key-only IBLT used by the lab, each cell stores:

count    = signed number of mapped keys
keyXor   = XOR of mapped keys
hashXor  = XOR of checksum(key) for mapped keys

Each key maps to k cells. Insert updates every mapped cell:

count   += 1
keyXor  ^= key
hashXor ^= checksum(key)

Deletion uses the same XOR updates and subtracts from the count:

count   -= 1
keyXor  ^= key
hashXor ^= checksum(key)

Goodrich and Mitzenmacher’s IBLT paper describes the general key-value version with a count field, a key-sum field, and a value-sum field; it also notes that XOR can replace sums in many settings to avoid overflow issues.²

For reconciliation, Alice builds a table for her set. Bob builds a table with the same size, hash functions, and checksum function. Then one side subtracts:

diff.count   = alice.count - bob.count
diff.keyXor  = alice.keyXor ^ bob.keyXor
diff.hashXor = alice.hashXor ^ bob.hashXor

A shared key appears once in Alice’s table and once in Bob’s table. It maps to the same cells. In the subtraction, its count contribution becomes zero and its XOR contribution cancels.

Only disagreement remains.

The Peel

A cell is pure when it looks like exactly one remaining key:

abs(count) == 1
hashXor == checksum(keyXor)

If count == 1, the key belongs to Alice but not Bob. If count == -1, it belongs to Bob but not Alice. After recording that key, the decoder removes it from every cell it hashes to.

That deletion can expose new pure cells:

find pure cell
recover key and side
delete that key from its k cells
repeat

This is not merely a convenient implementation. Goodrich and Mitzenmacher point out that IBLT listing is the same peeling process used to find the 2-core of a random hypergraph: cells are vertices, keys are hyperedges, and decoding stops when every remaining vertex has degree at least two.³

That gives the most important failure mode a concrete shape:

no pure cells left, but nonempty cells remain

The table is not lying. It is stuck.

The Lab

The lab below builds two full synthetic sets, inserts both into compatible IBLTs, subtracts the tables, and runs the pure-cell peeling decoder. It also runs a small deterministic capacity sweep so the failure cliff is visible.

The byte accounting is intentionally simple: each cell is treated as three 32-bit words, count, keyXor, and hashXor. Real systems choose wider checksums, salts, encodings, and failure budgets.

The default run has 2,500 shared keys and 84 differing keys. The two full lists would cost about 20.3 KB under the lab’s 32-bit key model; the IBLT message costs about 2.2 KB and decodes the exact difference.

The exported audit checks five deterministic scenarios and reports 25 named checks. It verifies that:

• a shared set cancels to an empty subtracted table;
• decoded Alice-only and Bob-only keys match the exact generated difference;
• every peeled cell has a valid side, +1 or -1;
• successful decodes leave no residual cells; and
• the subtracted table’s nonempty cells are bounded by the number of difference keys times the hash count.

The compact reproduction check is:

node - <<'NODE'
const lab = require("./assets/js/iblt-reconciliation-lab.js");
const EXPECTED_CASES = 5;
const EXPECTED_CHECKS = 25;
const EXPECTED_CHECK_NAMES = [
  "decoded-difference-exact",
  "peeled-cell-sign-valid",
  "shared-set-cancels-empty",
  "subtracted-cells-bounded",
  "successful-decode-empty-residual"
];
const EXPECTED_CASE_SHAPE = [
  "alice:5:24:62:3:2.55:19:24:0:744:3296",
  "balanced:5:140:308:5:2.2:73:140:0:3696:26160",
  "bob:5:48:84:4:1.75:16:48:0:1008:7392",
  "default-balanced:5:84:185:3:2.2:59:84:0:2220:20336",
  "split:5:90:171:3:1.9:61:90:0:2052:9960"
];
const EXPECTED_CASE_ROWS = [
  "alice:diff=24:cells=62:hashes=3:factor=2.55:pure=19:peeled=24:residual=0:bytes=744/3296:ratio=4.43:checks=5/5:passed=true",
  "balanced:diff=140:cells=308:hashes=5:factor=2.2:pure=73:peeled=140:residual=0:bytes=3696/26160:ratio=7.08:checks=5/5:passed=true",
  "bob:diff=48:cells=84:hashes=4:factor=1.75:pure=16:peeled=48:residual=0:bytes=1008/7392:ratio=7.33:checks=5/5:passed=true",
  "default-balanced:diff=84:cells=185:hashes=3:factor=2.2:pure=59:peeled=84:residual=0:bytes=2220/20336:ratio=9.16:checks=5/5:passed=true",
  "split:diff=90:cells=171:hashes=3:factor=1.9:pure=61:peeled=90:residual=0:bytes=2052/9960:ratio=4.85:checks=5/5:passed=true"
];
const EXPECTED_CHECK_ROWS = [
  "alice:decoded-difference-exact=true|peeled-cell-sign-valid=true|shared-set-cancels-empty=true|subtracted-cells-bounded=true|successful-decode-empty-residual=true",
  "balanced:decoded-difference-exact=true|peeled-cell-sign-valid=true|shared-set-cancels-empty=true|subtracted-cells-bounded=true|successful-decode-empty-residual=true",
  "bob:decoded-difference-exact=true|peeled-cell-sign-valid=true|shared-set-cancels-empty=true|subtracted-cells-bounded=true|successful-decode-empty-residual=true",
  "default-balanced:decoded-difference-exact=true|peeled-cell-sign-valid=true|shared-set-cancels-empty=true|subtracted-cells-bounded=true|successful-decode-empty-residual=true",
  "split:decoded-difference-exact=true|peeled-cell-sign-valid=true|shared-set-cancels-empty=true|subtracted-cells-bounded=true|successful-decode-empty-residual=true"
];
const EXPECTED_RESIDUAL_SHAPE = [
  "alice:0",
  "balanced:0",
  "bob:0",
  "default-balanced:0",
  "split:0"
];
const EXPECTED_TOTALS = {
  rows: EXPECTED_CASES,
  passed: EXPECTED_CASES,
  total: EXPECTED_CASES,
  passedChecks: EXPECTED_CHECKS,
  totalChecks: EXPECTED_CHECKS
};

function sameJson(actual, expected) {
  return JSON.stringify(actual) === JSON.stringify(expected);
}

function rowDrifts(actual, expected) {
  const count = Math.max(actual.length, expected.length);
  const drift = [];
  for (let index = 0; index < count; index += 1) {
    if (actual[index] !== expected[index]) {
      drift.push({ index, actual: actual[index], expected: expected[index] });
    }
  }
  return drift;
}

const audit = lab.auditIBLTLab();
const auditShape = {
  totals: {
    rows: audit.cases.length,
    passed: audit.passed,
    total: audit.total,
    passedChecks: audit.passedChecks,
    totalChecks: audit.totalChecks
  },
  caseChecks: audit.cases.map((row) => [
    row.scenario,
    row.totalChecks,
    row.diffSize,
    row.cells,
    row.hashes,
    row.factor,
    row.initialPure,
    row.peeled,
    row.residual,
    row.bytesIblt,
    row.bytesLists
  ].join(":")).sort(),
  caseRows: audit.cases.map((row) =>
    `${row.scenario}:diff=${row.diffSize}:cells=${row.cells}:` +
    `hashes=${row.hashes}:factor=${row.factor}:pure=${row.initialPure}:` +
    `peeled=${row.peeled}:residual=${row.residual}:` +
    `bytes=${row.bytesIblt}/${row.bytesLists}:` +
    `ratio=${row.compressionRatio.toFixed(2)}:` +
    `checks=${row.passedChecks}/${row.totalChecks}:passed=${row.passed}`
  ).sort(),
  checkRows: audit.cases.map((row) =>
    `${row.scenario}:` +
    row.checks.map((check) => `${check.name}=${check.ok}`).sort().join("|")
  ).sort(),
  checkNames: Array.from(new Set(audit.cases.flatMap(
    (row) => row.checks.map((check) => check.name)
  ))).sort(),
  residualByScenario: Object.entries(audit.byScenario)
    .map(([scenario, row]) => `${scenario}:${row.residual}`)
    .sort()
};
const caseRowDrifts = rowDrifts(auditShape.caseRows, EXPECTED_CASE_ROWS);
const checkRowDrifts = rowDrifts(auditShape.checkRows, EXPECTED_CHECK_ROWS);
const shapeErrors = [
  sameJson(auditShape.totals, EXPECTED_TOTALS) ? null : "totals",
  sameJson(auditShape.caseChecks, EXPECTED_CASE_SHAPE) ? null : "caseChecks",
  caseRowDrifts.length ? "caseRows" : null,
  checkRowDrifts.length ? "checkRows" : null,
  sameJson(auditShape.checkNames, EXPECTED_CHECK_NAMES) ? null : "checkNames",
  sameJson(auditShape.residualByScenario, EXPECTED_RESIDUAL_SHAPE)
    ? null
    : "residualByScenario"
].filter(Boolean);
if (shapeErrors.length) {
  throw new Error(
    `audit shape drifted in ${shapeErrors.join(", ")}:\n` +
    JSON.stringify({
      auditShape,
      drifts: {
        caseRows: caseRowDrifts,
        checkRows: checkRowDrifts
      }
    }, null, 2)
  );
}
const summary =
  `${audit.passed}/${audit.total} scenarios and ` +
  `${audit.passedChecks}/${audit.totalChecks} checks passed`;
const failedCases = audit.cases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
if (failedCases.length || !audit.ok ||
    audit.passed !== audit.total ||
    audit.passedChecks !== audit.totalChecks) {
  throw new Error(JSON.stringify({
    summary,
    errors: audit.errors,
    failedCases,
    shapeErrors,
    auditShape
  }, null, 2));
}

console.table(audit.cases.map((row) => ({
  scenario: row.scenario,
  diff: row.diffSize,
  cells: row.cells,
  hashes: row.hashes,
  factor: row.factor,
  initialPure: row.initialPure,
  peeled: row.peeled,
  residual: row.residual,
  messageKB: (row.bytesIblt / 1024).toFixed(1),
  listKB: (row.bytesLists / 1024).toFixed(1),
  checks: `${row.passedChecks}/${row.totalChecks}`,
  passed: row.passed
})));
console.log(summary);
NODE

Sizing Is the Algorithm

The lab’s Cells per diff slider is the important one.

Push it down toward 1.05x. Many runs stop with residual cells. The decoder is not confused; it has reached a 2-core. Every remaining key is entangled with other remaining keys, so no cell can testify alone.

Push it up. Pure cells appear, the peeling cascade starts, and the table lists the whole difference.

Goodrich and Mitzenmacher give 2-core threshold constants for several hash counts; for example, the table in their paper lists about 1.222 for k = 3, 1.295 for k = 4, and 1.425 for k = 5.³ Those are asymptotic thresholds under random-hypergraph assumptions, not a promise that a tiny browser demo with a 32-bit checksum should run exactly at the constant. In production, the sizing question belongs to a failure budget.

This is also why the number of hash locations is not monotone magic. Difference Digest notes the tradeoff directly: too few hashes do not propagate enough peeling information, while too many hashes can make it hard to find a pure cell at the start; values like 3 or 4 work well in practice.⁴

What This Toy Leaves Out

The lab assumes the difference size is known well enough to size the table. Difference Digest adds a Strata Estimator for that missing first step, because an IBLT that is too small may fail and an IBLT that is too large wastes bandwidth.¹

The lab also uses a short checksum. Real deployments choose checksum widths so that a false pure cell is negligible relative to the system’s risk budget. They also have to version the hash functions, salt them, serialize cell fields unambiguously, and decide what to do about duplicate keys, value changes, and malicious peers.

The conceptual invariant is still compact:

common keys cancel
single remaining keys reveal themselves
revealed keys delete themselves

An IBLT is not a smaller list. It is a table that can sometimes turn a set difference back into a list by finding enough places where only one key is left standing.

For a term in a search engine, the document IDs arrive sorted:

3, 4, 7, 13, 14, 15, 21, ...

The classical compression move is to store gaps:

3, 1, 3, 6, 1, 1, 6, ...

Small gaps get short codes. That is a good instinct. It is also a sequential instinct: to find the 10,000th posting or skip to the first posting at least x, the decoder often has to walk through earlier codes or auxiliary skip blocks.

Elias-Fano takes a different route. It treats the sorted list as a monotone sequence and stores the absolute values in two pieces:

low bits:  literal fixed-width suffixes
high bits: a unary bitmap with select support

The representation is not just a compressed byte stream. It is a compressed addressing scheme.

The construction is usually traced to Peter Elias’s work on static files and Robert Fano’s independent work on associative memory.¹

Split Each Value

Let the list contain \(n\) integers:

Pick:

Write each value as:

where \(l_i\) is the low \(\ell\)-bit suffix and \(h_i\) is the remaining high part.

The low parts are easy:

l_0, l_1, l_2, ...

stored in fixed width. This costs \(n\ell\) bits.

The high parts are monotone. Elias-Fano stores them by setting one bit per element in an upper bitmap:

H[h_i + i] = 1.

That + i is the little translation that keeps equal high parts from colliding. If several values share the same high part, their one-bits appear consecutively. Zeros in the bitmap mark high-part buckets with no value or with a boundary between groups.

To read the \(i\)th value, select the \(i\)th one-bit in H:

Then attach the stored low suffix:

That is the whole shape. The high bits are not decoded by replaying gaps. They are recovered by a select query.

The Space Bargain

The exact bit count in the lab is:

The first term is the low-bit array. The rest is the upper bitmap: one bit for each element plus enough zero slots to name the high buckets.

With the usual choice of \(\ell\), this is close to:

bits. Lucene’s Elias-Fano encoder documentation phrases the engineering bound as at most roughly 2 + ceil(log2(upperBound / numValues)) bits per encoded number, under its upper-bound convention.²

That is why the representation is attractive for sparse monotone lists. A raw fixed-width array spends \(\lceil \log_2 U \rceil\) bits per value. A bitset spends \(U\) bits whether the term appears in ten documents or ten million. Elias-Fano spends bits according to the average spacing.

The catch is density. If the list is very dense, a bitset can win. Vigna’s quasi-succinct index paper makes this engineering point explicitly by switching to ranked characteristic bitvectors for dense cases.³ Lucene’s docs make a similar practical comparison against fixed bitsets.²

So the right slogan is not “Elias-Fano beats bitsets.” It is:

Elias-Fano is a sparse monotone sequence layout with useful navigation baked in.

The Lab

The lab below builds deterministic synthetic posting lists, encodes them with Elias-Fano, and compares the bit budget against three baselines:

• fixed-width absolute document IDs;
• a full universe bitset;
• byte-aligned varint gaps; and
• the Elias-Fano split itself.

It also checks two operations:

• access(i), by decoding select1(i) - i plus the low bits; and
• nextGEQ(target), implemented here as a binary search over decoded access.

That nextGEQ implementation is intentionally simple. Production structures avoid decoding one item at a time by adding rank/select samples, broadword search, and skip pointers. The point of the artifact is to expose the invariant, not to pretend a few dozen lines of JavaScript is a tuned search engine.

The lab has a built-in audit. It reports 35 named checks: decode, monotonicity, high-bit placement, one-bit count, direct access, nextGEQ, and target-sweep lower bounds across five scenarios:

node - <<'NODE'
const lab = require("./assets/js/elias-fano-lab.js");
const EXPECTED_CASE_KEYS = [
  "1:default-clustered:100000:900:6",
  "2:uniform:4096:64:6",
  "3:clustered:100000:1500:6",
  "4:dense:2048:1200:0",
  "5:runs:250000:2200:6"
];
const EXPECTED_CASE_ROWS = [
  "1:default-clustered:100000:900:l=6:ef=8.74:varbyte=10.57:target=true:checks=7/7:passed=true",
  "2:uniform:4096:64:l=6:ef=8.00:varbyte=8.00:target=true:checks=7/7:passed=true",
  "3:clustered:100000:1500:l=6:ef=8.04:varbyte=9.02:target=true:checks=7/7:passed=true",
  "4:dense:2048:1200:l=0:ef=2.71:varbyte=8.01:target=true:checks=7/7:passed=true",
  "5:runs:250000:2200:l=6:ef=8.78:varbyte=8.35:target=true:checks=7/7:passed=true"
];
const EXPECTED_CHECK_SHAPE = [
  { name: "decode", ok: true },
  { name: "monotone-input", ok: true },
  { name: "high-bit-positions", ok: true },
  { name: "one-bit-count", ok: true },
  { name: "access-query", ok: true },
  { name: "next-geq-query", ok: true },
  { name: "target-sweep", ok: true }
];
const EXPECTED_CASES = EXPECTED_CASE_KEYS.length;
const EXPECTED_CHECKS = EXPECTED_CASES * EXPECTED_CHECK_SHAPE.length;

function sameList(left, right) {
  return left.length === right.length &&
    left.every((value, index) => value === right[index]);
}

function sameJson(left, right) {
  return JSON.stringify(left) === JSON.stringify(right);
}

function rowDrifts(actual, expected) {
  const count = Math.max(actual.length, expected.length);
  const drift = [];
  for (let index = 0; index < count; index += 1) {
    if (actual[index] !== expected[index]) {
      drift.push({ index, actual: actual[index], expected: expected[index] });
    }
  }
  return drift;
}

function auditShape(audit) {
  return {
    cases: audit.cases.map(
      (row) => `${row.caseId}:${row.scenario}:${row.universe}:${row.count}:${row.l}`
    ),
    caseRows: audit.cases.map(
      (row) => `${row.caseId}:${row.scenario}:${row.universe}:${row.count}:` +
        `l=${row.l}:ef=${row.bitsPerValue.toFixed(2)}:` +
        `varbyte=${row.varbyteBitsPerValue.toFixed(2)}:` +
        `target=${row.targetOk}:checks=${row.passedChecks}/${row.totalChecks}:` +
        `passed=${row.passed}`
    ),
    checksByCase: audit.cases.map((row) =>
      row.checks.map((check) => ({
        name: check.name,
        ok: check.ok
      }))
    )
  };
}

const audit = lab.auditEliasFanoLab();
const shape = auditShape(audit);
const failed = audit.cases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
const caseRowDrifts = rowDrifts(shape.caseRows, EXPECTED_CASE_ROWS);
const shapeErrors = [
  sameList(shape.cases, EXPECTED_CASE_KEYS) ? null : "cases",
  caseRowDrifts.length ? "caseRows" : null,
  shape.checksByCase.every((checks) => sameJson(checks, EXPECTED_CHECK_SHAPE))
    ? null
    : "checksByCase"
].filter(Boolean);
console.table(audit.cases.map((row) => ({
  scenario: row.scenario,
  universe: row.universe,
  count: row.count,
  l: row.l,
  efBitsPerValue: row.bitsPerValue.toFixed(2),
  varbyteBitsPerValue: row.varbyteBitsPerValue.toFixed(2),
  checks: `${row.passedChecks}/${row.totalChecks}`,
  targetOk: row.targetOk,
  passed: row.passed
})));
const summary =
  `${audit.passed}/${audit.total} scenarios and ` +
  `${audit.passedChecks}/${audit.totalChecks} checks passed`;
if (
  shapeErrors.length ||
  audit.total !== EXPECTED_CASES ||
  audit.totalChecks !== EXPECTED_CHECKS ||
  failed.length ||
  !audit.ok ||
  audit.passed !== audit.total ||
  audit.passedChecks !== audit.totalChecks
) {
  throw new Error(JSON.stringify({
    summary,
    shapeErrors,
    shape,
    drifts: { caseRows: caseRowDrifts },
    failed,
    errors: audit.errors,
    expectedCases: EXPECTED_CASES,
    expectedChecks: EXPECTED_CHECKS,
    total: audit.total,
    totalChecks: audit.totalChecks
  }, null, 2));
}
console.log(summary);
NODE

The checks cover uniform, clustered, dense, and run-heavy lists. They assert that:

• decoding every index reproduces the original sorted list;
• every one-bit is at position high(x[i]) + i;
• the number of one-bits equals the number of postings;
• access(i) agrees with the original list; and
• nextGEQ(target) agrees with a naive lower-bound scan.

Why This Is Useful for Search

Vigna’s quasi-succinct index paper begins with a contrast against ordinary gap-compressed inverted indexes: document pointers are stored in increasing order, and gap compression gives small gaps short codes, but the proposed index uses a quasi-succinct representation of monotone sequences instead.³

That change matters because query engines do not only enumerate postings. They also skip. A conjunctive query needs to keep several posting lists aligned:

advance the shorter list to at least the current document of the longer list

If the compressed representation supports access and nextGEQ cheaply, the index can stay compressed while still behaving like an addressable object.

This is the reason Elias-Fano keeps reappearing in search systems, graph compression, and succinct libraries. The high bitmap is not decorative. It is where the navigation lives.

What This Toy Does Not Include

The JavaScript lab stores the select1 positions explicitly. That would be wasteful in a real compressed index. Production implementations store sampled rank/select support, use word-level bit tricks, and often add skip pointers. Vigna describes longword addressing and broadword bit search as key engineering pieces for query speed.³

The lab also encodes one list at a time. Modern variants exploit clustering and partitioning. Ottaviano and Venturini’s partitioned Elias-Fano work describes a two-level representation that improves the compression/time tradeoff, especially when posting lists have locally clustered regions.⁴ Pibiri and Venturini later show that clustering related posting lists can reduce redundancy across lists, while still building on Elias-Fano representations of monotone sequences.⁵

Those refinements do not change the core picture:

low bits carry local offsets
high bits carry a selectable map

Once you see that split, Elias-Fano stops looking like just another integer codec. It is a way to store a sorted list so that the compressed form still has addresses.

The boring version has a sharp memory cliff. An 8-bit counter stops at 255. If you need many counters and only have bytes, the obvious repair is to give every counter more bytes. Robert Morris’s 1978 note starts from exactly that kind of machine constraint: many event counters, byte-sized storage, and no room for 16-bit counters.¹

Morris’s trick is to stop storing the count. Store something closer to its logarithm, and increment that stored value only sometimes.

For a base \(b > 1\), keep an integer register \(X\). On each event:

with probability b^(-X): X <- X + 1
otherwise:               X stays fixed

Decode the register as:

When \(X=0\), the estimate is 0. When \(X=1\), the estimate is 1. Later, the steps get wider. The counter has become a staircase with random landing times.

The surprising part is not that this compresses the count. The surprising part is that the decoded value is unbiased:

The counter forgot the exact path, but in expectation it kept the total.

The One-Line Martingale

Suppose the register currently has value \(X\). Define

After the next event, \(X\) increments with probability \(b^{-X}\). The expected next decoded value is:

That is the whole conservation law. Each real event adds one unit to the expected decoded estimate. Starting from zero, after \(N\) events the decoded estimate has expectation \(N\).

Morris used a parameter \(a\) rather than the base directly:

This version has variance:

So for large \(N\), the relative standard deviation is approximately:

That relative-error scale is almost independent of the count. It is paid for with range. In a fixed-width register, larger \(a\) means a base closer to one, smaller jumps, lower variance, and a smaller maximum decodable count.

Morris’s example used 8-bit counters with \(a=30\). The largest decodable count is about:

His paper reports the same order of magnitude, “about 130,000”, with a relative error around a quarter at 95% confidence under the normal approximation.¹

The Lab

The lab below simulates Morris counters directly. It uses a geometric waiting time for the next successful register increment, which is equivalent to processing events one at a time but much faster when the register is already large.

The controls expose the main engineering tradeoffs:

• true events is the real stream length;
• precision a is Morris’s parameter;
• register bits fixes the largest stored exponent;
• trials repeats the experiment to show the sampling distribution; and
• replicas averages independent counters, lowering variance by the usual factor of the number of replicas.

The artifact includes exact checks for small counts and seeded Monte Carlo checks for larger counts: 10 audit cases and 24 named checks.

node - <<'NODE'
const lab = require("./assets/js/morris-counter-lab.js");
const EXPECTED_EXACT_ROWS = 6;
const EXPECTED_SCENARIO_ROWS = 4;
const EXPECTED_ROWS = 10;
const EXPECTED_CHECKS = 24;
const EXPECTED_EXACT_EVENTS = [0, 1, 2, 8, 35, 60];
const EXPECTED_SCENARIO_EVENTS = [1000, 40000, 80000, 160000];
const EXPECTED_EXACT_CHECK_NAMES = [
  "exact expectation equals count",
  "exact variance matches formula"
];
const EXPECTED_SCENARIO_CHECK_NAMES = [
  "empirical mean is inside standard-error envelope",
  "saturation is either absent or explicitly near capacity",
  "seeded replay is deterministic"
];
const EXPECTED_TOTALS = {
  exactRows: EXPECTED_EXACT_ROWS,
  scenarioRows: EXPECTED_SCENARIO_ROWS,
  passed: EXPECTED_ROWS,
  total: EXPECTED_ROWS,
  passedChecks: EXPECTED_CHECKS,
  totalChecks: EXPECTED_CHECKS
};
const EXPECTED_EXACT_SHAPE = [
  "0:meanOk=true:varianceOk=true:checks=2/2",
  "1:meanOk=true:varianceOk=true:checks=2/2",
  "2:meanOk=true:varianceOk=true:checks=2/2",
  "8:meanOk=true:varianceOk=true:checks=2/2",
  "35:meanOk=true:varianceOk=true:checks=2/2",
  "60:meanOk=true:varianceOk=true:checks=2/2"
];
const EXPECTED_SCENARIO_SHAPE = [
  "80000:theoretical=80000:observed=80174.089:saturated=0:deterministic=true:meanOk=true:noBadSaturation=true:checks=3/3",
  "1000:theoretical=1000:observed=996.258:saturated=0:deterministic=true:meanOk=true:noBadSaturation=true:checks=3/3",
  "40000:theoretical=40000:observed=40013.436:saturated=0:deterministic=true:meanOk=true:noBadSaturation=true:checks=3/3",
  "160000:theoretical=160000:observed=159830.740:saturated=0:deterministic=true:meanOk=true:noBadSaturation=true:checks=3/3"
];
const EXPECTED_CHECK_SHAPE = [
  "exact:0:exact expectation equals count:true",
  "exact:0:exact variance matches formula:true",
  "exact:1:exact expectation equals count:true",
  "exact:1:exact variance matches formula:true",
  "exact:2:exact expectation equals count:true",
  "exact:2:exact variance matches formula:true",
  "exact:8:exact expectation equals count:true",
  "exact:8:exact variance matches formula:true",
  "exact:35:exact expectation equals count:true",
  "exact:35:exact variance matches formula:true",
  "exact:60:exact expectation equals count:true",
  "exact:60:exact variance matches formula:true",
  "scenario:80000:seeded replay is deterministic:true",
  "scenario:80000:empirical mean is inside standard-error envelope:true",
  "scenario:80000:saturation is either absent or explicitly near capacity:true",
  "scenario:1000:seeded replay is deterministic:true",
  "scenario:1000:empirical mean is inside standard-error envelope:true",
  "scenario:1000:saturation is either absent or explicitly near capacity:true",
  "scenario:40000:seeded replay is deterministic:true",
  "scenario:40000:empirical mean is inside standard-error envelope:true",
  "scenario:40000:saturation is either absent or explicitly near capacity:true",
  "scenario:160000:seeded replay is deterministic:true",
  "scenario:160000:empirical mean is inside standard-error envelope:true",
  "scenario:160000:saturation is either absent or explicitly near capacity:true"
];

function sameList(actual, expected) {
  return actual.length === expected.length &&
    actual.every((value, index) => value === expected[index]);
}

function sameJson(actual, expected) {
  return JSON.stringify(actual) === JSON.stringify(expected);
}

function exactShape(row) {
  return `${row.events}:meanOk=${row.meanOk}:varianceOk=${row.varianceOk}:` +
    `checks=${row.passedChecks}/${row.totalChecks}`;
}

function scenarioShape(row) {
  return `${row.events}:theoretical=${row.theoreticalMean}:` +
    `observed=${row.observedMean.toFixed(3)}:saturated=${row.saturatedTrials}:` +
    `deterministic=${row.deterministic}:meanOk=${row.meanOk}:` +
    `noBadSaturation=${row.noBadSaturation}:` +
    `checks=${row.passedChecks}/${row.totalChecks}`;
}

function checkShape(row, kind) {
  return row.checks.map((check) => `${kind}:${row.events}:${check.name}:${check.passed}`);
}

const audit = lab.auditMorrisCounterLab();
console.table(audit.exact.map((row) => ({
  events: row.events,
  meanOk: row.meanOk,
  varianceOk: row.varianceOk,
  checks: `${row.passedChecks}/${row.totalChecks}`
})));
console.table(audit.scenarios.map((row) => ({
  events: row.events,
  theoretical: row.theoreticalMean,
  observed: row.observedMean.toFixed(1),
  saturatedTrials: row.saturatedTrials,
  deterministic: row.deterministic,
  checks: `${row.passedChecks}/${row.totalChecks}`
})));
const auditShape = {
  totals: {
    exactRows: audit.exact.length,
    scenarioRows: audit.scenarios.length,
    passed: audit.passed,
    total: audit.total,
    passedChecks: audit.passedChecks,
    totalChecks: audit.totalChecks
  },
  exactCheckNames: Array.from(new Set(audit.exact.flatMap(
    (row) => row.checks.map((check) => check.name)
  ))).sort(),
  exactEvents: audit.exact.map((row) => row.events).sort((a, b) => a - b),
  exactShape: audit.exact.map(exactShape),
  scenarioCheckNames: Array.from(new Set(audit.scenarios.flatMap(
    (row) => row.checks.map((check) => check.name)
  ))).sort(),
  scenarioEvents: audit.scenarios.map((row) => row.events).sort((a, b) => a - b),
  scenarioShape: audit.scenarios.map(scenarioShape),
  checkShape: audit.exact.flatMap((row) => checkShape(row, "exact"))
    .concat(audit.scenarios.flatMap((row) => checkShape(row, "scenario")))
};
const shapeErrors = [
  sameJson(auditShape.totals, EXPECTED_TOTALS) ? null : "totals",
  sameJson(auditShape.exactEvents, EXPECTED_EXACT_EVENTS) ? null : "exactEvents",
  sameJson(auditShape.scenarioEvents, EXPECTED_SCENARIO_EVENTS) ? null : "scenarioEvents",
  sameJson(auditShape.exactCheckNames, EXPECTED_EXACT_CHECK_NAMES) ? null : "exactCheckNames",
  sameJson(auditShape.scenarioCheckNames, EXPECTED_SCENARIO_CHECK_NAMES)
    ? null
    : "scenarioCheckNames",
  sameList(auditShape.exactShape, EXPECTED_EXACT_SHAPE) ? null : "exactShape",
  sameList(auditShape.scenarioShape, EXPECTED_SCENARIO_SHAPE) ? null : "scenarioShape",
  sameList(auditShape.checkShape, EXPECTED_CHECK_SHAPE) ? null : "checkShape"
].filter(Boolean);
if (shapeErrors.length) {
  throw new Error(
    `audit shape drifted in ${shapeErrors.join(", ")}:\n` +
    JSON.stringify(auditShape, null, 2)
  );
}

const failedExactCases = audit.exact.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
const failedScenarioCases = audit.scenarios.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
if (!audit.ok || failedExactCases.length || failedScenarioCases.length ||
    audit.passed !== audit.total ||
    audit.passedChecks !== audit.totalChecks) {
  throw new Error(JSON.stringify({
    failures: audit.failures,
    failedExactCases,
    failedScenarioCases,
    shapeErrors,
    auditShape
  }, null, 2));
}
console.log(
  `${audit.passed}/${audit.total} audit cases and ` +
  `${audit.passedChecks}/${audit.totalChecks} checks passed`
);
NODE

Those named checks verify:

• the dynamic-programmed expectation matches the true count for small \(N\);
• the dynamic-programmed variance matches \(N(N-1)/(2a)\);
• the jump simulation is deterministic under a fixed seed;
• empirical means land within a standard-error envelope around the true count; and
• register saturation is flagged rather than silently folded into the unbiasedness claim.

The Register Has a Ceiling

The formula is unbiased only before the register saturates. If the register hits its maximum value, the implementation cannot keep taking logarithmic steps. It clips.

That is not a theoretical nuisance. It is the systems bargain.

For \(r\) register bits, the largest stored value is \(2^r - 1\). With Morris’s parameter \(a\), the largest decoded count is:

For fixed \(r\):

• lowering \(a\) increases the range but increases relative noise;
• raising \(a\) lowers relative noise but shortens the range; and
• averaging independent counters lowers noise but spends multiple registers.

This is why the lab has both a “max decoded” metric and a “saturated trials” metric. A run can look stable because the counter stopped moving. That is not a successful approximation.

A Tiny Counter Is Not a Tiny Truth

Morris’s counter is sometimes described as using \(O(\log \log N)\) bits. That is the memory headline, and it is real: the register value tracks a logarithm of the count, so the number of bits needed to store that register grows like the logarithm of a logarithm.²

The headline hides the variance bill.

For the base-2 version, where \(a=1\),

The relative standard deviation is about 70%. That is not a dashboard counter. It is a tiny, unbiased, very noisy sketch.

The parameterized version matters because it lets a system decide how much of that noise to buy down. In the lab default, \(a=30\) gives a theoretical relative standard deviation near 13%. Averaging four independent counters cuts that in half, but uses four registers. Raising \(a\) also lowers variance, but the 8-bit range falls quickly.

Nelson and Yu’s later work is useful perspective here: approximate counting is not just a historical curiosity but a clean problem about the best possible memory/error/failure-probability tradeoff.³ One way to improve accuracy is to average many Morris counters; another is to change the base. Those choices can have different space consequences even when they look similar from the variance formula alone.

Where This Belongs

A Morris counter is a good fit when:

• many counters are needed;
• each counter only needs approximate statistical weight;
• relative error is acceptable;
• the maximum representable count has been budgeted; and
• the downstream consumer understands that the estimate is noisy.

It is a poor fit when:

• exact thresholds matter;
• low counts need exact treatment beyond the first event;
• saturation would be operationally invisible;
• adversarial manipulation of randomized counters is in scope; or
• the system needs to subtract, merge, or audit individual event identities.

The counter is elegant because it does one thing cleanly:

spend randomness so a small exponent can stand in for a large count

That is not the same as remembering the count. It is remembering just enough of the logarithm that the expectation comes out right.

The hard part is not counting. It is naming. A Count-Min Sketch can answer “how many times did this key appear?” for a key you already know how to ask about, but it does not remember the keys themselves. Heavy-hitter detection has a different shape: after a stream has passed, the algorithm must say which items were common.

Space-Saving is one of the cleanest counter-based answers to that problem. It keeps a small table of named items. When a new unmonitored item arrives and the table is full, it evicts the item with the smallest stored count. The newcomer inherits that count as blame for the past.

That little inheritance rule is the whole trick.

if x is monitored:
  count[x] += 1
else if an empty counter exists:
  monitor x with count = 1 and error = 0
else:
  let y be an item with minimum stored count m
  stop monitoring y
  monitor x with count = m + 1 and error = m

The stored count is not presented as truth. It is a receipt:

true count of x lies in [count[x] - error[x], count[x]]

The right endpoint is the optimistic estimate. The left endpoint is the part that survived the audit.

The Minimum Counter Is a Certificate Boundary

Let the table have \(k\) counters. After \(n\) stream updates, the sum of all stored counts is exactly \(n\), because every event increments exactly one counter. Therefore the current minimum counter \(m_{\min}\) is at most \(n/k\).

Space-Saving’s more interesting invariant is about names:

any item whose true frequency is greater than the current minimum counter
must be monitored

The invariant is easy to miss because evictions look destructive. The destruction is tracked.

If an item is monitored with stored count \(c\) and stored error \(e\), then its true count \(f\) is bounded by:

The upper bound exists because every stored count may include mass from earlier items that occupied the same counter. The lower bound exists because error = m records exactly how much prehistory the newcomer inherited at its most recent insertion. Future arrivals of the same item increment the counter honestly.

For an unmonitored item \(z\), the invariant says:

Sketch of the induction:

• Before the table fills, unmonitored items have frequency zero.
• If an unmonitored item arrives while the table is full, it immediately becomes monitored.
• If a monitored item is evicted, it was sitting in a minimum counter, so its true count was no larger than that counter. The global minimum counter never decreases after the replacement.

So the minimum counter is not just an implementation detail. It is the boundary between “could still be hiding” and “must have a named counter.”

That boundary gives the threshold rule:

if the heavy-hitter threshold phi n is greater than m_min,
then Space-Saving has no false negatives above that threshold.

False positives are still possible if you report by the upper count. The stored lower bound separates those cases:

count[x] >= threshold          -> candidate
count[x] - error[x] >= threshold -> certified heavy hitter

That difference is where the algorithm stops being a vibe and becomes an auditable data structure.

The Lab

The lab below generates a deterministic Zipf-like stream with optional drift, runs Space-Saving, and compares the summary against the exact frequency table. The exact table is used only for the audit and visualization.

The panels show:

• exact top items, with monitored items ringed;
• stored counters as intervals [count - error, count];
• threshold candidates, guaranteed hits, and misses; and
• one exact-rank query interpreted through the Space-Saving receipt.

The default setting uses 64 counters for 50,000 events. The threshold is 1.2% of the stream, which is above the current minimum counter in the generated run. That makes the no-miss certificate visible on first load.

The audit is part of the artifact, not just a visual sanity check:

node - <<'NODE'
const lab = require("./assets/js/space-saving-lab.js");
const EXPECTED_SCENARIO_ROWS = 5;
const EXPECTED_REPLAY_ROWS = 1;
const EXPECTED_ROWS = 6;
const EXPECTED_CHECKS = 36;
const EXPECTED_SCENARIO_CHECK_NAMES = [
  "counter-total",
  "guaranteed-threshold",
  "minimum-n-over-k",
  "monitored-intervals",
  "threshold-no-miss",
  "top-k-range",
  "unmonitored-min-bound"
];
const EXPECTED_REPLAY_CHECK_NAMES = ["fixed-seed-replay"];
const EXPECTED_CASE_SHAPE = [
  "default:7:50000:2000:64:600:10:15:1",
  "fixed-seed-replay:1:50000:2000:64:600:10:15:1",
  "stress-1:7:5000:100:8:100:0:8:0",
  "stress-2:7:120000:8000:160:240:38:39:1",
  "stress-3:7:25000:500:24:300:11:24:0",
  "stress-4:7:70000:2500:48:560:17:48:0"
];
const EXPECTED_CASE_ROWS = [
  "default:checks=7/7:passed=true:events=50000:vocab=2000:counters=64:min=592:threshold=600:trueHeavy=10:reported=15:noMiss=true",
  "fixed-seed-replay:checks=1/1:passed=true:events=50000:vocab=2000:counters=64:min=592:threshold=600:trueHeavy=10:reported=15:noMiss=true",
  "stress-1:checks=7/7:passed=true:events=5000:vocab=100:counters=8:min=624:threshold=100:trueHeavy=0:reported=8:noMiss=false",
  "stress-2:checks=7/7:passed=true:events=120000:vocab=8000:counters=160:min=93:threshold=240:trueHeavy=38:reported=39:noMiss=true",
  "stress-3:checks=7/7:passed=true:events=25000:vocab=500:counters=24:min=973:threshold=300:trueHeavy=11:reported=24:noMiss=false",
  "stress-4:checks=7/7:passed=true:events=70000:vocab=2500:counters=48:min=864:threshold=560:trueHeavy=17:reported=48:noMiss=false"
];
const EXPECTED_CHECK_ROWS = [
  "default:counter-total=true|monitored-intervals=true|unmonitored-min-bound=true|threshold-no-miss=true|guaranteed-threshold=true|minimum-n-over-k=true|top-k-range=true",
  "fixed-seed-replay:fixed-seed-replay=true",
  "stress-1:counter-total=true|monitored-intervals=true|unmonitored-min-bound=true|threshold-no-miss=true|guaranteed-threshold=true|minimum-n-over-k=true|top-k-range=true",
  "stress-2:counter-total=true|monitored-intervals=true|unmonitored-min-bound=true|threshold-no-miss=true|guaranteed-threshold=true|minimum-n-over-k=true|top-k-range=true",
  "stress-3:counter-total=true|monitored-intervals=true|unmonitored-min-bound=true|threshold-no-miss=true|guaranteed-threshold=true|minimum-n-over-k=true|top-k-range=true",
  "stress-4:counter-total=true|monitored-intervals=true|unmonitored-min-bound=true|threshold-no-miss=true|guaranteed-threshold=true|minimum-n-over-k=true|top-k-range=true"
];
const EXPECTED_TOTALS = {
  scenarioRows: EXPECTED_SCENARIO_ROWS,
  replayRows: EXPECTED_REPLAY_ROWS,
  passed: EXPECTED_ROWS,
  total: EXPECTED_ROWS,
  passedChecks: EXPECTED_CHECKS,
  totalChecks: EXPECTED_CHECKS
};

function sameJson(actual, expected) {
  return JSON.stringify(actual) === JSON.stringify(expected);
}

function rowDrifts(actual, expected) {
  const count = Math.max(actual.length, expected.length);
  const drift = [];
  for (let index = 0; index < count; index += 1) {
    if (actual[index] !== expected[index]) {
      drift.push({ index, actual: actual[index], expected: expected[index] });
    }
  }
  return drift;
}

const audit = lab.auditSpaceSavingLab();
console.table(audit.cases.map((row) => ({
  scenario: row.scenario,
  events: row.events,
  vocabulary: row.vocabulary,
  counters: row.counters,
  minCount: row.minCount,
  threshold: row.thresholdCount,
  trueHeavy: row.trueHeavy,
  reported: row.reported,
  noMiss: row.noMissCondition,
  checks: `${row.passedChecks}/${row.totalChecks}`
})));
const scenarioRows = audit.cases.filter((row) => row.scenario !== "fixed-seed-replay");
const replayRows = audit.cases.filter((row) => row.scenario === "fixed-seed-replay");
const auditShape = {
  totals: {
    scenarioRows: scenarioRows.length,
    replayRows: replayRows.length,
    passed: audit.passed,
    total: audit.total,
    passedChecks: audit.passedChecks,
    totalChecks: audit.totalChecks
  },
  caseChecks: audit.cases.map((row) => [
    row.scenario,
    row.totalChecks,
    row.events,
    row.vocabulary,
    row.counters,
    row.thresholdCount,
    row.trueHeavy,
    row.reported,
    row.noMissCondition ? 1 : 0
  ].join(":")).sort(),
  caseRows: audit.cases.map((row) =>
    `${row.scenario}:checks=${row.passedChecks}/${row.totalChecks}:` +
    `passed=${row.passed}:events=${row.events}:vocab=${row.vocabulary}:` +
    `counters=${row.counters}:min=${row.minCount}:` +
    `threshold=${row.thresholdCount}:trueHeavy=${row.trueHeavy}:` +
    `reported=${row.reported}:noMiss=${row.noMissCondition}`
  ).sort(),
  checkRows: audit.cases.map((row) =>
    `${row.scenario}:` +
    row.checks.map((check) => `${check.name}=${check.passed}`).join("|")
  ).sort(),
  replayCheckNames: Array.from(new Set(replayRows.flatMap(
    (row) => row.checks.map((check) => check.name)
  ))).sort(),
  scenarioCheckNames: Array.from(new Set(scenarioRows.flatMap(
    (row) => row.checks.map((check) => check.name)
  ))).sort()
};
const caseRowDrifts = rowDrifts(auditShape.caseRows, EXPECTED_CASE_ROWS);
const checkRowDrifts = rowDrifts(auditShape.checkRows, EXPECTED_CHECK_ROWS);
const shapeErrors = [
  sameJson(auditShape.totals, EXPECTED_TOTALS) ? null : "totals",
  sameJson(auditShape.caseChecks, EXPECTED_CASE_SHAPE) ? null : "caseChecks",
  caseRowDrifts.length ? "caseRows" : null,
  checkRowDrifts.length ? "checkRows" : null,
  sameJson(auditShape.scenarioCheckNames, EXPECTED_SCENARIO_CHECK_NAMES)
    ? null
    : "scenarioCheckNames",
  sameJson(auditShape.replayCheckNames, EXPECTED_REPLAY_CHECK_NAMES)
    ? null
    : "replayCheckNames"
].filter(Boolean);
if (shapeErrors.length) {
  throw new Error(
    `audit shape drifted in ${shapeErrors.join(", ")}:\n` +
    JSON.stringify({
      auditShape,
      drifts: {
        caseRows: caseRowDrifts,
        checkRows: checkRowDrifts
      }
    }, null, 2)
  );
}

const failedCases = audit.cases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
if (!audit.ok || failedCases.length ||
    audit.passed !== audit.total ||
    audit.passedChecks !== audit.totalChecks) {
  throw new Error(JSON.stringify({
    failures: audit.failures,
    failedCases,
    shapeErrors,
    auditShape
  }, null, 2));
}
console.log(
  `${audit.passed}/${audit.total} audit scenarios and ` +
  `${audit.passedChecks}/${audit.totalChecks} checks passed`
);
NODE

The 36 named checks cover five parameter settings plus a fixed-seed replay. They assert that:

• the sum of stored counters equals the stream length;
• every monitored item’s exact count lies in its stored interval;
• every unmonitored item’s exact count is at most the current minimum counter;
• when the threshold is above the minimum counter, no true heavy hitter is unmonitored;
• any item whose lower bound crosses the threshold is truly above threshold;
• the top-k precision/recall summaries stay in probability range; and
• the implementation is deterministic for a fixed seed.

Why This Is Not Just Misra-Gries With Different Labels

Misra and Gries gave the older and beautifully terse repeated-elements algorithm: keep at most \(k-1\) candidates; if a new item arrives and no empty counter exists, decrement all counters and delete zeros.¹ It is a deletion ledger. Each global decrement cancels a group of distinct items.

Space-Saving uses a different ledger. It never decrements all counters. It replaces the minimum counter and records that minimum as the new item’s error. Metwally, Agrawal, and El Abbadi presented this as an integrated algorithm for frequent items and top-\(k\) queries in data streams.² Their analysis gives the interval and rank-style properties the lab is exercising.

Both algorithms are deterministic and both are about the same bottleneck: the stream has more possible names than the memory budget. But they leave different receipts. Misra-Gries is especially clean for proving that all items above \(n/k\) remain candidates. Space-Saving is especially convenient when the table itself needs to rank candidates online by stored counts and carry item-level error bounds.

Cormode and Hadjieleftheriou’s survey-style experimental comparison is useful here because it evaluates frequent-item algorithms under shared conditions rather than treating each sketch in isolation.³ Their concise description of Space-Saving matches the implementation above: keep item-count pairs, increment a monitored item, otherwise replace the smallest counter with the new item and increment it.

Reading a Space-Saving Table in Production

The most common mistake is to treat count as exact.

It is safer to expose three views:

That third row is the one that feels least natural at first. The algorithm can say something useful about keys it is not storing. It cannot name them, but it can bound them.

This also explains the table-size rule of thumb. Since \(m_{\min} \le n/k\), any threshold above \(n/k\) is protected from false negatives. If the product question is “show me everything above 1% of traffic,” then a table with a little more than 100 counters puts the minimum-counter certificate in the right range. More counters reduce candidate ambiguity; they do not make the upper counts exact.

What the Lab Does Not Claim

The implementation is deliberately simple. It scans the counter array to find the minimum, so each update costs \(O(k)\). That is fine for a visible browser experiment with at most 160 counters. A production implementation usually keeps counters in a heap or a stream-summary structure so the minimum can be found and updated efficiently.

The stream generator is synthetic. It uses a Zipf-like distribution and an optional midstream item shift to create churn. This is good for exercising the invariants, but it is not a benchmark for cache behavior, adversarial keys, distributed merging, sliding windows, deletions, or weighted updates.

The deterministic guarantee is also narrower than a product guarantee. The data structure can certify threshold coverage relative to its processed stream. It cannot decide whether the stream is the right measurement of user behavior, whether bot traffic was filtered correctly, whether a delayed pipeline double counted events, or whether the dashboard threshold is the right operational decision.

Space-Saving earns its place because the internal contract is crisp:

small memory, named candidates, explicit error receipts

That is often exactly the contract a streaming system needs.

Give it a small rank directory and it can answer:

rank1(B, i) = number of 1 bits in B[0..i)

Add select support and it can also answer:

select1(B, k) = position of the k-th 1 bit

That is enough for binary strings. The wavelet tree asks what happens when the sequence is not binary.

The trick is to refuse the large alphabet at the top level. Split the alphabet in two. Write 0 for symbols in the left half and 1 for symbols in the right half. Then recursively build the same structure on the two stable subsequences. After \(\lceil \log_2 \sigma \rceil\) levels, a symbol has been identified by a path of binary decisions.

This is not just a cute encoding. It is a query plan.

The Stored Object

Let \(S[0,n)\) be a static sequence over alphabet \(\Sigma\). A balanced wavelet tree node owns a subalphabet \(A\) and the subsequence of \(S\) whose symbols are in \(A\).

If \(A\) contains more than one symbol, split it into \(A_0\) and \(A_1\). Store a bitvector \(B_v\):

The left child receives the symbols of \(S_v\) in \(A_0\), in the same order. The right child receives the symbols in \(A_1\), also in the same order. That stable partition is the invariant. It is why positions can be translated from a parent bitmap to a child bitmap with rank.

Grossi, Gupta, and Vitter introduced wavelet trees inside their 2003 work on high-order entropy-compressed text indexes.¹ Navarro’s survey is a good map of the structure after it escaped that original setting: it can be viewed as a sequence representation, a permutation/reordering device, or a grid of points.²

The small version in this post is the sequence view.

Three Primitive Moves

For access(i), start at the root. Read the bit at position i.

bit 0: i <- rank0(B, i), go left
bit 1: i <- rank1(B, i), go right

When the descent reaches a leaf, that leaf’s symbol is S[i].

For rank(c, i), follow the path that would lead to symbol c. At every node, translate the prefix length:

c in left half:  i <- rank0(B, i)
c in right half: i <- rank1(B, i)

At the leaf, the remaining i is the number of occurrences of c in the original prefix.

For select(c, k), do the inverse. Start at the leaf for c, where the k-th copy has local position k - 1. Walk upward. If this leaf was reached through a left edge, ask the parent bitmap for the position of the corresponding zero; if it was reached through a right edge, ask for the corresponding one.

left edge:  parent_pos <- select0(B, child_pos + 1)
right edge: parent_pos <- select1(B, child_pos + 1)

Claude and Navarro’s practical study is a useful reminder that this elegant story lives or dies on the engineering of rank/select over the node bitvectors.³ The lab here uses visible prefix arrays, not a compressed RRR or broadword implementation, so the accounting is explanatory rather than competitive.

Range Quantile Is The Same Descent

Now ask a different question:

what is the k-th smallest symbol in S[l..r)?

At a node, count how many active range items go left:

If \(k \le z\), the answer is in the left child. Translate the range to:

l <- rank0(B, l)
r <- rank0(B, r)

Otherwise, the answer is in the right child. Subtract the left count and translate with rank1:

k <- k - z
l <- rank1(B, l)
r <- rank1(B, r)

Repeat until a leaf. Gagie, Puglisi, and Turpin used this observation to support range quantile queries, including medians as the special case where k is the middle rank, in \(O(\log \sigma)\) time using a balanced wavelet tree.⁴

The implementation below checks that descent against naive sorting for every slice of each built-in sequence.

What The Lab Audits

The module exports the same implementation used by the browser:

node - <<'NODE'
const lab = require("./assets/js/wavelet-tree-lab.js");
const EXPECTED_CASE_SHAPE = [
  "1:genome:all:24/5:58:24/125/24/2600:7",
  "2:genome:#:24/5:58:24/125/24/2600:7",
  "3:genome:A:24/5:58:24/125/24/2600:7",
  "4:genome:C:24/5:58:24/125/24/2600:7",
  "5:genome:G:24/5:58:24/125/24/2600:7",
  "6:genome:T:24/5:58:24/125/24/2600:7",
  "7:mississippi:all:12/5:29:12/65/12/364:7",
  "8:mississippi:#:12/5:29:12/65/12/364:7",
  "9:mississippi:i:12/5:29:12/65/12/364:7",
  "10:mississippi:m:12/5:29:12/65/12/364:7",
  "11:mississippi:p:12/5:29:12/65/12/364:7",
  "12:mississippi:s:12/5:29:12/65/12/364:7",
  "13:abracadabra:all:12/6:32:12/78/12/364:7",
  "14:abracadabra:#:12/6:32:12/78/12/364:7",
  "15:abracadabra:a:12/6:32:12/78/12/364:7",
  "16:abracadabra:b:12/6:32:12/78/12/364:7",
  "17:abracadabra:c:12/6:32:12/78/12/364:7",
  "18:abracadabra:d:12/6:32:12/78/12/364:7",
  "19:abracadabra:r:12/6:32:12/78/12/364:7",
  "20:prices:all:20/10:67:20/210/20/1540:7",
  "21:prices:0:20/10:67:20/210/20/1540:7",
  "22:prices:1:20/10:67:20/210/20/1540:7",
  "23:prices:2:20/10:67:20/210/20/1540:7",
  "24:prices:3:20/10:67:20/210/20/1540:7",
  "25:prices:4:20/10:67:20/210/20/1540:7",
  "26:prices:5:20/10:67:20/210/20/1540:7",
  "27:prices:6:20/10:67:20/210/20/1540:7",
  "28:prices:7:20/10:67:20/210/20/1540:7",
  "29:prices:8:20/10:67:20/210/20/1540:7",
  "30:prices:9:20/10:67:20/210/20/1540:7"
];
const EXPECTED_SAMPLE_SHAPE = [
  "abracadabra:7 cases/49 checks:12/6:32:84/546/84/364",
  "genome:6 cases/42 checks:24/5:58:144/750/144/2600",
  "mississippi:6 cases/42 checks:12/5:29:72/390/72/364",
  "prices:11 cases/77 checks:20/10:67:220/2310/220/1540"
];
const EXPECTED_CRITICAL_SHAPE = [
  "access agrees with the original sequence:30/30",
  "compressed bitmap entropy sums to sequence H0:30/30",
  "internal bitmaps preserve stable partition lengths:30/30",
  "range quantile agrees with sorting every slice:30/30",
  "rank agrees with naive prefix counts:30/30",
  "raw bitmap budget is bounded by fixed-width storage:30/30",
  "select agrees with naive occurrence positions:30/30"
];
const EXPECTED_CASES = EXPECTED_CASE_SHAPE.length;
const EXPECTED_CHECKS = EXPECTED_CASES * EXPECTED_CRITICAL_SHAPE.length;
const EXPECTED_TOTALS = {
  rows: EXPECTED_CASES,
  samples: EXPECTED_SAMPLE_SHAPE.length,
  criticalChecks: EXPECTED_CRITICAL_SHAPE.length,
  passed: EXPECTED_CASES,
  total: EXPECTED_CASES,
  checked: EXPECTED_CHECKS,
  passedChecks: EXPECTED_CHECKS,
  totalChecks: EXPECTED_CHECKS
};
const EXPECTED_CASE_ROWS = EXPECTED_CASE_SHAPE.map(
  (row) => `${row}:checks=${EXPECTED_CRITICAL_SHAPE.length}/${EXPECTED_CRITICAL_SHAPE.length}:` +
    "failed=none:passed=true"
);

function sameList(left, right) {
  return left.length === right.length &&
    left.every((value, index) => value === right[index]);
}

function sameJson(left, right) {
  return JSON.stringify(left) === JSON.stringify(right);
}

function symbolKey(symbol) {
  return symbol == null ? "all" : symbol;
}

function caseShape(row) {
  return `${row.caseId}:${row.sample}:${symbolKey(row.symbol)}:` +
    `${row.length}/${row.alphabet}:${row.waveletBits}:` +
    `${row.accessChecks}/${row.rankChecks}/` +
    `${row.selectChecks}/${row.rangeQuantileChecks}:${row.totalChecks}`;
}

function caseRow(row) {
  return `${caseShape(row)}:checks=${row.passedChecks}/${row.totalChecks}:` +
    `failed=${row.failedChecks.length ? row.failedChecks.join("|") : "none"}:` +
    `passed=${row.passed}`;
}

function rowDrifts(actual, expected) {
  return {
    missing: expected.filter((row) => !actual.includes(row)),
    extra: actual.filter((row) => !expected.includes(row))
  };
}

function hasRowDrift(drift) {
  return drift.missing.length > 0 || drift.extra.length > 0;
}

function auditShape(audit) {
  return {
    totals: {
      rows: audit.cases.length,
      samples: audit.bySample.length,
      criticalChecks: audit.criticalChecks.length,
      passed: audit.passed,
      total: audit.total,
      checked: audit.checked,
      passedChecks: audit.passedChecks,
      totalChecks: audit.totalChecks
    },
    cases: audit.cases.map(caseShape),
    caseRows: audit.cases.map(caseRow),
    bySample: audit.bySample.map(
      (row) => `${row.sample}:${row.cases} cases/${row.totalChecks} checks:` +
        `${row.length}/${row.alphabet}:${row.waveletBits}:` +
        `${row.accessChecks}/${row.rankChecks}/` +
        `${row.selectChecks}/${row.maxRangeQuantileChecks}`
    ),
    criticalChecks: audit.criticalChecks.map(
      (row) => `${row.check}:${row.passed}/${row.total}`
    )
  };
}

const audit = lab.auditWaveletTreeLab();
const shape = auditShape(audit);
const failed = audit.cases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
const failedCriticalChecks = audit.criticalChecks.filter(
  (row) => !row.ok || row.passed !== row.total
);
const caseRowDrifts = rowDrifts(shape.caseRows, EXPECTED_CASE_ROWS);
const shapeErrors = [
  sameJson(shape.totals, EXPECTED_TOTALS) ? null : "totals",
  sameList(shape.cases, EXPECTED_CASE_SHAPE) ? null : "cases",
  hasRowDrift(caseRowDrifts) ? "caseRows" : null,
  sameList(shape.bySample, EXPECTED_SAMPLE_SHAPE) ? null : "bySample",
  sameList(shape.criticalChecks, EXPECTED_CRITICAL_SHAPE) ? null : "criticalChecks"
].filter(Boolean);
console.table(audit.bySample);
console.table(audit.criticalChecks);
const summary =
  `${audit.passed}/${audit.total} cases and ${audit.passedChecks}/${audit.totalChecks} checks passed`;
if (
  shapeErrors.length ||
  failed.length ||
  failedCriticalChecks.length ||
  !audit.ok ||
  audit.passed !== audit.total ||
  audit.passedChecks !== audit.totalChecks
) {
  throw new Error(JSON.stringify({
    summary,
    shapeErrors,
    shape,
    caseRowDrifts,
    failed,
    failedCriticalChecks,
    errors: audit.errors,
    passed: audit.passed,
    total: audit.total,
    passedChecks: audit.passedChecks,
    totalChecks: audit.totalChecks
  }, null, 2));
}
console.log(summary);
NODE

For every built-in sequence, the audit checks:

• access(i) returns the original symbol for every position;
• rank(c, i) equals a direct prefix scan for every symbol and prefix length;
• select(c, k) returns the same position as a direct occurrence scan;
• range quantile agrees with sorting every nonempty slice and taking the requested rank;
• every internal bitmap length equals its stable partition children; and
• the sum of zero-order entropy over node bitmaps equals the sequence’s zero-order empirical entropy.

The last check is the compression ledger. The raw balanced tree stores at most \(n \lceil \log_2 \sigma \rceil\) bitmap bits, because every original symbol contributes one bit per level on its root-to-leaf path. If each node bitmap were compressed to its own zero-order entropy while keeping rank/select, the entropy terms telescope to \(nH_0(S)\). Navarro gives the clean derivation in the survey: the root separates the alphabet into two groups; children separate those groups again; after the last split, the sum has become \(\sum_{c \in \Sigma} n_c \log_2(n/n_c)\).

Where This Toy Stops

The implementation is static and intentionally literal. It stores one prefix count per bit position, so rank is easy to inspect. A production compact sequence representation would replace those arrays with succinct rank/select structures, possibly use Huffman-shaped or multiary wavelet trees, or use a wavelet matrix to remove pointer-heavy tree navigation for large alphabets.

The important invariant survives those engineering choices:

parent range + rank on a stable bitmap = child range

Once that invariant clicks, the structure stops looking like a compression curiosity. It is a way to keep asking binary questions without forgetting where the original positions went.

look at about 37% of the candidates,
then take the next one who beats everyone so far

That slogan is memorable, but it hides the actual object. This is not a general rule for hiring, dating, search, or life. It is an optimal-stopping theorem for a narrow information contract:

n candidates arrive in uniformly random order
you see only relative ranks among candidates already seen
you must accept or reject immediately
you win only if you select the single best candidate

Under that contract, the only candidates worth accepting are records: someone better than every earlier candidate. A non-record is already known not to be the global best.

The decision is therefore not “is this person good?” It is:

has the sampling period been long enough
that a new record is worth stopping on?

The Finite Formula

Pick a cutoff r. Reject candidates 1..r-1. From candidate r onward, accept the first record. If no record appears, the final candidate is taken and usually loses.

For r > 1, this rule succeeds exactly when the best candidate appears at some position i >= r and the best among the first i-1 candidates lies inside the sample window 1..r-1. Conditional on the global best appearing at position i, the previous maximum is equally likely to occupy any of the first i-1 positions. So

P(success | cutoff r)
  = (r-1)/n * sum_{i=r}^n 1/(i-1).

For r = 1, the rule accepts the first candidate and succeeds with probability 1/n.

Let n grow and write x = r/n. The harmonic sum becomes an integral and the success probability approaches

-x log x.

The maximum is at x = 1/e, with value 1/e. That is where the 37% rule comes from. Ferguson’s historical survey gives this derivation and points to Gilbert and Mosteller’s 1966 paper as the basic treatment with many extensions.¹

The Backward View

The formula above proves the best cutoff among cutoff rules. The dynamic program shows why a cutoff rule appears at all.

Suppose candidate i has arrived and is a record. If we stop, the chance that this record is the global best is:

i / n

That may look backwards at first. A record at position i is the best of the first i candidates; by exchangeability, the best-so-far is the global best with probability i/n.

Let V[i] be the optimal success probability before seeing candidate i. If candidate i is a record, stopping pays i/n; continuing pays V[i+1]. If it is not a record, stopping pays zero, so continuing is the only rational move. Because candidate i is a record with probability 1/i,

V[i] = (1/i) * max(i/n, V[i+1])
     + (1 - 1/i) * V[i+1].

Run this recurrence backward from the end. The first index where i/n >= V[i+1] is the same cutoff found by the finite formula.

Lab: Where The Record Becomes Worth It

The lab computes:

• the exact finite success curve for every cutoff;
• the backward dynamic program’s accept-record boundary;
• a seeded simulation of the selected cutoff;
• one visible shuffled order, with records and the selected candidate marked.

For n = 80, the exact optimum is to reject 29 candidates and make candidate 30 the first eligible record. The exact success probability is about 0.3719. The limiting 1/e answer is already a good mental model, but the finite curve is the real answer.

What The Audit Checks

The exported Node audit does four things:

enumerates all permutations for n = 5, 6, 7
checks every cutoff against the closed-form probability
runs backward induction for n = 12, 25, 80, 150
checks that the DP cutoff and value equal the exact finite optimum

It also runs the default seeded simulation and checks that the simulated success rate is within a small tolerance of the exact probability. Ignoring the returned case rows, the current top-level audit reports:

{
  "exactAtCutoff": 0.3719,
  "ok": true,
  "optimalCutoff": 30,
  "optimalProbability": 0.3719,
  "passed": 26,
  "passedChecks": 30,
  "totalChecks": 30,
  "total": 26
}

The compact reproduction check is:

node - <<'NODE'
const lab = require("./assets/js/secretary-stopping-lab.js");
const EXPECTED_EXACT_CASE_SHAPE = [
  "5:1:0.200000000000:0.200000000000:0.000e+0:1/1:closed form equals brute force=true",
  "5:2:0.416666666667:0.416666666667:5.551e-17:1/1:closed form equals brute force=true",
  "5:3:0.433333333333:0.433333333333:5.551e-17:1/1:closed form equals brute force=true",
  "5:4:0.350000000000:0.350000000000:0.000e+0:1/1:closed form equals brute force=true",
  "5:5:0.200000000000:0.200000000000:0.000e+0:1/1:closed form equals brute force=true",
  "6:1:0.166666666667:0.166666666667:0.000e+0:1/1:closed form equals brute force=true",
  "6:2:0.380555555556:0.380555555556:0.000e+0:1/1:closed form equals brute force=true",
  "6:3:0.427777777778:0.427777777778:0.000e+0:1/1:closed form equals brute force=true",
  "6:4:0.391666666667:0.391666666667:5.551e-17:1/1:closed form equals brute force=true",
  "6:5:0.300000000000:0.300000000000:0.000e+0:1/1:closed form equals brute force=true",
  "6:6:0.166666666667:0.166666666667:0.000e+0:1/1:closed form equals brute force=true",
  "7:1:0.142857142857:0.142857142857:0.000e+0:1/1:closed form equals brute force=true",
  "7:2:0.350000000000:0.350000000000:0.000e+0:1/1:closed form equals brute force=true",
  "7:3:0.414285714286:0.414285714286:5.551e-17:1/1:closed form equals brute force=true",
  "7:4:0.407142857143:0.407142857143:5.551e-17:1/1:closed form equals brute force=true",
  "7:5:0.352380952381:0.352380952381:0.000e+0:1/1:closed form equals brute force=true",
  "7:6:0.261904761905:0.261904761905:0.000e+0:1/1:closed form equals brute force=true",
  "7:7:0.142857142857:0.142857142857:0.000e+0:1/1:closed form equals brute force=true"
];
const EXPECTED_EXACT_SUMMARY_SHAPE = [
  "5:5:5/5:5.55e-17",
  "6:6:6/6:5.55e-17",
  "7:7:7/7:5.55e-17"
];
const EXPECTED_DP_CASE_SHAPE = [
  "12:5:5:0.395514670515:0.395514670515:0.000e+0:2/2:DP cutoff equals finite optimum=true|DP value equals finite optimum=true",
  "25:10:10:0.380916372563:0.380916372563:5.551e-17:2/2:DP cutoff equals finite optimum=true|DP value equals finite optimum=true",
  "80:30:30:0.371855486992:0.371855486992:1.110e-16:2/2:DP cutoff equals finite optimum=true|DP value equals finite optimum=true",
  "150:56:56:0.369997293685:0.369997293685:6.106e-16:2/2:DP cutoff equals finite optimum=true|DP value equals finite optimum=true"
];
const EXPECTED_DEFAULT_CHECK_SHAPE = [
  "cutoff range:1/1:passed=true",
  "curve bounded:1/1:passed=true",
  "formula finite:1/1:passed=true",
  "simulation close:1/1:passed=true"
];
const EXPECTED_ROWS =
  EXPECTED_EXACT_CASE_SHAPE.length +
  EXPECTED_DP_CASE_SHAPE.length +
  EXPECTED_DEFAULT_CHECK_SHAPE.length;
const EXPECTED_CHECKS = [
  ...EXPECTED_EXACT_CASE_SHAPE,
  ...EXPECTED_DP_CASE_SHAPE,
  ...EXPECTED_DEFAULT_CHECK_SHAPE
].reduce((sum, row) => sum + Number(row.match(/:(\d+)\/(\d+)(?::|$)/)[2]), 0);

function sameList(actual, expected) {
  return actual.length === expected.length &&
    actual.every((value, index) => value === expected[index]);
}

function checkResults(row) {
  return row.checks.map((check) => `${check.name}=${check.passed}`).join("|");
}

function exactCaseShape(row) {
  return `${row.n}:${row.cutoff}:${row.exact.toFixed(12)}:` +
    `${row.brute.toFixed(12)}:${row.difference.toExponential(3)}:` +
    `${row.passedChecks}/${row.totalChecks}:${checkResults(row)}`;
}

function exactSummaryShape(row) {
  return `${row.n}:${row.cutoffs}:${row.checks}:${row.maxDifference}`;
}

function dpCaseShape(row) {
  return `${row.n}:${row.bestCutoff}:${row.dpFirstAccept}:` +
    `${row.bestProbability.toFixed(12)}:${row.dpValue.toFixed(12)}:` +
    `${row.valueDifference.toExponential(3)}:` +
    `${row.passedChecks}/${row.totalChecks}:${checkResults(row)}`;
}

function defaultCheckShape(row) {
  return `${row.name}:${row.passedChecks}/${row.totalChecks}:passed=${row.passed}`;
}

const audit = lab.auditSecretaryStoppingLab();
const exactSummary = [5, 6, 7].map((n) => {
  const rows = audit.exactCases.filter((row) => row.n === n);
  return {
    n,
    cutoffs: rows.length,
    checks: `${rows.reduce((sum, row) => sum + row.passedChecks, 0)}/${rows.reduce((sum, row) => sum + row.totalChecks, 0)}`,
    maxDifference: Math.max(...rows.map((row) => row.difference)).toExponential(2)
  };
});
console.table(exactSummary);
console.table(audit.dpCases.map((row) => ({
  n: row.n,
  bestCutoff: row.bestCutoff,
  dpFirstAccept: row.dpFirstAccept,
  bestProbability: row.bestProbability.toFixed(4),
  valueDifference: row.valueDifference,
  checks: `${row.passedChecks}/${row.totalChecks}`
})));
console.table(audit.defaultChecks.map((row) => ({
  check: row.name,
  checks: `${row.passedChecks}/${row.totalChecks}`
})));
const shape = {
  defaultChecks: audit.defaultChecks.map(defaultCheckShape),
  dpCases: audit.dpCases.map(dpCaseShape),
  exactCases: audit.exactCases.map(exactCaseShape),
  exactSummary: exactSummary.map(exactSummaryShape)
};
const auditShape = {
  exactRows: audit.exactCases.length,
  dpRows: audit.dpCases.length,
  defaultChecks: audit.defaultChecks.length,
  passed: audit.passed,
  total: audit.total,
  passedChecks: audit.passedChecks,
  totalChecks: audit.totalChecks
};
const shapeErrors = [
  ["exactCases", shape.exactCases, EXPECTED_EXACT_CASE_SHAPE],
  ["exactSummary", shape.exactSummary, EXPECTED_EXACT_SUMMARY_SHAPE],
  ["dpCases", shape.dpCases, EXPECTED_DP_CASE_SHAPE],
  ["defaultChecks", shape.defaultChecks, EXPECTED_DEFAULT_CHECK_SHAPE]
].filter((row) => !sameList(row[1], row[2]))
  .map(([name, actual, expected]) => ({ name, actual, expected }));

const failedExactCases = audit.exactCases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
const failedDpCases = audit.dpCases.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
const failedDefaultChecks = audit.defaultChecks.filter(
  (row) => !row.passed || row.passedChecks !== row.totalChecks
);
if (shapeErrors.length ||
    auditShape.total !== EXPECTED_ROWS ||
    auditShape.totalChecks !== EXPECTED_CHECKS ||
    !audit.ok || failedExactCases.length || failedDpCases.length ||
    failedDefaultChecks.length || audit.passed !== audit.total ||
    audit.passedChecks !== audit.totalChecks) {
  throw new Error(JSON.stringify({
    failures: audit.failures,
    failedExactCases,
    failedDpCases,
    failedDefaultChecks,
    shapeErrors,
    auditShape
  }, null, 2));
}
console.log(
  `${audit.passed}/${audit.total} audit rows and ` +
  `${audit.passedChecks}/${audit.totalChecks} checks passed`
);
NODE

That simulation tolerance is not the theorem. It is only a smoke test that the Monte Carlo path agrees with the exact calculation. The theorem is in the finite formula and the backward recurrence.

The Boundary Of The Story

The classic problem uses only relative ranks. That makes it robust to the scale of candidate quality, but it also throws away information. If actual scores are visible and drawn from a known distribution, the problem changes. Gilbert and Mosteller studied that full-information version too.² The right rule becomes an adaptive threshold on observed values, not merely “wait for the next record.”

Real decisions are further away. Hiring is not a random permutation with a single hidden total order. Search often has costs, correlated arrivals, multiple acceptable choices, delayed information, legal constraints, and humans who deserve more than a toy objective function.

So the useful artifact is not the slogan. It is the receipt:

what information arrives,
what decisions are irrevocable,
what payoff is being maximized,
and which stopping rule was priced into that payoff

Under the classic receipt, the best candidate waits for a record. Under a different receipt, the number 37% may be nothing but folklore wearing a lab coat.