snippetMajor
Least number of comparisons needed to sort (order) 5 elements
Viewed 0 times
numberneededorderelementsleastsortcomparisons
Problem
Find the least number of comparisons needed to sort (order) five elements and
devise an algorithm that sorts these elements using this number of comparisons.
Solution: There are 5! = 120 possible outcomes. Therefore a binary
tree for the sorting procedure will have at least 7 levels. Indeed, $2^h$
≥ 120 implies $h $ ≥ 7. But 7 comparisons is not enough. The least number
of comparisons needed to sort (order) five elements is 8.
Here is my actual question: I did find an algorithm that does it in 8 comparison but how can I prove that it can't be done in 7 comparisons?
devise an algorithm that sorts these elements using this number of comparisons.
Solution: There are 5! = 120 possible outcomes. Therefore a binary
tree for the sorting procedure will have at least 7 levels. Indeed, $2^h$
≥ 120 implies $h $ ≥ 7. But 7 comparisons is not enough. The least number
of comparisons needed to sort (order) five elements is 8.
Here is my actual question: I did find an algorithm that does it in 8 comparison but how can I prove that it can't be done in 7 comparisons?
Solution
The solution is wrong. Demuth [1; via 2, sec. 5.3.1] shows that five values can be sorted using only seven comparisons, i.e. that the "information theoretic" lower bound is tight in this instance.
The answer is a method tailored to $n=5$, not a general algorithm. It's also not very nice. This is the outline:
-
Sort the first two pairs.
-
Order the pairs w.r.t. their respective larger element.
Call the result $[a,b,c,d,e]$; we know $a
-
Insert $e$ into $[a,b,d]$.
-
Insert $c$ into the result of step 3.
The first step clearly takes two comparisons, the second only one. The last two steps take two comparisons each; we insert into a three-element list in both cases (for step 4., note that we know from $c
by Donald E. Knuth; The Art of Computer Programming Vol. 3 (2nd ed, 1998)
The answer is a method tailored to $n=5$, not a general algorithm. It's also not very nice. This is the outline:
-
Sort the first two pairs.
-
Order the pairs w.r.t. their respective larger element.
Call the result $[a,b,c,d,e]$; we know $a
-
Insert $e$ into $[a,b,d]$.
-
Insert $c$ into the result of step 3.
The first step clearly takes two comparisons, the second only one. The last two steps take two comparisons each; we insert into a three-element list in both cases (for step 4., note that we know from $c
- Sorting and Searching
by Donald E. Knuth; The Art of Computer Programming Vol. 3 (2nd ed, 1998)
Context
StackExchange Computer Science Q#44981, answer score: 32
Revisions (0)
No revisions yet.