3.1.3 · D5Complexity Analysis

Question bank — Best, worst, average case — with examples

1,466 words7 min readBack to topic

Before you start, re-arm the three definitions:

Recall The three cases, in one breath

For a fixed size : best (least work over all size- inputs), worst (most work), average (probability-weighted expected work). Only the input's arrangement/content varies — never .


True or false — justify

Answer each with T/F and one sentence of reasoning.

Worst case is always a larger input than best case.
False. Both are measured at the same ; you change the arrangement, not the size — worst case is the unluckiest layout of the same-sized input.
Best-case running time is the fastest an algorithm can ever run on any input at all.
False. It's the minimum over inputs of a fixed size , so it's still a function of (e.g. insertion-sort best case is , not ).
For linear search the average case equals exactly the midpoint of best and worst.
True, but only by luck: because the cost is linear and uniform in position; this coincidence does not generalise (see quicksort).
If an algorithm's best and worst case are both , then its average case is also .
True. The average is a weighted mean squeezed between best and worst, so if both bounds are the average has no room to escape that order.
Big-O notation always refers to the worst case.
False. , , are bound types (upper/lower/tight) and are independent of which case you analyse — you can write "best case is " perfectly well. See Asymptotic Notation.
Average case requires you to assume something about the inputs.
True. needs a probability distribution over inputs; change the assumed distribution and the average can change. See Expected Value.
Quicksort's average case is close to its worst case because both involve partitioning.
False. Average is and worst is — an entire order apart — because catastrophically bad pivots are rare under random input. See Quicksort.
An algorithm with best case can never be considered "efficient" overall.
False. The best case being cheap says nothing about typical behaviour; you judge efficiency by the worst and average cases, not the lucky one.
The average case can be strictly larger than the worst case if inputs are weird enough.
False. is a weighted average of values that are all , so it can never exceed the worst case; likewise it's never below the best case.

Spot the error

Each statement is wrong or muddled — name the mistake and fix it.

"Insertion sort is , full stop."
The error is quoting one number for all cases; insertion sort is best (sorted) and worst (reversed), so you must say which case refers to. See Insertion Sort.
"Linear search worst case is when the array is very large."
Confuses size with arrangement; worst case is fixed- and occurs when the key is last or absent ( comparisons), regardless of how big is. See Linear Search.
"The average of best and worst is , which we simplify to ."
Two errors: average is not the arithmetic midpoint, and — constant factors vanish in , so it would never simplify to .
"Worst case is pessimistic, so it always overstates real-world time badly."
It guarantees an upper bound, which is a feature not a flaw; for adversarial or safety-critical inputs the worst case is the realistic one, and it never understates time.
"Since quicksort's worst case is , it's slower than merge sort in practice."
Conflates worst case with typical behaviour; quicksort's average with small constants makes it fast in practice, and randomised pivots make the case vanishingly unlikely.
"Best case is useless information."
Not so — a large gap between best () and worst (), as in insertion sort, tells you the algorithm exploits structure (nearly-sorted data), which is genuinely useful.
"Amortized time is just the average case with a different name."
Different averaging: average case averages over the distribution of inputs, while amortized analysis averages the cost over a sequence of operations on one structure, with no probability involved.

Why questions

Answer with the actual reasoning, not a definition.

Why must all three cases hold fixed?
If you let vary you'd be comparing costs across different problem sizes, which mixes "growth with " and "luck of arrangement" into one meaningless number.
Why does insertion sort's best case beat its worst by a whole order of growth?
On sorted input the inner while fails on its first test every time (1 comparison per element ), whereas reversed input forces each element to walk to the front ().
Why can't the average case ever fall outside the best–worst range?
Every lies between and , and a probability-weighted mean of numbers in an interval stays inside that interval.
Why is the uniform-distribution assumption so common in average-case analysis?
It's the simplest, most symmetric model and often makes the sums tractable (e.g. Gauss's ); but it's an assumption, and real inputs may follow a very different distribution.
Why does knowing the worst case matter even if it's rare?
For real-time, security, or hard-deadline systems you need a guarantee that holds even against an adversary who deliberately feeds you the worst input.
Why is " = worst, = best" a tempting but false shortcut?
Because worst case is usually stated with and best with in textbooks, but the bound type describes the shape of a bound (upper/lower/tight) and can be applied to any case independently.

Edge cases

Boundary and degenerate inputs — reason carefully.

Linear search on (empty array): what is each case?
All three collapse — the loop runs zero times and returns "not found" immediately, so best = worst = average (a constant, the return itself).
Linear search when the key appears multiple times: does the worst case change?
No — the algorithm stops at the first match, so many matches can only make it faster; the worst case is still key-absent with comparisons.
Insertion sort on : which case applies?
The outer loop for i in 1..n-1 never executes, so zero comparisons happen — a degenerate input where best, worst and average all equal .
Insertion sort on an array of all-equal elements: best or worst?
Best-like : since a[j] > key is never strictly true (equal is not greater), the inner loop stops immediately, just like the sorted case.
Average case when one input is astronomically more likely than the rest:
The average is dominated by that input's cost; a skewed distribution pulls toward the likely input, which is exactly why the assumed distribution must be stated.
Quicksort on an already-sorted array with a naive "first element" pivot:
This hits the worst case , because each pivot splits off just one element — sorted input is the trap that motivates randomised pivots. See Quicksort.
What if best case = worst case for some algorithm?
Then the running time is input-insensitive at each (e.g. summing every element of an array is always ), and the average is forced to the same order — no spread at all.

Connections