Sorting

Suppose you have a Scanner that is tied to an external input file and you want to print the lines of the file in reverse order. For example, the file might contain the following four lines of text:

this
is
fun
no?

Printing these lines in reverse order would produce this output:

no?
fun
is
this

To perform this task iteratively (i.e., using a loop), you'd need some kind of data structure for storing the lines of text, such as an ArrayList<String>. However, recursion allows you to solve the problem without using a data structure.

Remember that recursive programming involves thinking about cases. What would be the simplest file to reverse? A one-line file would be fairly easy to reverse, but it would be even easier to reverse an empty file. So, you can begin writing your method as follows:

public static void reverse(Scanner input) {
    if (!input.hasNextLine()) {
        // base case (empty file)
        ...
    } else {
        // recursive case (nonempty file)
        ...
    }
}

In this problem, the base case is so simple that there isn't anything to do. An empty file has no lines to reverse. Thus, in this case it makes more sense to turn around the if/else statement so that you test for the recursive case. That way you can write a simple if statement that has an implied "else there is nothing to do":

public static void reverse(Scanner input) {
    if (input.hasNextLine()) {
        // recursive case (nonempty file)
        ...
    }
}

Again, the challenge is to solve only a little bit of the problem. How do you take just one step that will get you closer to completing the task? You can read one line of text from the file:

public static void reverse(Scanner input) {
    if (input.hasNextLine()) {
        // recursive case (nonempty file)
        String line = input.nextLine();
        ...
    }
}

For the sample file, this code would read the line "this" into the variable line and leave you with the following three lines of text in the Scanner:

is
fun
no?

Recall that your aim is to produce the following overall output:

no?
fun
is
this

You might be asking yourself questions like, "Is there another line of input to process?" But that's not recursive thinking. If you're thinking recursively, you'll be thinking about what a call on the method will get you. Since the Scanner is positioned in front of the three lines "is", "fun", and "no?", a call on reverse should read in those lines and produce the first three lines of output that you're looking for. If that works, you'll only have to write out the line "this" afterward to complete the output.

This is where the leap of faith comes in—you have to believe that the reverse method actually works. If it does, this code can be completed as follows:

public static void reverse(Scanner input) {
    if (input.hasNextLine()) {
        // recursive case (nonempty file)
        String line = input.nextLine();
        reverse(input);
        System.out.println(line);
    }
}

This code does work. To reverse a sequence of lines, simply read in the first one, reverse the others, and then write out the first one.

Let's break down what reverse does on our small example. The idea of representing each method call as a piece of paper and putting each one on top of the others as it is called is a metaphor for Java's call stack. If you envision the call stack as a stack of papers with the most recently called method on top, you'll have a pretty good idea of how it works. Let's use the idea of the call stack to understand how the recursive file-reversing method works. To visualize the call stack, we need to put the method definition on a piece of paper:

Notice that the paper includes a place to store the value of the local variable line. This is an important detail. Suppose that we call this method with the earlier sample input file, which contains the following four lines of text:

this
is
fun
no?

When we call the method, it reads the first line of text into its line variable, and then it reaches the recursive call on reverse:

Then what happens? To understand what happens, you have to realize that each method invocation is independent of the others. We don't have only a single sheet of paper with the reverse method written on it; we have as many copies as we want. So, we can grab a second copy of the method definition and place it on top of the current one:

This new version of the method has a variable of its own, called line, in which it can store a line of text. Even though the previous version (the one underneath this one) is in the middle of its execution, this new one is at the beginning of its execution. Think of the analogy of being able to employ an entire army of people to help print out the lines in reverse. You can call on as many people as you need to solve the problem. In this case, you can bring up as many copies of the reverse method as you need to solve this problem.

The second call on reverse reads another line of text (the second line, "is"). After the program reads the second line, it makes another recursive call on reverse:

So Java sets aside this version of the method as well and brings up a third version:

Again, notice that this version has its own variable called line that is independent of the other variables called line. This version of the method also reads in a line (the third line, "fun") and reaches a recursive call on reverse:

This brings up a fourth version of the method:

This version finds a fourth line of input ("no?"), so it reads that in and reaches the recursive call:

This call brings up a fifth version of the method:

This version turns out to have the easy task. This time around the Scanner is empty (input.hasNextLine() returns false). The program has reached the very important base case that stops this process from going on indefinitely. This version of the method recognizes that there are no lines to reverse, so it simply terminates.

Then what? Having completed this call, we throw it away and return to where we were just before executing the call:

We've finished the call on reverse and are positioned at the println right after it, so we print the text in the line variable ("no?") and terminate. Where does that leave us? This method has been executed and we return to where we were just before:

We then print the current line of text, which is "fun", and this version also goes away:

Now we execute this println, for the text "is", and eliminate one more call:

Notice that we've written out three lines of text so far:

no?
fun
is

Our leap of faith was justified. The recursive call on reverse read in the three lines of text that followed the first line of input and printed them in reverse order. We complete the task by printing the first line of text, which leads to this overall output:

no?
fun
is
this

Then this version of the method terminates, and the program has finished executing.

• It's a very efficient sorting algorithm
  • Java (and many other programming libraries) use an algorithm based on merge sort for their built-in sorting
• It's a comparison sort meaning that it involves comparing objects to each other and thus uses the compareTo method we've just learned about
• It provides some practice with recursion
• Computer scientists are generally expected to know about sorting

To get us started here's a visual example of what merge sort will do:

     [13, 42, 97, -3, 53, 18, 92, 50]
          /                       \
         /                         \
  [13, 42, 97, -3]         [53, 18, 92, 50]
     /          \            /          \
    /            \          /            \
 [13, 42]    [97, -3]    [53, 18]    [92, 50]
   /   \       /   \      /   \       /   \
  /     \     /     \    /     \     /     \
[13]  [42]  [97]  [-3]  [53]  [18]  [92]  [50]
  \    /      \    /      \    /      \    /
   \  /        \  /        \  /        \  /
 [13, 42]   [-3, 97]    [18, 53]    [50, 92]
     \         /            \          /
      \       /              \        /
  [-3, 13, 42, 97]         [18, 50, 53, 92]
          \                       /
           \                     /
     [-3, 13, 18, 42, 50, 53, 92, 97]

It will start by splitting up the list into smaller and smaller sublists (dividing in half each time). Once it's down to single-element lists (which don't need to be sorted), it starts merging the sublists back together. It's during this merge step that the sorting actually takes place, so let's start there.

Take two sorted lists, combine them into a single sorted list. Pseudocode:

Given two sorted lists, left and right, and an empty list, merged
while elements remain in both left and right
    compare the first element in left to the first element in right
    remove the smaller one from its list and append it to merged
append any remaining elements from left or right to merged

Let's begin by writing a method that takes three lists as arguments. The first list will be empty and that will be where we want to store our result. The other two lists will each contain a sorted list of values. The idea is to merge the two sorted lists into one list. By the time we're done, we want all of the values to be in the first list in sorted order and we want the other two lists to be empty.

So the header for our method would look like this (for sorting strings):

public static void merge(Queue<String> result,
                         Queue<String> list1,
                         Queue<String> list2) {

So we have two sorted lists and we want to merge them together. How do we do it? A good wrong answer is to say that we glue the two lists together and call a sorting routine. We want to take advantage of the fact that the two lists are already sorted. Perhaps we'd want to look at the first value in each list and pick the smaller one. Then we'd move that value into our result.

if (list1.peek() < list2.peek()) {
    // move front of list1 to result
}

This has the right logic, but we have to work out the syntax.Remember that we can't compare String objects this way (str1 < str2). Instead, we have to take advantage of the fact that String implements the Comparable interface and use its compareTo method instead. We also have to fill in how to move something from the front of one of the two lists into our result.

if (list1.peek().compareTo(list2.peek()) < 0) {
    result.add(list1.remove());
}

And what do we do if the first value of list1 is not less than or equal to the first value of list2? Then we'd want to take from the other list:

if (list1.peek().compareTo(list2.peek()) < 0) {
    result.add(list1.remove());
} else {
    result.add(list2.remove());
}

Of course, this just says how to handle one value. We want to keep doing this as long as their are values left to compare, so we need this inside a loop. So we want to continue while both lists are nonempty:

!list1.isEmpty() && !list2.isEmpty()

So using this as a loop test our code becomes:

while (!list1.isEmpty() && !list2.isEmpty()) {
    if (list1.peek().compareTo(list2.peek()) < 0) {
        result.add(list1.remove());
    } else {
        result.add(list2.remove());
    }
}

So this loop will take values from one list or the other while they both have something left to compare. Eventually one of the lists will become empty. Then what? Suppose it's the second list that becomes empty first. What do we do with the values left in the first list? Every one of them is larger than the values in the second list and they're in sorted order. So all we have to do is transfer them from the first list to the result.

while (!list1.isEmpty()) {
    result.add(list1.remove());
}

This is the right code to execute if the second list is the one that has gone empty. But what if it's the first list that has gone empty? Then you'd want to do a corresponding transfer from the second list:

while (!list2.isEmpty()) {
    result.add(list2.remove());
}

You might think that we need an if/else to figure out whether it's the first case or the second case, but it turns out that an if/else would be redundant. The loops already have tests to see if the list is empty. So we can simply execute both loops. What will end up happening is that one list will have something left in it, so one of these loops will execute, and the other list will be empty, in which case the other loop doesn't have any effect. So the final code is as follows:

public static void mergeInto(Queue<String> result,
                             Queue<String> list1,
                             Queue<String> list2) {
    while (!list1.isEmpty() && !list2.isEmpty()) {
        if (list1.peek().compareTo(list2.peek()) < 0) {
            result.add(list1.remove());
        } else {
            result.add(list2.remove());
        }
    }
    while (!list1.isEmpty()) {
        result.add(list1.remove());
    }
    while (!list2.isEmpty()) {
        result.add(list2.remove());
    }
}

Now let's turn our attention to how to use this merge method to sort a list. Sticking with a queue of strings, we want to write a method like this:

public static void sort(Queue<String> list) {
            ...
        }

If we want to think recursively, we can begin by thinking about base cases. What would be an easy list to sort? An empty list seems pretty easy—it doesn't need to be sorted at all. It's also true that a list of 1 element also doesn't need to be sorted. If there is only one thing, there is nothing else around to be out of order with it. This is one of those cases where we don't have to do anything in the base case. So we can write a simple if statement with a test for when there's actual sorting to do:

public static void sort(Queue<String> list) {
    if (list.size() > 1) {
        ...
    }
}

Now we should think about how we could split such a list into two lists. We'd need some variables:

Queue<String> half1 = new LinkedList<String>();
Queue<String> half2 = new LinkedList<String>();

How many things should end up in each list? We want to divide the initial list in half, so list.size() divided by 2 is probably what we want. That's almost right, but we have to worry about the size being odd. An easy way to make this work is to set one of the sizes to list.size() divided by 2 and to set the other to list.size() minus the first one:

int size1 = list.size() / 2;
int size2 = list.size() - size1;

So now it's just a matter of transferring items from the list to the two new lists. We can do so with simple for loops:

for (int i = 0; i < size1; i++) {
    half1.add(list.remove());
}
for (int i = 0; i < size2; i++) {
    half2.add(list.remove());
}

So where does that leave us? We have two lists, each with half of the items from the original list. That means that our original list is now empty. And we also know that we have a way to merge two sorted lists together (the method merge that we wrote earlier). But will that work? Unfortunately not. These two lists aren't necessarily sorted. They're just the first and second half of the original list.

What are we to do??? Don't give up hope, recursion will come to our rescue! We've reached a point where we have two lists, each with half of the items from the original list. We need them to be sorted. If only we had a method for sorting a list, then we could call it. But we have such a method. We're writing it! So we sort these two sublists:

sort(half1);
sort(half2);

And once the two are sorted, we can merge them together putting them back into the original list using the method we wrote a minute ago:

merge(list, half1, half2);

And that's the entire method. We're done. Putting all the pieces together, we ended up with:

public static void sort(Queue<String> list) {
    if (list.size() > 1) {
        Queue<String> half1 = new LinkedList<String>();
        Queue<String> half2 = new LinkedList<String>();
        int size1 = list.size() / 2;
        int size2 = list.size() - size1;
        for (int i = 0; i < size1; i++) {
            half1.add(list.remove());
        }
        for (int i = 0; i < size2; i++) {
            half2.add(list.remove());
        }
        sort(half1);
        sort(half2);
        merge(list, half1, half2);
    }
}

• merge is \(O(n)\) (we have to compare and/or insert each element of the two sublists)
• how many merges?
  • number of times \(n\) can be divided by 2 before we reach the base case: \(O(\log_2 n)\)
• so overall, mergesort is \(O(n\log_2 n)\)
  • There is, in fact, no general sorting algorithm with better big-O efficiency than \(O(n\log_2 n)\)