Short Assignment 10 is due Friday.
Programs have to handle all sorts of errors. That's too bad, because programming would be a lot more fun if errors didn't occur. But they do, and in a commercial program, it's not uncommon for far more than half the program text to be for handling errors that are fairly rare.
Yet think about what it would be like to use real software if it doesn't handle errors. A good example was Mac OS 9, which let you corrupt memory that you shouldn't be able to corrupt—and eventually the whole machine would crash.
The following situations are common error cases:
Note that the following three places in a program almost always differ:
In particular, we often need the corrective action to take place within a method that calls the method that detects the error. Or perhaps within a method that calls the method that calls the method that detects the error. Or perhaps within that method's caller. That's the major reason why error handling is so tricky. We need some good way to transfer control from the point of detection to the point of correction. Although calling a method to handle the error might seem like a nice idea, it's often the opposite of what we really need to do. Rather than pushing a method onto the runtime stack, we need to pop methods off the stack.
Java exceptions provide a mechanism to do just this. Java uses three keywords, try, throw, and catch, for exception handling. (C++, by the way, also has exceptions and uses the same three keywords.)
The convention when programming in Java is that there is a distinction between errors and exceptions; errors are more dire. An error occurs when something goes awry and there is no way to continue the program. For example, perhaps a file required to be linked into the program is missing, or one of the "threads of control" has died. An exception occurs when something goes awry, but there might be a way for the program to deal with it. For example, an array index is out of bounds, or we try to open a file that does not exist.
Exceptions are objects. They are subclasses of Throwable, and there's a whole class hierarchy under the Exception class.
Exceptions are thrown. Sometimes by an explicit throw statement, and sometimes just by the program's own bad behavior. As examples of the latter, consider
int a = 1, b = 0, c;
c = a / b;You get the following message:
Exception in thread "main" java.lang.ArithmeticException: / by zeroOr how about
String s = null;
System.out.println(s.toUpperCase());which results in
Exception in thread "main" java.lang.NullPointerExceptionWe'll see throw statements in a moment.
To deal with an exception, it is caught in a try-catch statement. The "try" part is a set of statements. If an exception occurs in the try part, and the "catch" part lists the exception as an exception class that it deals with, then that's where it's dealt with. We say that the exception is caught at that point. Otherwise, the method (let's call it f) immediately terminates and control is immediately transferred to its caller (let's call it g). If the call of f within g was itself within a try-catch statement, and the catch part lists the exception as an exception class that it deals with, then g catches the exception. Otherwise, g propagates the exception back to its caller. And so on. Eventually, we either get to a method that deals with the exception, or we have popped the entire runtime stack. In the latter case, we have propagated the exception all the way back to main without finding a method that catches the exception. In this case, the program terminates, and a message is printed out, along with a stack trace.
Although it may seem horrible to terminate the entire program due to an uncaught exception, doing so is better than the alternatives. The program should not merrily go along, acting as if everything is OK. Something has gone very wrong, and rather than let the program do something wrong, it is better to just stop it.
Note how this scheme of each method either catching the exception or propagating it back to its caller gives us the behavior described above, in which methods are popped from the runtime stack until we find one that catches the exception.
It's pretty easy to throw an exception. There are already a bunch of Java exception classes, and it's quite possible that what has happened fits into one of them. For example, suppose that we were writing the method Integer.parseInt, which takes as a parameter a reference to a String and returns the corresponding int. What if the string does not contain characters that can be interpreted as an int, e.g., 7x? There's a class NumberFormatException, and we can throw an object of this class. We can see this behavior in ParseIntException.java. If s references a String containing 7x, and we call Integer.parseInt(x) in main, we get the output
Exception in thread "main" java.lang.NumberFormatException: For input string: "7x"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Integer.parseInt(Integer.java:492)
at java.lang.Integer.parseInt(Integer.java:527)
at ParseIntException.main(ParseIntException.java:18)We typically construct exception objects with a string that describes what happened. For example, the parseInt method in ParseIntException.java does so.
The string that we give to the exception constructor is part of what's returned by toString. If this exception is caught later on, and we print the exception, we'll actually print that string.
We'll see a little later how to create our own exception classes.
As I said, we use a try-catch statement to catch an exception. For example, suppose we want the user to enter two doubles, and the program divides them and prints the quotient. Here's how we can deal with the denominator being 0 without checking in advance:
Scanner input = new Scanner(System.in);
int a, b;
a = input.nextInt();
b = input.nextInt();
try {
System.out.println("The quotient is " + (a / b));
}
catch (ArithmeticException e) {
System.out.println("Sorry, but we don't allow dividing by zero.");
}If we want to use the message in the exception, we could rewrite the example as
Scanner input = new Scanner(System.in);
int a, b;
a = input.nextInt();
b = input.nextInt();
try {
System.out.println("The quotient is " + (a / b));
}
catch (ArithmeticException e) {
System.out.println("Arithmetic exception: " + e);
}Note how we take advantage of the object e being an ArithmeticException object.
This example showed how we can catch an exception. In fact, this is a lousy use of an exception, because we could have just as easily tested in advance:
Scanner input = new Scanner(System.in);
int a, b;
a = input.nextInt();
b = input.nextInt();
if (b != 0)
System.out.println("The quotient is " + (a / b));
else
System.out.println("Sorry, but we don't allow dividing by zero.");In general, we use exceptions for problems that we either cannot check in our code or are just too inconvenient to check. (For example, perhaps we are in the midst of a long calculation that has a lot of divisions. If we want to catch any of them being a divide by zero, we can use a try-catch statement.)
We can catch more than one type of exception by using multiple catch clauses. If an exception occurs, we go through the catch clauses one by one. The first one to match the type of exception thrown is executed. Note that the subclass principle applies here. If an exception is listed in a catch clause, and the thrown exception is of a subclass, then it matches.
Sometimes, you want a piece of code to be executed whether or not an exception occurred. For example, you might want to free up a resource whether or not there was an exception. We use a finally clause, following all the catch clauses, to do so. To continue the brief but bad example from before:
Scanner input = new Scanner(System.in);
int a, b;
a = input.nextInt();
b = input.nextInt();
try {
System.out.println("The quotient is " + (a / b));
}
catch (ArithmeticException e) {
System.out.println("Arithmetic exception: " + e);
}
finally {
System.out.println("Have a nice day.");
}The "Have a nice day" message will be printed out in all cases.
We define new kinds of exceptions by making a subclass of Exception or one of its transitive subclasses (i.e., anything below Exception in the class hierarchy.) For example, CreatingExceptions.java and OutOfRangeException.java show how to do so. The OutOfRangeException class is a subclass of Exception. All it does is give the string in its constructor to its superclass's constructor. Granted, that's not much help.
Bear in mind, however, that since exceptions are objects, they can include whatever instance variables we want. Let's say that you want to implement your own class called AssociativeArray. An associative array is like an ArrayList, but its indices can be any String. Just to give you a flavor, we might have an associative array indexed by the name of a state and whose contents are the state's capital. Let's suppose that the AssociativeArray class also has a method called lookup, which takes a String and gives you the value stored with that String as the index:
AssociativeArray capitals = new AssociativeArray();
capitals.add("New Hampshire", "Concord");
capitals.add("Vermont", "Montpelier");
capitals.add("Maine", "Augusta");
System.out.println("The capital of Maine is " + capitals.lookup("Maine"));This fragment prints
The capital of Maine is AugustaNow suppose that we make the call capitals.lookup("Samoa"). Since we have no associative array entry indexed by Samoa, we might throw an exception. And it might be good for the exception to include the offending index. We could define an exception class as follows:
public class AssociativeArrayIndexException extends Exception {
private String badIndex;
AssociativeArrayIndexException(String s) {
badIndex = s;
}
public String toString() {
return "AssociativeArray indexing error: index is " + badIndex;
}
}And our AssociativeArray class, upon detecting such an indexing error, could include the code
public String lookup(String index) {
...
if (indexNotFound)
throw new AssociativeArrayIndexException(index);
} where indexNotFound is a boolean indicating that index does not index an entry of the associative array.
Exceptions in Java are considered either checked or unchecked. When you call a method that throws a checked exception, you need to indicate what you will do about the exception if it is ever thrown. You have two choices as to how to indicate what you will do:
You can have your method not catch it, but then you need to explicitly indicate that your method is not catching it and will instead propagate the checked exception up to its caller. You do so in the method header. For example, the OutOfRangeException that we saw earlier is a checked exception. If your method, let's call it bozo, calls a method that could throw an OutOfRangeException, and bozo doesn't catch OutOfRangeException, then the header for bozo should look like
public void bozo() throws OutOfRangeExceptionThe throws clause in the header alerts bozo's caller that bozo may throw an OutOfRangeException. The caller has to either catch it or propagate it up, and so on.
If a method can propagate multiple checked exceptions, list them in the header, separated by commas:
public void bozo() throws OutOfRangeException, FileNotFoundExceptionFileNotFoundException occurs when the program tries to access a file on the computer, and the file is not there.
How do you know which exceptions are checked and which are unchecked? The general rule is that checked exceptions aren't your fault. For example, a FileNotFoundException is not your fault. Maybe the user typed the wrong file name. Maybe some clown trashed the file. But it's not the fault of the programmer.
Unchecked exceptions are your fault. For example, a NullPointerException. You either should not have had a null pointer, or you should have checked for it before using it. Either way, it's your bad.
A priority queue is a queue which instead of being FIFO is "Best Out." "Best" is defined by a priority. For a typical priority queue, low priority numbers are removed first. That may seem backwards, but think of "you are our number one priority!" That's better than being their number two or three priority.
There are hundreds of applications of priority queues. They come up in computer systems (high-priority print jobs, various priority levels of jobs running on a time-sharing system, etc.). They are used in finding shortest paths and other search problems. And a priority queue gives you an easy way to sort: put everything into the priority queue, then take them out one at a time. They come out in sorted order.
There are two flavors of priority queues: min-priority queues and max-priority queues. They vary only in whether a low or high priority number corresponds to "better" priority.
Min-priority queues form the heart of discrete event simulators. A discrete event simulator simulates a system in which events occur. Each event occurs at some moment in time. The simulation runs through time, where the time of each occurrence is nondecreasing (i.e., the simulated time either increases or stays the same—it never backs up). An event can cause another event to occur at some later time. A min-priority queue keeps track of the events that have yet to occur, with the key of an element being the time that its event is to occur. When an event is created, it is added to the min-priority queue. To process the next event to occur, we have to determine the event in the min-priority queue with the lowest time of occurrence and remove it from the queue so that we don't try to process it more than once. Sometimes, the result of an event is to allow some other event, already scheduled, to occur even earlier.
MinPriorityQueue.java contains the interface for a min-priority queue. Here, each element has a value, which we call its key. The MinPriorityQueue interface supports the following operations:
isEmpty, a predicate that tells whether the priority queue is empty.insert, which inserts an element into the priority queue.minimum, which returns the element in the priority queue with the smallest key, but leaves the element in the priority queue.extractMin, which returns the element in the priority queue with the smallest key and removes it from the priority queue.Some applications also require a decreaseKey operation, which reduces the priority value in a given element. The decreaseKey operation makes code more complex, because the surrounding application needs a way to identify individual elements within the priority queue. Doing so could expose the implementation of the priority queue to the surrounding code, unless we use some opaque type as a "middleman" between the code that implements the priority queue and the surrounding code.
We can also define a max-priority queue, which replaces minimum and extractMin by maximum and extractMax (and increaseKey if you include it). We will focus on min-priority queues, but if you can implement one, you can implement the other easily.
Java provides a class java.util.PriorityQueue, although surprisingly no interface for a general priority queue. This implementation is based on a heap, which we will see later in this lecture. Once again, Java chooses different names:
insert becomes add or offer.minimum becomes peek.extractMin becomes poll.isEmpty method. But there is a size method, and you can compare its return value against 0.We define a MinPriorityQueue interface in MinPriorityQueue.java. Here, the interface is declared as
public interface MinPriorityQueue<E extends Comparable<E>>This declaration says that you can use any type E that extends the Comparable interface. But wait, you don't extend an interface; you implement an interface. In the context of generic types, however, you always extend, even if you do it by implementing. Better not to ask why. There might even be a good reason.
What is the Comparable interface? It is the standard Java interface for comparing two objects for less than, greater than, or equal. You need to implement a single method, compareTo(other). It is used to compare this object to the other object. The result is an integer that is negative when this is "less than" other, 0 when this "equals" other, and positive when this is "greater" than other. For example, we might see code like this:
if (list.get(smallest).compareTo(list.get(i)) > 0)This line tests whether list.get(smallest) > list.get(i), i.e., is the element in position smallest of list greater than the element in position i. To test less than you would replace > 0 by < 0, and to test equality you would replace it by == 0.
There is another way to compare two objects: the Comparator interface. The book discusses this interface on pages 363–364. You implement the method compare(a, b) and give the same negative, zero, or positive result as in compareTo. The Java PriorityQueue class will use "natural order" (meaning the results of compareTo) if you call the constructor with no arguments. If you want to use a Comparator you call a constructor that takes two arguments: the initial size of the queue and a Comparator object. This style is more flexible, because you can define different orders for different purposes.
We will look at three implementations of min-priority queues. Each has different running times for the various operations, leading to tradeoffs on which implementation to choose.
ArrayListThe simplest way to implement a min-priority queue is by an ArrayList whose elements may appear in any order. ArrayListMinPriorityQueue.java gives such an implementation.
The methods of this class, which implements the MinPriorityQueue interface, are straightforward. The private method indexOfMinimum computes and returns the index in the array of the element with the smallest key. This method is called by the minimum and extractMin methods. extractMin seems a bit strange. Instead of always removing the smallest element, it moves the last element to the place where the smallest element was and then removes the last element. Why? Because removing the last element is faster than removing an element from the middle of the ArrayList.
Let's look at the worst-case running times of the min-priority queue operations in this implementation. We express them in terms of the number n of elements that will ever be in the min-priority queue at any one time.
isEmpty just returns a boolean indicating whether the size of the ArrayList is 0. This method takes constant time, or Θ(1).insert just adds a new reference at the end of the ArrayList, and so it takes Θ(1) amortized time.minimum and extractMin methods call indexOfMinimum to find the element with the smallest key. This helper method takes Θ(n) time to search through n elements, and therefore so do minimum and extractMin.ArrayListThe biggest disadvantage of implementing a min-priority queue by an unsorted ArrayList is that minimum and extractMin take Θ(n) time. We can get the running time of these operations down to Θ(1) if we keep the ArrayList sorted between operations. SortedArrayListMinPriorityQueue.java gives this implementation. An important detail is that it is sorted in decreasing order, so that the last position is the minimum.
The minimum method is simpler now: it just returns the element in position size-1 of the ArrayList. The extractMin method removes and returns the element in position size-1. Thus both of these operations take Θ(1) time.
The tradeoff is that, although minimum and extractMin now take only Θ(1) time, we find that insert takes O(n) time. So we have not improved matters by maintaining the array as sorted, unless we are making a lot more calls to minimum and extractMin than to insert. In practice, the number of calls to extractMin is often the same as the number of calls to insert, and so we gain no overall advantage from keeping the array sorted.
Can we do better? Yes, by using a data structure called a "heap."
Heaps are based on binary trees. We usually implement a heap in an array or an ArrayList, however.
A heap is a "nearly complete" binary tree. In other words, we fill in the tree from the root down toward the leaves, level by level, not starting a new level until we have filled the previous level. This is the shape property of a heap. For example, here's a heap and its representation in an array or ArrayList. Each node of the heap has its index in the array appearing above the node, and its contents appear within the node.
It's easy to compute the array index of a node's parent, left child, or right child, given the array index i of the node:
We will always store a heap in an array or ArrayList, but given this simple scheme for determining parent and child indices, it's always easy to interpret the array as a binary tree. If we were going to be excruciatingly accurate, we would always refer to "the node indexed by i," but we will instead use the less cumbersome language "node i."
There are actually two kinds of heaps: max-heaps and min-heaps. In both kinds, the values in the nodes satisfy a heap property, the specifics depending on whether we're talking about a max-heap or a min-heap.
In a max-heap, the nodes satisfy the max-heap property:
For every node i other than the root, the value in the parent of node i is greater than or equal to the value in node i.
In other words, the value in a node is at most the value in its parent. The largest value in a max-heap must be at the root, and this property holds for any subtree. The heap in the figure above is a max-heap.
A min-heap is defined in the opposite way, so that the min-heap property is
For every node i other than the root, the value in the parent of node i is less than or equal to the value in node i.
In other words, the value in a node is at least the value in its parent. The smallest value in any subtree of a min-heap must be at the root of the subtree.
We define the height of a heap to be the number of edges on the longest path from the root down to a leaf. The height of a heap with n nodes is Θ(lg n). (More precisely, the height is the greatest integer less than or equal to lg n.) Showing this property is not too hard, and the book does so on page 371.
We need to implement two operations that change a heap: insert and either extractMin or extractMax. Let's focus on a max-heap, so that we will implement extractMax. In both operations we want to maintain both the shape and heap properties. The trick is for both operations to fix the shape first, and then to fix the heap property.
Let's consider insert. Suppose we want to insert 15 in the heap shown above. By the shape property, it should go into the position to the right of the value 1, which would be position 10 in the array. (Representing the heap in an ArrayList makes this insertion particularly easy.) So if we put 15 into position 10 the shape property is statisfied:
But what about the heap property? Everything is fine, with the possible exception that the newly inserted element might have a key greater than that of its parent. (This is the case in our example.) But that problem is easy to fix: just swap the keys in the parent and the newly inserted child. Here's what we get:
Now we have the same problem, but moved up a level in the heap. Swap keys again:
Now the max-heap property holds everywhere. In general, we keep swapping keys in a node and its parent until the max-heap property is restored. We know that we'll stop eventually, because the highest up that the new key can go is the root.
What about extracting the maximum key? We know where it is; it is at the root, position 0 of the array. But simply removing it would leave a hole, which is not allowed:
Also, the heap has one fewer element, so that the rightmost leaf at the bottom level has to disappear. We can fix both of these shape problems by moving the rightmost leaf (the last element in the occupied portion of the array) to the root (position 0) and decrementing the size of the occupied portion of the array:
What does this do to the heap property? The left and right subtrees of the root are both valid heaps. But the root's key might be less than the key in one or both of its children. Again, this problem is easy to fix by swapping the root with its larger child. Its larger child will be greater than the original root, everything in its subtree, and the smaller child (and thus everything in the smaller child's subtree). Thus it is the largest key in the heap and should be the new root. But we might have moved the problem down into the subtree, because the value swapped into the subtree's root might violate the heap property of the subtree. In this example, it does:
But this is the same problem, and so we can repeat the operation, swapping the key in a node with the larger of its children until the max-heap property is restored. In our example, one more swap finishes up:
An implementation of a min-heap in an ArrayList is in HeapMinPriorityQueue.java. It shows how to implement the operations described above. Switching between max-heaps and min-heaps shouldn't throw you.
Let's look at the worst-case running times of the min-priority queue operations in this implementation. We express them in terms of the number n of elements that are in the min-priority queue when the operations occur.
isEmpty just returns a boolean indicating whether the size of the ArrayList is zero. This method takes constant time, or Θ(1).insert first adds a new reference at the end of the ArrayList, which takes Θ(1) amortized time. It then has to bubble the value up the heap until it is less than its parent. Each swap takes constant time, and the number of swaps is bounded by the height of the heap. Thus, insert takes O(lg n) time.minimum just returns what is in position 0 of the ArrayList, taking Θ(1) time.extractMin returns the element in position 0 and puts the last element in its place, taking Θ(1) time. It then has to restore the heap property, however, and so it has to bubble the new root down until it is smaller than both children or is a leaf. Like insert, this procedure takes O(lg n) time.A heap is the basis of a sorting algorithm called heapsort. Its running time is O(n lg n), and it sorts in place. That is, it needs no additional space for copying values (as merge sort does) or for a stack of recursive calls (as needed in quicksort and merge sort).
Heapsort has two major phases. You can see all the steps in this PowerPoint presentation. First, given an array of values in an unknown order, we have to rearrange the values to obey the max-heap property. That is, we have to build a heap. Then, once we've built the heap, we repeatedly pick out the maximum value in the heap—which we know is at the root—swap it with the last leaf in the heap, and restore the max-heap property. When we put the maximum value into the array position that had held the last leaf, we consider that array position to no longer be part of the heap.
The code for heapsort is in Heapsort.java. We've written it to sort an array, rather than an ArrayList, but you can easily modify it to sort an ArrayList. Or you can use the overloaded version that takes an ArrayList, converts it to an array, sorts the array, and then copies the sorted array back into the ArrayList. At the bottom, you can see some private methods that help out other methods in the class: swap, leftChild, and rightChild.
The obvious way to build a heap is to start with an unordered array. The first element is a valid heap. We can then insert the second element into the heap, then the third, etc. After we have inserted the last element, we have a valid heap. This idea works fine and leads to an O(n lg n)-time heapsort. We can avoid implementing the insert code and speed up the algorithm a bit, however, by building the heap from the bottom up rather than from the top down and using the same idea as when we restore the max-heap property during the extractMax operation.
The code to restore the max-heap property is in the maxHeapify method. It takes three parameters: the array a holding the heap and indices i and lastLeaf into the array. The maxHeapify method assumes that, when it is called, if you look at the subarray a[i..lastLeaf] (the subarray starting at index i and going through index lastLeaf), the max-heap property holds everywhere in this subarray, except possibly among node i and its children. maxHeapify restores the max-heap property everywhere in the subarray.
maxHeapify works as follows. It computes the indices left and right of the left and right children of node i, if it has such children. Node i has a left child if the index left is no greater than the index lastLeaf of the last leaf in the entire heap, and similarly for the right child.
maxHeapify then determines which node, out of node i and its children, has the greatest key value, storing the index of this node in the variable largest. First, if there's a left child, then whichever of node i and its left child has the larger value is stored in largest. Then, if there's a right child, whichever of the winner of the previous comparison and the right child has the larger value is stored in largest.
Once largest indexes the node with the largest value among node i and its children, we check to see whether we need to do anything. If largest equals i, then the max-heap property already is satisfied, and we're done. Otherwise, we swap the values in node i and node largest. By swapping, however, we have put a new, smaller value into node largest, which means that the max-heap property might be violated among node largest and its children. We call maxHeapify recursively, with largest taking on the role of i, to correct this possible violation.
Notice that in each recursive call of maxHeapify, the value taken on by i is one level further down in the heap. The total number of recursive calls we can make, therefore, is at most the height of the heap, which is Θ(lg n). Because we might not go all the way down to a leaf (remember that we stop once we find a node that does not violate the max-heap property), the total number of recursive calls of maxHeapify is O(lg n). Each call of maxHeapify takes constant time, not counting the time for the recursive calls. The total time for a call of maxHeapify, therefore, is O(lg n).
Now that we know how to correct a single violation of the max-heap property, we can build the entire heap from the bottom up. Suppose we were to call maxHeapify on each leaf. Nothing would change, because the only way that maxHeapify changes anything is when there's a violation of the max-heap property among a node and its children. Now suppose we called maxHeapify on each node that has at least one child that's a leaf. Then afterward, the max-heap property would hold at each of these nodes. But it might not hold at the parents of these nodes. So we can call maxHeapify on the parents of the nodes that we just fixed up, and then on the parents of these nodes, and so on, up to the root.
That's exactly how the buildMaxHeap method in Heapsort.java works. It computes the index lastNonLeaf of the highest-indexed non-leaf node, and then runs maxHeapify on nodes by decreasing index, all the way up to the root.
You can see how buildMaxHeap works on our example heap, including all the changes made by maxHeapify, by running the slide show in the PowerPoint presentation. Run it for 17 transitions, until you see the message "Heap is built."
Let's analyze how long it takes to build a heap. We run maxHeapify on at most half of the nodes, or at most n/2 nodes. We have already established that each call of maxHeapify takes O(lg n) time. The total time to build a heap, therefore, is O(n lg n).
Because we are shooting for a sorting algorithm that takes O(n lg n) time, we can be content with the analysis that says it takes O(n lg n) time to build a heap. It turns out, however, that a more rigorous analysis shows that the total time to run the buildMaxHeap method is only O(n). Notice that most of the calls of maxHeapify made by buildMaxHeap are on nodes close to a leaf. In fact, about half of the nodes are leaves and take no time, a quarter of the nodes are parents of leaves and require at most 1 swap, an eighth of the nodes are parents of the parents of leaves and take at most 2 swaps, and so on. If we sum the total number of swaps, it ends up being O(n).
The second phase of sorting is the while-loop in the heapsort method in Heapsort.java. After heapsort calls buildMaxHeap so that the array obeys the max-heap property, the while-loop sorts the array. You can see how it works on the example by running the rest of the slide show in the PowerPoint presentation.
Let's think about the array once the heap has been built. We know that the largest value is in the root, node 0. And we know that the largest value should go into the position currently occupied by the last leaf in the heap. So we swap these two values, and declare that the last position—where we just put the largest value—is no longer in the heap. That is, the heap occupies the first n − 1 slots of the array, not the first n. The local variable lastLeaf indexes the last leaf, and so we decrement it. By swapping a different value into the root, we might have caused a violation of the max-heap property at the root. Fortunately, we haven't touched any other nodes, and so we can call maxHeapify on the root to restore the max-heap property.
We now have a heap with n − 1 nodes. The nth slot of the array—a[n-1]—contains the largest element from the original array, and this slot is no longer in the heap. So we can now do the same thing, but now with the last leaf in a[n-2]. Afterward, the second-largest element is in a[n-2], this slot is no longer in the heap, and we have run maxHeapify on the root to restore the max-heap property. We continue on in this way, until the only node that we have not put into the heap is node 0, the root. By then, it must contain the smallest value, and we can just declare that we're done. (This idea is analogous to how we finish up selection sort, where we put the n − 1 smallest values into the first n − 1 slots of the array. We then declared that we were done, since the only remaining value must be the smallest, and it's already in its correct place.)
Analyzing this second phase is easy. The while-loop runs n − 1 times (once for each node other than node 0). In each iteration, swapping node values and decrementing lastLeaf take constant time. Each call of maxHeapify takes O(lg n) time, for a total of O(n lg n) time. Adding in the O(n lg n) time to build the heap gives a total sorting time of O(n lg n).