Sets, canonical keys, and the seen-set invariant
Choosing the key is the design decision in most hashing problems — a sorted string versus a count signature for grouping, why an array can't be a key in JavaScript but a tuple can in Python, how a set turns an O(n log n) sequence problem into an amortised O(n) one, and the three cases where a set is the wrong structure entirely.
What you'll be able to do
- Design a canonical key so that equivalent inputs collide deliberately, and compare the cost of the two standard choices
- Explain what makes a value usable as a key in JavaScript versus Python, and the bug that follows from getting it wrong
- Use a seen-set to reach amortised O(n) on a problem whose obvious solution sorts
- Prove an amortised bound by counting total work rather than per-iteration work
- Name the three situations where a bitmask, a sorted structure, or a probabilistic filter beats a hash set
Before this: hash-maps, counting-and-frequency
The rest of this lesson is in the app
Choosing the key is the design decision in most hashing problems — a sorted string versus a count signature for grouping, why an array can't be a key in JavaScript but a tuple can in Python, how a set turns an O(n log n) sequence problem into an amortised O(n) one, and the three cases where a set is the wrong structure entirely. This walkthrough runs about 20 minutes, with runnable code you can edit and re-run as you read.
Continue in ChannelPulseThe first module of every track is free to read on the web — see what's open in Coding & data structures.