"Two different questions get mixed up constantly: 'how tight is my bound?' and 'which input am I analyzing?' They're separate axes. Untangling them clears up half the confusion."
Axis One: How Tight Is the Bound?
O, Θ, and Ω are three ways to bound one function's growth:
- Big-O is an upper bound: "grows at most this fast." Saying an algorithm is O(n²) promises it's never worse than quadratic — but it might be better.
- Big-Ω (Omega) is a lower bound: "grows at least this fast." It's the floor.
- Big-Θ (Theta) is a tight bound: upper and lower agree, so it's the true shape. Θ(n) means "grows exactly like n, no loophole."
In casual conversation, people say "O(n)" when they really mean Θ(n) — the exact shape. That's usually fine; just know that strictly, O is only the ceiling. When someone pedantically corrects your "O" to "Θ," this is what they're on about.
Axis Two: Which Input?
This is a completely different axis, and conflating it with the first is the classic beginner mix-up. Best / average / worst case asks: for a given input size, which arrangement of the input am I looking at?
- Best case — the luckiest input. Linear search finds it at position 0: O(1). Rarely the number you should care about.
- Worst case — the unluckiest input. Linear search scans everything and misses: O(n). This is usually the number that matters, because it's the guarantee.
- Average case — the typical input, averaged over realistic data. Linear search: about n/2 → still O(n).
So quicksort is "Θ(n log n) average, Θ(n²) worst" — two different inputs, two different shapes, both true. Hash lookup is "O(1) average, O(n) worst." You're not contradicting yourself; you're naming different inputs.
Which Number Should Rule Your Decisions?
Usually two: the worst case (the promise you can keep no matter what the user throws at you) and the average case (what actually happens most of the time). Best case is mostly bragging — "it's O(1) if the answer happens to be first" tells you nothing useful. When a system needs hard guarantees (real-time, safety-critical), worst case is king; when it just needs to be fast in practice, average case often wins the design.