Selection Sort

Most of the work in this chapter has been about putting the elements of an array into a particular order, such as smallest to largest. This article turns that goal around. Instead of asking for a specific order, we ask how to put the elements into a random order. This problem is much less common than sorting, but it is a useful companion to it, and it is worth studying because it reuses a familiar structure: selection sort.

The standard picture is shuffling a deck of cards. A shuffled deck is one in which no card's position can be predicted from the order it started in. Keep that picture in mind. The array plays the role of the deck, and the algorithm's job is to rearrange it so that the final order is unpredictable. Selection sort, by contrast, is the procedure that finds the smallest remaining item and places it at the front of the unfinished part, and it is the structure we will trace throughout this article.

A shuffle works in rounds. At the start the whole array is unfinished. In each round one item is chosen at random from the unfinished part and moved to the end of that part. The unfinished part is then treated as one element shorter, and the process repeats on what remains. The loop stops when no unfinished part is left to process.

The source introduces a shuffle subroutine for an array, but the code itself is not reproduced in the material this article draws on. The illustration below is written to match the description: it works from the end of the array toward the front, picks a random position from the unfinished part, and swaps that item into place. Read it as a faithful rendering of the idea rather than the textbook's exact code.

Because the choice is random, two runs on the same array will usually produce different orders. That is the point of the exercise, and it is also why the function cannot be tested by checking one fixed output. A test instead checks properties, such as whether the result contains exactly the same items as the input.

Every cell in this final state differs from the starting array [7, 3, 9, 4]. That is a coincidence of this particular trace, not a rule. A random pick can land on the item itself, as it did in round 3, and then that slot keeps its value. The rule that matters is that each pick comes only from the unfinished positions, and that each chosen item is actually swapped into place.

The control flow of the shuffle is short. At the top of the loop there is a decision: is any unfinished part left? If yes, the algorithm performs the pick, the swap, and the shrinking of the unfinished part, then returns to the decision. If no, the shuffle is done. The decision is deterministic. The pick is the only step that depends on chance, and it is the only place where randomness enters.

The phrase at random is the whole difference from selection sort. In selection sort, the choice is determined by the values in the array, because the largest or smallest remaining item is always the one picked. In a shuffle, the value of the item plays no role in the choice. The algorithm picks a position by chance, and whatever sits there is moved to the end of the unfinished part.

The easiest way to picture selection sort is to split the list into two regions. The front region holds values that are already in their final positions. The back region holds everything not yet placed. Each pass looks only at the back region, finds its smallest value, and moves that value to the first position of the back region. That position then becomes part of the front region, so the boundary moves one step to the right. When the back region has only one item left, the whole list is in order.

The source describes the same idea with the largest item moving to the end of an increasing list, since that is where the largest value belongs. The mirror-image version, used here, moves the smallest remaining item to the front. Both follow the same reasoning: select the next item that belongs in place, put it there, and repeat the same choice on what is left.

Notice that pass 2 does not change the list at all. That is normal: the smallest value of the back region was already at the boundary. The second and third passes are still needed, because the 5 and the 8 are not settled until the back region has been reduced to one item.

The source applies the same idea to a hand of playing cards. Each Card object offers getSuit() and getValue() methods, and the hand is stored in an ArrayList of Card. The method described does not swap cards inside the original list. Instead it creates a second list, repeatedly selects the smallest remaining card from the old list, removes that card from the old list, and adds it to the new list. When the old list is empty, the new list becomes the hand. The source notes that this is not the most efficient procedure, but a hand of cards is small enough that the inefficiency is negligible.

The comparison rule is the part that most often confuses readers. Cards of the same suit are grouped together, and within a suit they are ordered by value. A card c1 replaces the current minimum c when its suit is smaller, or when its suit is equal and its value is smaller. The source also treats aces as the lowest value, 1. This is a two-key comparison: suit is checked first, and value is used only as a tie-breaker when the suits match.

When a finished list is wrong, do not start by rereading the whole algorithm. Trace the list pass by pass and check the boundary after each one. The first pass that produces a value you did not expect is the location of the divergence, and the mistake is almost always in that pass's search step or swap step.