3.3.6 · D4Hashing

Exercises — Load factor — when to resize, rehashing cost

2,452 words11 min readBack to topic

Before we start, one reminder of the symbols so nothing here is a surprise:

Figure below (s01): the two cost curves you will keep meeting. The blue line is chaining's cost , a gentle straight climb. The orange line is open addressing's , which hugs the floor until about (green dashed line) and then rockets up as (red dotted line). Keep this picture in mind for Exercises 2.1–2.3 — it is why the two collision strategies choose different resize points.

Figure — Load factor — when to resize, rehashing cost

Level 1 — Recognition

Exercise 1.1

A chained hash table (see Separate Chaining) has buckets and currently stores keys. What is its load factor ?

Recall Solution

WHAT we do: plug straight into . WHY: the load factor is defined as keys-per-bucket. Nothing more to compute. Answer: .

Exercise 1.2

An open-addressing table (see Open Addressing) reports . Explain, in one sentence, why this number is impossible.

Recall Solution

In open addressing every key lives in its own slot, so you can never store more keys than there are slots: , hence . A value would mean — more cars than parking spaces — which cannot happen. Answer: open addressing requires ; violates .


Level 2 — Application

Exercise 2.1

An open-addressing table has . Using the bound from the parent note, how many probes should an unsuccessful search expect at most?

Recall Solution

WHY this formula: for a failed search we keep probing occupied slots until we hit an empty one; the expected count is bounded by the geometric-series result . Answer: at most probes.

Exercise 2.2

You expect to store keys and want to keep . What is the minimum number of buckets ? Round up to the next power of two.

Recall Solution

WHAT: we want . Rearranged: . WHY round up to a power of two: the slot of a key is (defined in the symbol box above). When the operation equals keeping the lowest bits of — a single fast bit-mask instead of a slow division. The next power of two is . Answer: , choose .

Exercise 2.3

A chained table stores keys in buckets. Give the expected cost of a search in terms, and state the numeric expected chain length.

Recall Solution

Expected chain length scanned is exactly . Total expected search cost: WHY: the "" is the hash-and-index step (always happens); the "" is the average number of keys in the bucket you must walk past. Answer: expected chain length ; expected cost .


Level 3 — Analysis

Exercise 3.1

Insert keys into a table starting at size , doubling whenever would exceed . Fill in the total number of element moves caused by rehashing, and show it is .

Recall Solution

Rehashes fire when the size must double: at sizes . The moved count each time equals how many keys already sat in the table: This is the geometric series with , giving . Compare to : , and , matching the parent's bound "total move work ." WHY it amortizes: those moves are shared across cheap inserts, so per insert the extra work is — a constant. See Amortized Analysis. Answer: total moves ; per-insert amortized cost .

Exercise 3.2

A designer grows the table by adding a fixed 4 slots each time it fills, starting empty at size . Estimate the total rehash-move work to insert keys and give the amortized cost per insert.

Recall Solution

WHAT: with additive growth (), a rehash happens every inserts. The -th rehash moves about elements (the table has grown to keys by then). Number of rehashes . Total moves: As a closed form this is — same order, . Amortized per insert: moves, and this ratio grows with → amortized , not constant. WHY this is bad: unlike doubling, the series is arithmetic (), which sums to instead of a geometric . Answer: moves, amortized moves/insert (and worsening).

Figure below (s02): the two growth strategies plotted head-to-head. The blue line (doubling) is the near-flat move-work; the red line (additive ) is the quadratic that peels away and shoots upward. This is the visual proof of Exercise 3.2's claim: additive growth's total work diverges from linear as grows.

Figure — Load factor — when to resize, rehashing cost

Level 4 — Synthesis

Exercise 4.1

Design the grow/shrink policy for a table so that an adversary alternating insert, delete, insert, delete, … cannot force work per operation. Give concrete thresholds and justify with the load factors reached right after each resize.

Recall Solution

The danger (thrashing): if you grow at and shrink at , one insert can push just above (grow, cost ), then one delete pulls it just below (shrink, cost ), forever — per op. The fix — hysteresis (a gap between thresholds):

  • Grow () when .
  • Shrink () when .

Why the gap saves us — check the post-resize load factor:

  • After a grow ( doubles, unchanged): halves from just above to just above . That is comfortably above the shrink line , so no delete can immediately trigger a shrink.
  • After a shrink ( halves): doubles from just below to just below . That is comfortably below the grow line , so no insert can immediately trigger a grow.

Because each resize leaves you far from the next threshold, you must perform ops to cross a boundary again — so the resize cost amortizes over ops → each. Answer: grow at , shrink at ; after any resize lands in , a safe zone away from both thresholds.


Level 5 — Mastery

Exercise 5.1

Prove from first principles that inserting keys into a table that starts at size and doubles at costs total (hence amortized). Then compute the exact total cost for .

Recall Solution

Setup — two kinds of work.

  1. The placement of each key itself — writing one key into its slot — costs . Over inserts: total .
  2. Rehash moves — each time the size doubles we re-insert all keys currently present.

Rehash work (careful with bounds). Starting at size and inserting keys, doublings are triggered as the table fills at sizes . The rehash that grows the table from size moves the keys sitting in it. So the moves are using . Note: the top index is , not — the final size never itself overflows within these inserts, so it triggers no move. This is the summation bound that must be .

Grand total. Amortized per insert:

Check for (so ):

  • rehash moves ✓ (the doublings ).
  • placements .
  • total ✓.

Everything is now consistent: rehash moves , total cost . Answer: total ; for that is ; amortized .

Exercise 5.2

An open-addressing table must guarantee at most 4 expected probes on an unsuccessful search. What is the largest load factor you may allow, and if you expect keys, what minimum meets it (round to the next power of two)?

Recall Solution

Step 1 — bound from the probe target. We need WHY invert like this: is increasing in ; capping the output at caps the input at . Step 2 — size the table. . WHY round to a power of two: exactly as in Exercise 2.2 — with , the slot computation becomes a bit-mask (keep the low bits of ) instead of a slower division. The next power of two is . Answer: ; minimum , choose .


Recall One-line recap of the whole ladder

Definition () → pick the right cost formula ( vs ) → doubling gives geometric move-work total amortized → hysteresis stops thrashing → but worst-case single insert is still .