Conceptintro
Worst-case analysis
Also called worst-case running time.
Bounds the running time over all inputs of a given size, giving a guarantee that holds for every input.
Worst-case analysis measures the running time of an algorithm as the largest time over all inputs of the same size. The result is a function and a guarantee: no input of size makes the algorithm slower. It is the default way to state a time complexity.
In plain words
An algorithm can be fast on one input and slow on another input of the same size. For example, you look for a name in a list. If the name is first, you stop at once. If the name is not in the list, you must read every entry. Worst-case analysis asks: what is the slowest case for a list of this length? The answer is a promise. No list of this length can take longer.
This is why the worst case is the usual choice. The promise holds for any input, even one that an enemy chooses on purpose. You do not need to know what inputs will come. The worst case can be too pessimistic for inputs that you really meet. In that case, other kinds of analysis help.
The idea
For an algorithm on a set of inputs of size , with the number of steps on input in a stated model:
To prove a bound , you show for each . To prove , you give one input for each with . The first proof is an upper bound for all inputs. The second proof needs one bad input only. If the two bounds are equal up to a constant, you can write , and gives the order of growth of the worst case.
Why it is the default.
- It is a guarantee. A system with a deadline needs a bound that holds for every input.
- It does not need a model of the inputs. Average-case analysis needs a probability distribution, and a wrong distribution gives a wrong result.
- It is often easier to compute than the average.
- For many algorithms the worst case happens often, or it is close to the typical case. Linear search for an absent key is one example.
Contrast with the other costs.
- The best case is the minimum over . It is a lower bound on the time of the algorithm, not a promise. A statement such as "insertion sort takes comparisons" holds only for special inputs, such as a sorted input. It is not a bound for every input.
- The average case is a mean over a distribution on . It tells you the typical cost when you trust the distribution.
- The amortized cost is a bound on the mean cost per operation in a sequence of operations, for the worst sequence. One operation can cost more than the amortized bound, but the sequence as a whole cannot. The input is a sequence, not one instance, and no probability is used.
- The expected time of a randomized algorithm is a mean over its own random choices, for the worst input. It is a worst case over inputs and an average over coin flips. Randomized quicksort makes expected comparisons on each input of distinct keys, but one unlucky run can still make comparisons.
Always , for any distribution.
A limit. The worst-case function can be far above the cost on inputs that occur in practice. In such a case the worst-case bound is still true, but it does not predict the time that you see in practice. Two classic cases:
- Quicksort with the first item as the pivot makes comparisons on a sorted array ( with Lomuto partitioning), so its worst case is . Its average over random orders is .
- The simplex method with Dantzig's pivot rule needs an exponential number of steps on the cubes of Klee and Minty (1972), and similar inputs are known for most other standard rules. But it is fast on most inputs that occur in practice. Smoothed analysis, by Spielman and Teng, explains this gap: it measures the worst case of the expected time after a small random change of the input.
Pitfalls
- A worst-case is not a statement about each input. "The worst-case time of insertion sort is " does not say that insertion sort takes quadratic time on each input. On a sorted input it takes linear time.
- A bare . When a source writes "the algorithm runs in time" and names no case, it means a worst-case upper bound. A bare or claims the bound for every input. So "insertion sort runs in time" is false, and "its worst-case time is " is true. Name the case when you use .
- One bad input is enough for a lower bound, not for an upper bound. To show you must cover every input of size . Tests on many inputs do not prove it.
Examples
Linear search. The array and a key are the input. The algorithm compares with in this order, and it stops at the first match or after . Count each comparison as one step.
- Best case: . The count is .
- Worst case: is absent or is only at . The count is . Each input of size makes at most comparisons, because the loop has passes at most. So exactly.
- Average case, when is in the array, the keys are distinct, and the place of is uniform on : the count is .
So , and the average is half of the worst case. The factor does not change the order of growth.
Insertion sort. Count the comparisons between a key and an item of the sorted part. Insertion sort puts item (for ) in its place in the sorted part , and it compares the key with the items from right to left until an item is not larger than the key, or the part is empty.
- The key at step is compared at least once and at most times. So the total is at least and at most .
- The upper bound is reached by the reverse-sorted input (all items distinct): each key is smaller than all items before it, so step makes exactly comparisons.
- The lower bound is reached by the sorted input: each key is compared once.
So, in comparisons, and . For the two counts are and . For the average over the orders of distinct items the count is , between and . See insertion sort for the algorithm and its proof.
Where it is used
Worst-case bounds are the standard statement for sorting, searching and graph algorithms, and the bounds on this site name the case. They are the base of real-time systems, where a late answer is a failure. They are also the base of lower bounds: a lower bound for a problem in a model, such as the bound for comparison sorting, is a statement about the worst case of every algorithm. When the worst case is too pessimistic, the next tools are average-case analysis and amortized analysis.
References
- Cormen, Leiserson, Rivest and Stein, Introduction to Algorithms, fourth edition, Section 2.2
- Robert Sedgewick and Kevin Wayne, Algorithms, fourth edition, Section 1.4
- Kleinberg and Tardos, Algorithm Design, Chapter 2
- Daniel A. Spielman and Shang-Hua Teng, Smoothed analysis of algorithms: why the simplex algorithm usually takes polynomial time, Journal of the ACM 51 (2004), Introduction
Where this leads
About this page
The build computes these levels from the evidence in the repository. Each row says what the next level needs. Read what the levels mean.
| Ladder | Level | What the next level needs |
|---|---|---|
| Human proof | H0 no proof |
|
| Lean | L0 no Lean part |
|
| Visual | V0 none |
|
| Writing | W4 complete |
|
Tag B5285R Edit this page History Report an error Markdown JSON