Exercises — Universal hashing — probabilistic guarantee
Reminder of the tools we lean on (all built in the parent note):
Level 1 — Recognition
L1·Q1 — Spot the universal family
Which of these families is universal, and which merely feels safe?
- (a) , a single fixed function chosen once by the library author.
- (b) The family with random .
Recall Solution
(b) is universal. A family must contain many functions so we can pick one by coin flip; (a) has exactly one function, so is either or — there is no randomness to average over. An adversary who reads the source code of (a) hands you colliding keys and wins. (b) ranges over different functions; the parent note proves (exactly when ). ✔ universal.
L1·Q2 — Read the definition literally
True or false: "Universal hashing assumes the input keys are random."
Recall Solution
False. The randomness lives entirely in the choice of . The keys are fixed and arbitrary — even adversarial. The probability is taken over , written . Mantra: RANDOM the FUNCTION, never the DATA.
L1·Q3 — Which quantity is the load factor?
A table has slots holding keys. What is ?
Recall Solution
It is the average number of keys per slot. See the bucket picture below — is just "how tall, on average, is each stack".
The figure below shows 6 slots holding 8 keys. What to observe: the individual stacks are uneven (slot 2 is empty, slot 3 holds three keys), yet the pink dashed line — the average height — sits at . That dashed line is : universal hashing controls the average stack, never promising every stack is equal. Carry that mental image into every expected-cost problem below.

Level 2 — Application
L2·Q1 — Compute a hash
With , , , , compute for .
Recall Solution
- (WHY: apply the linear map first.)
- (WHY: mod — this is the universality engine.)
- (WHY: squeeze into .) So . (Note , so every slot is reachable — no wasted buckets.)
The figure traces this as a pipeline of four boxes. What to observe: the arrows are one-directional — you can never skip a box or swap the order. Notice the labels under the arrows: "mod p first!" sits before "into [0,m)". This is the visual antidote to the L2 trap below; the whole reason the family is universal is that the blue box (mod ) happens strictly before the pink box (mod ).

L2·Q2 — Expected chain length
Universal hashing, slots, keys already inserted. A new key (not yet in the table) arrives. Bound the expected number of keys already sitting in 's slot, and the expected search cost.
Recall Solution
Recall the collision indicator from the top of the page: exactly when the existing key lands in the same slot as , else . The number of keys sharing 's slot is the sum over the keys already present. Because is not yet inserted, all existing keys are candidates. Using and Linearity of expectation: Expected search cost comparisons (the = touch 's slot header). Constant, independent of which 48 keys.
L2·Q3 — When is the bound exactly ?
For , name the condition under which holds exactly, and give the honest bound otherwise.
Recall Solution
Exactly iff divides (), because only then do the residues split into perfectly equal buckets. In general (with but ) the buckets are uneven ( vs residues), giving the almost-universal bound
Level 3 — Analysis
L3·Q1 — Why
Show concretely that allowing destroys universality. Use .
Recall Solution
If then , which is the same constant for every key . So for any distinct : always, i.e. . The requirement (never ) is exactly what keeps a bijection, so distinct keys get distinct residues before the final squeeze. ✔
L3·Q2 — Count colliding function-pairs by hand
Let , , and fix keys . Over all valid with , (that's functions), what fraction collide? Compare to the almost-universal bound.
Recall Solution
Collision happens iff and land in the same class mod . Direct enumeration over the 42 functions gives 14 collisions, fraction . Bound: (almost-universal), and . Observe , so this pair sits exactly at the truly-universal ceiling and comfortably under the almost-universal ceiling — no pair exceeds . ✔ (verified numerically).
The figure shows why the bound is and not exactly . What to observe: the seven residues are dealt into three buckets by "value mod 3", and bucket 0 gets three residues while buckets 1 and 2 get only two each. That single overloaded bucket is the extra collision risk — it is why the honest ceiling is , slightly above the ideal . Uneven buckets ⇒ almost-universal, not exactly universal.

L3·Q3 — Variance of the analysis is not needed
The parent bounds using linearity of expectation without independence. Explain in one line why independence would have been the wrong assumption.
Recall Solution
Collisions are correlated: if and , then automatically — the events are chained, not independent. Linearity holds regardless of dependence, so we never need (and never have) independence. Assuming it would be false here.
Level 4 — Synthesis
L4·Q1 — Design for a target cost
You must guarantee expected search cost comparisons for a table that will hold up to keys. What is the largest load factor you may allow, and hence the minimum number of slots ?
Recall Solution
Expected cost . Require . Minimum slots . need not be prime — 50000 is perfectly fine (a common choice is even a power of two for a fast final ). The only primality requirement is on the modulus : you must pick a prime (bigger than every key), for example only if that exceeds your largest key; if keys can be large, must be a much bigger prime. So: slots, = any prime above the maximum key. This ties directly to Load factor and rehashing: keep low by resizing.
L4·Q2 — Combine with rehashing
Starting from , you double (rehash, drawing a fresh random ) whenever would exceed . You insert keys one at a time up to . How many resizes occur, and what is right after the last resize?
Recall Solution
Resize triggers when , i.e. at (), (), (). At , ; inserting up to crosses , so one more: (). That's 4 resizes (). After the last resize (, ): . Comfortably below , and fresh random each time preserves the per-pair guarantee.
The sawtooth figure makes the policy visible. What to observe: the blue curve climbs as keys are inserted, and every time it touches the pink threshold line at it instantly drops (a resize doubles , halving ). The yellow "resize" arrows sit exactly at . The takeaway: is never allowed above , so expected cost stays for the whole run.

L4·Q3 — Why fresh randomness on rehash matters
Argue why we draw a new at each resize instead of reusing the old one.
Recall Solution
The universal guarantee is "for fixed keys, over the random draw of ". If we reuse , an adversary who has watched the table (timing, which keys collided) gains information that correlates future keys with the now-known — exactly the fixed-function weakness returning. A fresh independent draw restores the secret, so the bound applies anew to all pairs. See Adversarial inputs and randomized algorithms.
Level 5 — Mastery
L5·Q1 — Prove the bucket-imbalance bound
Prove that for and distinct ,
Recall Solution
Fix distinct . Set , . Bijection step (WHY): since is prime and , the map is a bijection onto all ordered pairs with (subtracting the two equations, , and is invertible mod ). So choosing uniformly is the same as choosing an ordered pair , , uniformly. Collision condition: iff . Fix ; among the other residues , how many satisfy ? Each residue class mod holds at most of the residues, so excluding itself leaves at most valid . Count: Final step (WHY each piece): we claim . Start from the ceiling fact that for any integers, (a ceiling never rounds up by a whole unit or more), so . Multiplying the ceiling of counts at most rounded up; subtracting therefore gives at most . Concretely, because (the smallest multiple of that is is at most ). Dividing both sides of by gives exactly . ∎ (This is the engine behind Perfect hashing (FKS) — uses universal hashing as a building block.)
L5·Q2 — Second-level FKS sizing
In FKS perfect hashing you build a small second-level table for the keys that fell into one bucket, using slots so that the expected number of collisions inside it is . Using a universal family, verify that expectation is for .
Recall Solution
Number of unordered pairs among keys is . Each collides with prob . By linearity: So with we expect fewer than collisions; by Markov, a collision-free second-level table exists with probability , so a few random draws find one. That's the heart of FKS's two-level -space, -worst-case scheme.
L5·Q3 — Sum over all buckets
Continuing FKS: if bucket holds keys and , the total second-level space is . Show its expectation is when the first-level table has buckets from a universal family.
Recall Solution
Step 1 — split the square (WHY: separate the diagonal). For each bucket use the identity , where counts unordered distinct pairs inside bucket . Summing over all buckets: (Used .) Step 2 — count colliding pairs in expectation (WHY: this is where universality enters). is exactly the number of unordered pairs of keys that landed in the same bucket. For one fixed pair , the probability they share a bucket is . There are pairs total, so by Linearity of expectation: Step 3 — plug in . Then . Step 4 — combine. So the whole two-level structure uses linear expected space while giving worst-case lookups — exactly the FKS guarantee. ∎
Self-test grid
Fresh on rehash — why?
Cost formula for a search under universal hashing?
FKS second-level slot count for a bucket of keys?
Identity converting to pair counts?
Total FKS space with buckets?
Exact-universal condition for ?
Does have to be prime?
What does denote?
Connections
- Universal hashing — probabilistic guarantee (parent)
- Linearity of expectation
- Modular arithmetic and primes
- Load factor and rehashing
- Hashing — chaining vs open addressing
- Adversarial inputs and randomized algorithms
- Perfect hashing (FKS) — uses universal hashing as a building block