Algorithms and Data Structures

N.Wirth. Algorithms and Data Structures. Oberon version 67
behavior of the partitioning process first. After having selected a bound x, it sweeps the entire array.
Hence, exactly n comparisons are performed. The number of exchanges can be determind by the following
probabilistic argument.
With a fixed bound u, the expected number of exchange operations is equal to the number of elements in
the left part of the partition, namely u, multiplied by the probability that such an element reached its place
by an exchange. An exchange had taken place if the element had previously been part of the right partition;
the probablity for this is (n-u)/n. The expected number of exchanges is therefore the average of these
expected values over all possible bounds u:
M = [Su: 0 ≤ u ≤ n-1 : u*(n-u)]/n 2
= n*(n-1)/2n - (2n 2 - 3n + 1)/6n
= (n - 1/n)/6
Assuming that we are very lucky and always happen to select the median as the bound, then each
partitioning process splits the array in two halves, and the number of necessary passes to sort is log(n).
The resulting total number of comparisons is then n*log(n), and the total number of exchanges is
n*log(n)/6.
Of course, one cannot expect to hit the median all the time. In fact, the chance of doing so is only 1/n.
Surprisingly, however, the average performance of Quicksort is inferior to the optimal case by a factor of
only 2*ln(2), if the bound is chosen at random.
But Quicksort does have its pitfalls. First of all, it performs moderately well for small values of n, as do
all advanced methods. Its advantage over the other advanced methods lies in the ease with which a straight
sorting method can be incorporated to handle small partitions. This is particularly advantageous when
considering the recursive version of the program.
Still, there remains the question of the worst case. How does Quicksort perform then? The answer is
unfortunately disappointing and it unveils the one weakness of Quicksort. Consider, for instance, the
unlucky case in which each time the largest value of a partition happens to be picked as comparand x.
Then each step splits a segment of n items into a left partition with n-1 items and a right partition with a
single element. The result is that n (instead of log(n)) splits become necessary, and that the worst-case
performance is of the order n 2 .
Apparently, the crucial step is the selection of the comparand x. In our example program it is chosen as
the middle element. Note that one might almost as well select either the first or the last element. In these
cases, the worst case is the initially sorted array; Quicksort then shows a definite dislike for the trivial job
and a preference for disordered arrays. In choosing the middle element, the strange characteristic of
Quicksort is less obvious because the initially sorted array becomes the optimal case. In fact, also the
average performance is slightly better, if the middle element is selected. Hoare suggests that the choice of x
be made at random, or by selecting it as the median of a small sample of, say, three keys [2.12 and 2.13].
Such a judicious choice hardly influences the average performance of Quicksort, but it improves the worstcase
performance considerably. It becomes evident that sorting on the basis of Quicksort is somewhat like
a gamble in which one should be aware of how much one may afford to lose if bad luck were to strike.
There is one important lesson to be learned from this experience; it concerns the programmer directly.
What are the consequences of the worst case behavior mentioned above to the performance Quicksort?
We have realized that each split results in a right partition of only a single element; the request to sort this
partition is stacked for later execution. Consequently, the maximum number of requests, and therefore the
total required stack size, is n. This is, of course, totally unacceptable. (Note that we fare no better — in
fact even worse — with the recursive version because a system allowing recursive activation of procedures
will have to store the values of local variables and parameters of all procedure activations automatically,