程序代写代做代考 scheme assembly Fortran algorithm file system ant Java flex assembler concurrency AI c++ Excel database DNA information theory discrete mathematics computer architecture cache AVL compiler Hive data structure decision tree chain 0132835061.pdf

1.5.7 Type Erasure
Generic types, for the most part, are constructs in the Java language but not in the Virtual
Machine. Generic classes are converted by the compiler to nongeneric classes by a pro-
cess known as type erasure. The simplified version of what happens is that the compiler
generates a raw class with the same name as the generic class with the type parameters
removed. The type variables are replaced with their bounds, and when calls are made

1.5 Implementing Generic Components Using Java 5 Generics 23

to generic methods that have an erased return type, casts are inserted automatically. If a
generic class is used without a type parameter, the raw class is used.

One important consequence of type erasure is that the generated code is not much
different than the code that programmers have been writing before generics and in fact is
not any faster. The significant benefit is that the programmer does not have to place casts
in the code, and the compiler will do significant type checking.

1.5.8 Restrictions on Generics
There are numerous restrictions on generic types. Every one of the restrictions listed here
is required because of type erasure.

Primitive Types
Primitive types cannot be used for a type parameter. Thus GenericMemoryCell is illegal.
You must use wrapper classes.

instanceof tests
instanceof tests and typecasts work only with raw type. In the following code

GenericMemoryCell cell1 = new GenericMemoryCell<>( );
cell1.write( 4 );
Object cell = cell1;
GenericMemoryCell cell2 = (GenericMemoryCell) cell;
String s = cell2.read( );

the typecast succeeds at runtime since all types are GenericMemoryCell. Eventually, a run-
time error results at the last line because the call to read tries to return a String but cannot.
As a result, the typecast will generate a warning, and a corresponding instanceof test is
illegal.

Static Contexts
In a generic class, static methods and fields cannot refer to the class’s type variables since,
after erasure, there are no type variables. Further, since there is really only one raw class,
static fields are shared among the class’s generic instantiations.

Instantiation of Generic Types
It is illegal to create an instance of a generic type. If T is a type variable, the statement

T obj = new T( ); // Right-hand side is illegal

is illegal. T is replaced by its bounds, which could be Object (or even an abstract class), so
the call to new cannot make sense.

Generic Array Objects
It is illegal to create an array of a generic type. If T is a type variable, the statement

T [ ] arr = new T[ 10 ]; // Right-hand side is illegal

24 Chapter 1 Introduction

is illegal. T would be replaced by its bounds, which would probably be Object, and then the
cast (generated by type erasure) to T[] would fail because Object[] IS-NOT-A T[]. Because
we cannot create arrays of generic objects, generally we must create an array of the erased
type and then use a typecast. This typecast will generate a compiler warning about an
unchecked type conversion.

Arrays of Parameterized Types
Instantiation of arrays of parameterized types is illegal. Consider the following code:

1 GenericMemoryCell [ ] arr1 = new GenericMemoryCell<>[ 10 ];
2 GenericMemoryCell cell = new GenericMemoryCell<>( ); cell.write( 4.5 );
3 Object [ ] arr2 = arr1;
4 arr2[ 0 ] = cell;
5 String s = arr1[ 0 ].read( );

Normally, we would expect that the assignment at line 4, which has the wrong type,
would generate an ArrayStoreException. However, after type erasure, the array type is
GenericMemoryCell[], and the object added to the array is GenericMemoryCell, so there is
no ArrayStoreException. Thus, this code has no casts, yet it will eventually generate a
ClassCastException at line 5, which is exactly the situation that generics are supposed to
avoid.

1.6 Function Objects
In Section 1.5, we showed how to write generic algorithms. As an example, the generic
method in Figure 1.16 can be used to find the maximum item in an array.

However, that generic method has an important limitation: It works only for objects
that implement the Comparable interface, using compareTo as the basis for all comparison
decisions. In many situations, this approach is not feasible. For instance, it is a stretch
to presume that a Rectangle class will implement Comparable, and even if it does, the
compareTo method that it has might not be the one we want. For instance, given a 2-by-10
rectangle and a 5-by-5 rectangle, which is the larger rectangle? The answer would depend
on whether we are using area or width to decide. Or perhaps if we are trying to fit the rect-
angle through an opening, the larger rectangle is the rectangle with the larger minimum
dimension. As a second example, if we wanted to find the maximum string (alphabeti-
cally last) in an array of strings, the default compareTo does not ignore case distinctions, so
“ZEBRA” would be considered to precede “alligator” alphabetically, which is probably not
what we want.

The solution in these situations is to rewrite findMax to accept two parameters: an array
of objects and a comparison function that explains how to decide which of two objects is
the larger and which is the smaller. In effect, the objects no longer know how to compare
themselves; instead, this information is completely decoupled from the objects in the array.

An ingenious way to pass functions as parameters is to notice that an object contains
both data and methods, so we can define a class with no data and one method and pass

1.6 Function Objects 25

1 // Generic findMax, with a function object.
2 // Precondition: a.size( ) > 0.
3 public static
4 AnyType findMax( AnyType [ ] arr, Comparator cmp )
5 {
6 int maxIndex = 0;
7
8 for( int i = 1; i < arr.size( ); i++ ) 9 if( cmp.compare( arr[ i ], arr[ maxIndex ] ) > 0 )

10 maxIndex = i;
11
12 return arr[ maxIndex ];
13 }
14
15 class CaseInsensitiveCompare implements Comparator
16 {
17 public int compare( String lhs, String rhs )
18 { return lhs.compareToIgnoreCase( rhs ); }
19 }
20
21 class TestProgram
22 {
23 public static void main( String [ ] args )
24 {
25 String [ ] arr = { “ZEBRA”, “alligator”, “crocodile” };
26 System.out.println( findMax( arr, new CaseInsensitiveCompare( ) ) )
27 }
28 }

Figure 1.18 Using a function object as a second parameter to findMax; output is ZEBRA

an instance of the class. In effect, a function is being passed by placing it inside an object.
This object is commonly known as a function object.

Figure 1.18 shows the simplest implementation of the function object idea. findMax
takes a second parameter, which is an object of type Comparator. The Comparator inter-
face is specified in java.util and contains a compare method. This interface is shown in
Figure 1.19.

Any class that implements the Comparator interface type must have a method
named compare that takes two parameters of the generic type (AnyType) and returns an int,
following the same general contract as compareTo. Thus, in Figure 1.18, the call to compare
at line 9 can be used to compare array items. The bounded wildcard at line 4 is used to
signal that if we are finding the maximum in an array of items, the comparator must know
how to compare items, or objects of the items’ supertype. To use this version of findMax, at
line 26, we can see that findMax is called by passing an array of String and an object that

26 Chapter 1 Introduction

1 package java.util;
2
3 public interface Comparator
4 {
5 int compare( AnyType lhs, AnyType rhs );
6 }

Figure 1.19 The Comparator interface

implements Comparator. This object is of type CaseInsensitiveCompare, which is a
class we write.

In Chapter 4, we will give an example of a class that needs to order the items it stores.
We will write most of the code using Comparable and show the adjustments needed to use
the function objects. Elsewhere in the book, we will avoid the detail of function objects to
keep the code as simple as possible, knowing that it is not difficult to add function objects
later.

Summary

This chapter sets the stage for the rest of the book. The time taken by an algorithm con-
fronted with large amounts of input will be an important criterion for deciding if it is a
good algorithm. (Of course, correctness is most important.) Speed is relative. What is fast
for one problem on one machine might be slow for another problem or a different machine.
We will begin to address these issues in the next chapter and will use the mathematics
discussed here to establish a formal model.

Exercises

1.1 Write a program to solve the selection problem. Let k = N/2. Draw a table showing
the running time of your program for various values of N.

1.2 Write a program to solve the word puzzle problem.

1.3 Write a method to output an arbitrary double number (which might be negative)
using only printDigit for I/O.

1.4 C allows statements of the form

#include filename

which reads filename and inserts its contents in place of the include statement.
Include statements may be nested; in other words, the file filename may itself con-
tain an include statement, but, obviously, a file can’t include itself in any chain.
Write a program that reads in a file and outputs the file as modified by the include
statements.

Exercises 27

1.5 Write a recursive method that returns the number of 1’s in the binary representation
of N. Use the fact that this is equal to the number of 1’s in the representation of N/2,
plus 1, if N is odd.

1.6 Write the routines with the following declarations:

public void permute( String str );
private void permute( char [ ] str, int low, int high );

The first routine is a driver that calls the second and prints all the permutations of
the characters in String str. If str is “abc”, then the strings that are output are abc,
acb, bac, bca, cab, and cba. Use recursion for the second routine.

1.7 Prove the following formulas:
a. log X < X for all X > 0
b. log(AB) = B log A

1.8 Evaluate the following sums:
a.

∑∞
i=0

1
4i

b.
∑∞

i=0
i

4i

�c.
∑∞

i=0
i2

4i
��d.

∑∞
i=0

iN

4i

1.9 Estimate

N∑
i=
N/2�

1

i

�1.10 What is 2100 (mod 5)?

1.11 Let Fi be the Fibonacci numbers as defined in Section 1.2. Prove the following:
a.

∑N−2
i=1 Fi = FN − 2

b. FN < φ N, with φ = (1 + √5)/2 ��c. Give a precise closed-form expression for FN. 1.12 Prove the following formulas: a. ∑N i=1(2i − 1) = N2 b. ∑N i=1i 3 = (∑N i=1i )2 1.13 Design a generic class, Collection, that stores a collection of Objects (in an array), along with the current size of the collection. Provide public methods isEmpty, makeEmpty, insert, remove, and isPresent. isPresent(x) returns true if and only if an Object that is equal to x (as defined by equals) is present in the collection. 1.14 Design a generic class, OrderedCollection, that stores a collection of Comparables (in an array), along with the current size of the collection. Provide public methods isEmpty, makeEmpty, insert, remove, findMin, and findMax. findMin and findMax return references to the smallest and largest, respectively, Comparable in the collection (or null if the collection is empty). 28 Chapter 1 Introduction 1.15 Define a Rectangle class that provides getLength and getWidth methods. Using the findMax routines in Figure 1.18, write a main that creates an array of Rectangle and finds the largest Rectangle first on the basis of area, and then on the basis of perimeter. References There are many good textbooks covering the mathematics reviewed in this chapter. A small subset is [1], [2], [3], [11], [13], and [14]. Reference [11] is specifically geared toward the analysis of algorithms. It is the first volume of a three-volume series that will be cited throughout this text. More advanced material is covered in [8]. Throughout this book we will assume a knowledge of Java [4], [6], [7]. The material in this chapter is meant to serve as an overview of the features that we will use in this text. We also assume familiarity with recursion (the recursion summary in this chapter is meant to be a quick review). We will attempt to provide hints on its use where appropriate throughout the textbook. Readers not familiar with recursion should consult [14] or any good intermediate programming textbook. General programming style is discussed in several books. Some of the classics are [5], [9], and [10]. 1. M. O. Albertson and J. P. Hutchinson, Discrete Mathematics with Algorithms, John Wiley & Sons, New York, 1988. 2. Z. Bavel, Math Companion for Computer Science, Reston Publishing Co., Reston, Va., 1982. 3. R. A. Brualdi, Introductory Combinatorics, North-Holland, New York, 1977. 4. G. Cornell and C. S. Horstmann, Core Java, Vol. I, 8th ed., Prentice Hall, Upper Saddle River, N.J., 2009. 5. E. W. Dijkstra, A Discipline of Programming, Prentice Hall, Englewood Cliffs, N.J., 1976. 6. D. Flanagan, Java in a Nutshell, 5th ed., O’Reilly and Associates, Sebastopol, Calif., 2005. 7. J. Gosling, B. Joy, G. Steele, and G. Bracha, The Java Language Specification, 3d ed., Addison- Wesley, Reading, Mass., 2005. 8. R. L. Graham, D. E. Knuth, and O. Patashnik, Concrete Mathematics, Addison-Wesley, Reading, Mass., 1989. 9. D. Gries, The Science of Programming, Springer-Verlag, New York, 1981. 10. B. W. Kernighan and P. J. Plauger, The Elements of Programming Style, 2d ed., McGraw-Hill, New York, 1978. 11. D. E. Knuth, The Art of Computer Programming, Vol. 1: Fundamental Algorithms, 3d ed., Addison-Wesley, Reading, Mass., 1997. 12. F. S. Roberts, Applied Combinatorics, Prentice Hall, Englewood Cliffs, N.J., 1984. 13. A. Tucker, Applied Combinatorics, 2d ed., John Wiley & Sons, New York, 1984. 14. M. A. Weiss, Data Structures and Problem Solving Using Java, 4th ed., Addison-Wesley, Boston, Mass., 2010. C H A P T E R 2 Algorithm Analysis An algorithm is a clearly specified set of simple instructions to be followed to solve a problem. Once an algorithm is given for a problem and decided (somehow) to be correct, an important step is to determine how much in the way of resources, such as time or space, the algorithm will require. An algorithm that solves a problem but requires a year is hardly of any use. Likewise, an algorithm that requires hundreds of gigabytes of main memory is not (currently) useful on most machines. In this chapter, we shall discuss � How to estimate the time required for a program. � How to reduce the running time of a program from days or years to fractions of a second. � The results of careless use of recursion. � Very efficient algorithms to raise a number to a power and to compute the greatest common divisor of two numbers. 2.1 Mathematical Background The analysis required to estimate the resource use of an algorithm is generally a theoretical issue, and therefore a formal framework is required. We begin with some mathematical definitions. Throughout the book we will use the following four definitions: Definition 2.1. T(N) = O(f(N)) if there are positive constants c and n0 such that T(N) ≤ cf(N) when N ≥ n0. Definition 2.2. T(N) = �(g(N)) if there are positive constants c and n0 such that T(N) ≥ cg(N) when N ≥ n0. Definition 2.3. T(N) = �(h(N)) if and only if T(N) = O(h(N)) and T(N) = �(h(N)). 29 30 Chapter 2 Algorithm Analysis Definition 2.4. T(N) = o(p(N)) if for all positive constants c there exists an n0 such that T(N) < cp(N) when N > n0. Less formally, T(N) = o(p(N)) if T(N) = O(p(N)) and T(N) �= �(p(N)).
The idea of these definitions is to establish a relative order among functions. Given two

functions, there are usually points where one function is smaller than the other function,
so it does not make sense to claim, for instance, f(N) < g(N). Thus, we compare their relative rates of growth. When we apply this to the analysis of algorithms, we shall see why this is the important measure. Although 1,000N is larger than N2 for small values of N, N2 grows at a faster rate, and thus N2 will eventually be the larger function. The turning point is N = 1,000 in this case. The first definition says that eventually there is some point n0 past which c · f(N) is always at least as large as T(N), so that if constant factors are ignored, f(N) is at least as big as T(N). In our case, we have T(N) = 1,000N, f(N) = N2, n0 = 1,000, and c = 1. We could also use n0 = 10 and c = 100. Thus, we can say that 1,000N = O(N2) (order N-squared). This notation is known as Big-Oh notation. Frequently, instead of saying “order . . . ,” one says “Big-Oh . . . .” If we use the traditional inequality operators to compare growth rates, then the first definition says that the growth rate of T(N) is less than or equal to (≤) that of f(N). The second definition, T(N) = �(g(N)) (pronounced “omega”), says that the growth rate of T(N) is greater than or equal to (≥) that of g(N). The third definition, T(N) = �(h(N)) (pronounced “theta”), says that the growth rate of T(N) equals (=) the growth rate of h(N). The last definition, T(N) = o(p(N)) (pronounced “little-oh”), says that the growth rate of T(N) is less than (<) the growth rate of p(N). This is different from Big-Oh, because Big-Oh allows the possibility that the growth rates are the same. To prove that some function T(N) = O(f(N)), we usually do not apply these defini- tions formally but instead use a repertoire of known results. In general, this means that a proof (or determination that the assumption is incorrect) is a very simple calculation and should not involve calculus, except in extraordinary circumstances (not likely to occur in an algorithm analysis). When we say that T(N) = O(f(N)), we are guaranteeing that the function T(N) grows at a rate no faster than f(N); thus f(N) is an upper bound on T(N). Since this implies that f(N) = �(T(N)), we say that T(N) is a lower bound on f(N). As an example, N3 grows faster than N2, so we can say that N2 = O(N3) or N3 = �(N2). f(N) = N2 and g(N) = 2N2 grow at the same rate, so both f(N) = O(g(N)) and f(N) = �(g(N)) are true. When two functions grow at the same rate, then the decision of whether or not to signify this with �() can depend on the particular context. Intuitively, if g(N) = 2N2, then g(N) = O(N4), g(N) = O(N3), and g(N) = O(N2) are all technically correct, but the last option is the best answer. Writing g(N) = �(N2) says not only that g(N) = O(N2), but also that the result is as good (tight) as possible. 2.1 Mathematical Background 31 Function Name c Constant log N Logarithmic log2 N Log-squared N Linear N log N N2 Quadratic N3 Cubic 2N Exponential Figure 2.1 Typical growth rates The important things to know are Rule 1. If T1(N) = O(f(N)) and T2(N) = O(g(N)), then (a) T1(N) + T2(N) = O(f(N) + g(N)) (intuitively and less formally it is O(max(f(N), g(N))) ), (b) T1(N) ∗ T2(N) = O(f(N) ∗ g(N)). Rule 2. If T(N) is a polynomial of degree k, then T(N) = �(Nk). Rule 3. logk N = O(N) for any constant k. This tells us that logarithms grow very slowly. This information is sufficient to arrange most of the common functions by growth rate (see Figure 2.1). Several points are in order. First, it is very bad style to include constants or low-order terms inside a Big-Oh. Do not say T(N) = O(2N2) or T(N) = O(N2 +N). In both cases, the correct form is T(N) = O(N2). This means that in any analysis that will require a Big-Oh answer, all sorts of shortcuts are possible. Lower-order terms can generally be ignored, and constants can be thrown away. Considerably less precision is required in these cases. Second, we can always determine the relative growth rates of two functions f(N) and g(N) by computing limN→∞ f(N)/g(N), using L’Hôpital’s rule if necessary.1 The limit can have four possible values: � The limit is 0: This means that f(N) = o(g(N)). � The limit is c �= 0: This means that f(N) = �(g(N)). 1 L’Hôpital’s rule states that if limN→∞ f(N) = ∞ and limN→∞ g(N) = ∞, then limN→∞ f(N)/g(N) = limN→∞ f ′(N)/g′(N), where f ′(N) and g′(N) are the derivatives of f(N) and g(N), respectively. 32 Chapter 2 Algorithm Analysis � The limit is ∞: This means that g(N) = o(f(N)). � The limit does not exist: There is no relation (this will not happen in our context). Using this method almost always amounts to overkill. Usually the relation between f(N) and g(N) can be derived by simple algebra. For instance, if f(N) = N log N and g(N) = N1.5, then to decide which of f(N) and g(N) grows faster, one really needs to determine which of log N and N0.5 grows faster. This is like determining which of log2 N or N grows faster. This is a simple problem, because it is already known that N grows faster than any power of a log. Thus, g(N) grows faster than f(N). One stylistic note: It is bad to say f(N) ≤ O(g(N)), because the inequality is implied by the definition. It is wrong to write f(N) ≥ O(g(N)), which does not make sense. As an example of the typical kinds of analysis that are performed, consider the problem of downloading a file over the Internet. Suppose there is an initial 3-sec delay (to set up a connection), after which the download proceeds at 1.5 M(bytes)/sec. Then it follows that if the file is N megabytes, the time to download is described by the formula T(N) = N/1.5 + 3. This is a linear function. Notice that the time to download a 1,500M file (1,003 sec) is approximately (but not exactly) twice the time to download a 750M file (503 sec). This is typical of a linear function. Notice, also, that if the speed of the connection doubles, both times decrease, but the 1,500M file still takes approximately twice the time to download as a 750M file. This is the typical characteristic of linear-time algorithms, and it is why we write T(N) = O(N), ignoring constant factors. (Although using Big-Theta would be more precise, Big-Oh answers are typically given.) Observe, too, that this behavior is not true of all algorithms. For the first selection algorithm described in Section 1.1, the running time is controlled by the time it takes to perform a sort. For a simple sorting algorithm, such as the suggested bubble sort, when the amount of input doubles, the running time increases by a factor of four for large amounts of input. This is because those algorithms are not linear. Instead, as we will see when we discuss sorting, trivial sorting algorithms are O(N2), or quadratic. 2.2 Model In order to analyze algorithms in a formal framework, we need a model of computation. Our model is basically a normal computer, in which instructions are executed sequentially. Our model has the standard repertoire of simple instructions, such as addition, multipli- cation, comparison, and assignment, but, unlike the case with real computers, it takes exactly one time unit to do anything (simple). To be reasonable, we will assume that, like a modern computer, our model has fixed-size (say, 32-bit) integers and that there are no fancy operations, such as matrix inversion or sorting, that clearly cannot be done in one time unit. We also assume infinite memory. This model clearly has some weaknesses. Obviously, in real life, not all operations take exactly the same time. In particular, in our model one disk read counts the same as an addition, even though the addition is typically several orders of magnitude faster. Also, by assuming infinite memory, we ignore the fact that the cost of a memory access can increase when slower memory is used due to larger memory requirements. 2.3 What to Analyze 33 2.3 What to Analyze The most important resource to analyze is generally the running time. Several factors affect the running time of a program. Some, such as the compiler and computer used, are obviously beyond the scope of any theoretical model, so, although they are important, we cannot deal with them here. The other main factors are the algorithm used and the input to the algorithm. Typically, the size of the input is the main consideration. We define two functions, Tavg(N) and Tworst(N), as the average and worst-case running time, respectively, used by an algorithm on input of size N. Clearly, Tavg(N) ≤ Tworst(N). If there is more than one input, these functions may have more than one argument. Occasionally the best-case performance of an algorithm is analyzed. However, this is often of little interest, because it does not represent typical behavior. Average-case perfor- mance often reflects typical behavior, while worst-case performance represents a guarantee for performance on any possible input. Notice, also, that, although in this chapter we ana- lyze Java code, these bounds are really bounds for the algorithms rather than programs. Programs are an implementation of the algorithm in a particular programming language, and almost always the details of the programming language do not affect a Big-Oh answer. If a program is running much more slowly than the algorithm analysis suggests, there may be an implementation inefficiency. This is more common in languages (like C++) where arrays can be inadvertently copied in their entirety, instead of passed with references. However, this can occur in Java, too. Thus in future chapters we will analyze the algorithms rather than the programs. Generally, the quantity required is the worst-case time, unless otherwise specified. One reason for this is that it provides a bound for all input, including particularly bad input, which an average-case analysis does not provide. The other reason is that average-case bounds are usually much more difficult to compute. In some instances, the definition of “average” can affect the result. (For instance, what is average input for the following problem?) As an example, in the next section, we shall consider the following problem: Maximum Subsequence Sum Problem. Given (possibly negative) integers A1, A2, . . . , AN, find the maximum value of ∑j k=i Ak. (For convenience, the maximum subsequence sum is 0 if all the integers are negative.) Example: For input −2, 11, −4, 13, −5, −2, the answer is 20 (A2 through A4). This problem is interesting mainly because there are so many algorithms to solve it, and the performance of these algorithms varies drastically. We will discuss four algo- rithms to solve this problem. The running time on some computer (the exact computer is unimportant) for these algorithms is given in Figure 2.2. There are several important things worth noting in this table. For a small amount of input, the algorithms all run in a blink of the eye, so if only a small amount of input is expected, it might be silly to expend a great deal of effort to design a clever algorithm. On the other hand, there is a large market these days for rewriting programs that were written five years ago based on a no-longer-valid assumption of small input size. These 34 Chapter 2 Algorithm Analysis Algorithm Time Input 1 2 3 4 Size O(N3) O(N2) O(N log N) O(N) N = 100 0.000159 0.000006 0.000005 0.000002 N = 1,000 0.095857 0.000371 0.000060 0.000022 N = 10,000 86.67 0.033322 0.000619 0.000222 N = 100,000 NA 3.33 0.006700 0.002205 N = 1,000,000 NA NA 0.074870 0.022711 Figure 2.2 Running times of several algorithms for maximum subsequence sum (in seconds) programs are now too slow, because they used poor algorithms. For large amounts of input, algorithm 4 is clearly the best choice (although algorithm 3 is still usable). Second, the times given do not include the time required to read the input. For algo- rithm 4, the time merely to read in the input from a disk is likely to be an order of magnitude larger than the time required to solve the problem. This is typical of many efficient algorithms. Reading the data is generally the bottleneck; once the data are read, the problem can be solved quickly. For inefficient algorithms this is not true, and significant computer resources must be used. Thus it is important that, whenever possible, algorithms be efficient enough not to be the bottleneck of a problem. Notice that algorithm 4, which is linear, exhibits the nice behavior that as the prob- lem size increases by a factor of ten, the running time also increases by a factor of ten. 0 R un ni ng T im e 10 20 30 40 50 60 70 80 90 100 Input Size (N) Linear O(N log N ) Quadratic Cubic Figure 2.3 Plot (N vs. time) of various algorithms 2.4 Running Time Calculations 35 0 0 R un ni ng T im e 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Input Size (N) Linear O(N log N ) Quadratic Cubic Figure 2.4 Plot (N vs. time) of various algorithms Algorithm 2, which is quadratic, does not have this behavior; a tenfold increase in input size yields roughly a hundredfold (102) increase in running time. And algorithm 1, which is cubic, yields a thousandfold (103) increase in running time. We would expect algorithm 1 to take nearly 9,000 seconds (or two and half hours) to complete for N = 100,000. Similarly, we would expect algorithm 2 to take roughly 333 seconds to complete for N = 1,000,000. However, it is possible that Algorithm 2 could take somewhat longer to complete due to the fact that N = 1,000,000 could also yield slower memory accesses than N = 100,000 on modern computers, depending on the size of the memory cache. Figure 2.3 shows the growth rates of the running times of the four algorithms. Even though this graph encompasses only values of N ranging from 10 to 100, the relative growth rates are still evident. Although the graph for the O(N log N) algorithm seems linear, it is easy to verify that it is not by using a straight-edge (or piece of paper). Although the graph for the O(N) algorithm seems constant, this is only because for small values of N, the constant term is larger than the linear term. Figure 2.4 shows the performance for larger values. It dramatically illustrates how useless inefficient algorithms are for even moderately large amounts of input. 2.4 Running Time Calculations There are several ways to estimate the running time of a program. The previous table was obtained empirically. If two programs are expected to take similar times, probably the best way to decide which is faster is to code them both up and run them! 36 Chapter 2 Algorithm Analysis Generally, there are several algorithmic ideas, and we would like to eliminate the bad ones early, so an analysis is usually required. Furthermore, the ability to do an analysis usually provides insight into designing efficient algorithms. The analysis also generally pinpoints the bottlenecks, which are worth coding carefully. To simplify the analysis, we will adopt the convention that there are no particular units of time. Thus, we throw away leading constants. We will also throw away low-order terms, so what we are essentially doing is computing a Big-Oh running time. Since Big-Oh is an upper bound, we must be careful never to underestimate the running time of the program. In effect, the answer provided is a guarantee that the program will terminate within a certain time period. The program may stop earlier than this, but never later. 2.4.1 A Simple Example Here is a simple program fragment to calculate ∑N i=1 i 3: public static int sum( int n ) { int partialSum; 1 partialSum = 0; 2 for( int i = 1; i <= n; i++ ) 3 partialSum += i * i * i; 4 return partialSum; } The analysis of this fragment is simple. The declarations count for no time. Lines 1 and 4 count for one unit each. Line 3 counts for four units per time executed (two multiplica- tions, one addition, and one assignment) and is executed N times, for a total of 4N units. Line 2 has the hidden costs of initializing i, testing i ≤ N, and incrementing i. The total cost of all these is 1 to initialize, N + 1 for all the tests, and N for all the increments, which is 2N + 2. We ignore the costs of calling the method and returning, for a total of 6N + 4. Thus, we say that this method is O(N). If we had to perform all this work every time we needed to analyze a program, the task would quickly become infeasible. Fortunately, since we are giving the answer in terms of Big-Oh, there are lots of shortcuts that can be taken without affecting the final answer. For instance, line 3 is obviously an O(1) statement (per execution), so it is silly to count precisely whether it is two, three, or four units; it does not matter. Line 1 is obviously insignificant compared with the for loop, so it is silly to waste time here. This leads to several general rules. 2.4.2 General Rules Rule 1—for loops. The running time of a for loop is at most the running time of the statements inside the for loop (including tests) times the number of iterations. 2.4 Running Time Calculations 37 Rule 2—Nested loops. Analyze these inside out. The total running time of a statement inside a group of nested loops is the running time of the statement multiplied by the product of the sizes of all the loops. As an example, the following program fragment is O(N2): for( i = 0; i < n; i++ ) for( j = 0; j < n; j++ ) k++; Rule 3—Consecutive Statements. These just add (which means that the maximum is the one that counts; see rule 1(a) on page 31). As an example, the following program fragment, which has O(N) work followed by O(N2) work, is also O(N2): for( i = 0; i < n; i++ ) a[ i ] = 0; for( i = 0; i < n; i++ ) for( j = 0; j < n; j++ ) a[ i ] += a[ j ] + i + j; Rule 4—if/else. For the fragment if( condition ) S1 else S2 the running time of an if/else statement is never more than the running time of the test plus the larger of the running times of S1 and S2. Clearly, this can be an overestimate in some cases, but it is never an underestimate. Other rules are obvious, but a basic strategy of analyzing from the inside (or deepest part) out works. If there are method calls, these must be analyzed first. If there are recursive methods, there are several options. If the recursion is really just a thinly veiled for loop, the analysis is usually trivial. For instance, the following method is really just a simple loop and is O(N): public static long factorial( int n ) { if( n <= 1 ) return 1; else return n * factorial( n - 1 ); } 38 Chapter 2 Algorithm Analysis This example is really a poor use of recursion. When recursion is properly used, it is difficult to convert the recursion into a simple loop structure. In this case, the analysis will involve a recurrence relation that needs to be solved. To see what might happen, consider the following program, which turns out to be a horrible use of recursion: public static long fib( int n ) { 1 if( n <= 1 ) 2 return 1; else 3 return fib( n - 1 ) + fib( n - 2 ); } At first glance, this seems like a very clever use of recursion. However, if the program is coded up and run for values of N around 40, it becomes apparent that this program is terribly inefficient. The analysis is fairly simple. Let T(N) be the running time for the method call fib(n). If N = 0 or N = 1, then the running time is some constant value, which is the time to do the test at line 1 and return. We can say that T(0) = T(1) = 1 because constants do not matter. The running time for other values of N is then measured relative to the running time of the base case. For N > 2, the time to execute the method is
the constant work at line 1 plus the work at line 3. Line 3 consists of an addition and two
method calls. Since the method calls are not simple operations, they must be analyzed by
themselves. The first method call is fib(n – 1) and hence, by the definition of T, requires
T(N − 1) units of time. A similar argument shows that the second method call requires
T(N − 2) units of time. The total time required is then T(N − 1) + T(N − 2) + 2, where the
2 accounts for the work at line 1 plus the addition at line 3. Thus, for N ≥ 2, we have the
following formula for the running time of fib(n):

T(N) = T(N − 1) + T(N − 2) + 2
Since fib(N) = fib(N − 1) + fib(N − 2), it is easy to show by induction that T(N) ≥ fib(N).
In Section 1.2.5, we showed that fib(N) < (5/3)N. A similar calculation shows that (for N > 4) fib(N) ≥ (3/2)N, and so the running time of this program grows exponentially. This
is about as bad as possible. By keeping a simple array and using a for loop, the running
time can be reduced substantially.

This program is slow because there is a huge amount of redundant work being per-
formed, violating the fourth major rule of recursion (the compound interest rule), which
was presented in Section 1.3. Notice that the first call on line 3, fib(n – 1), actually com-
putes fib(n – 2) at some point. This information is thrown away and recomputed by the
second call on line 3. The amount of information thrown away compounds recursively and
results in the huge running time. This is perhaps the finest example of the maxim “Don’t
compute anything more than once” and should not scare you away from using recursion.
Throughout this book, we shall see outstanding uses of recursion.

2.4 Running Time Calculations 39

2.4.3 Solutions for the Maximum Subsequence
Sum Problem

We will now present four algorithms to solve the maximum subsequence sum prob-
lem posed earlier. The first algorithm, which merely exhaustively tries all possibilities,
is depicted in Figure 2.5. The indices in the for loop reflect the fact that in Java, arrays
begin at 0, instead of 1. Also, the algorithm does not compute the actual subsequences;
additional code is required to do this.

Convince yourself that this algorithm works (this should not take much convincing).
The running time is O(N3) and is entirely due to lines 13 and 14, which consist of an O(1)
statement buried inside three nested for loops. The loop at line 8 is of size N.

The second loop has size N − i which could be small but could also be of size N. We
must assume the worst, with the knowledge that this could make the final bound a bit
high. The third loop has size j − i + 1, which, again, we must assume is of size N. The total
is O(1 · N · N · N) = O(N3). Line 6 takes only O(1) total, and lines 16 and 17 take only
O(N2) total, since they are easy expressions inside only two loops.

It turns out that a more precise analysis, taking into account the actual size of these
loops, shows that the answer is �(N3) and that our estimate above was a factor of 6 too
high (which is all right, because constants do not matter). This is generally true in these
kinds of problems. The precise analysis is obtained from the sum

∑N−1
i=0

∑N−1
j=i

∑j
k=i 1,

1 /**
2 * Cubic maximum contiguous subsequence sum algorithm.
3 */
4 public static int maxSubSum1( int [ ] a )
5 {
6 int maxSum = 0;
7
8 for( int i = 0; i < a.length; i++ ) 9 for( int j = i; j < a.length; j++ ) 10 { 11 int thisSum = 0; 12 13 for( int k = i; k <= j; k++ ) 14 thisSum += a[ k ]; 15 16 if( thisSum > maxSum )
17 maxSum = thisSum;
18 }
19
20 return maxSum;
21 }

Figure 2.5 Algorithm 1

40 Chapter 2 Algorithm Analysis

which tells how many times line 14 is executed. The sum can be evaluated inside out,
using formulas from Section 1.2.3. In particular, we will use the formulas for the sum of
the first N integers and first N squares. First we have

j∑
k=i

1 = j − i + 1

Next we evaluate

N−1∑
j=i

(j − i + 1) = (N − i + 1)(N − i)
2

This sum is computed by observing that it is just the sum of the first N − i integers. To
complete the calculation, we evaluate

N−1∑
i=0

(N − i + 1)(N − i)
2

=
N∑

i=1

(N − i + 1)(N − i + 2)
2

= 1
2

N∑
i=1

i2 −
(

N + 3
2

) N∑
i=1

i + 1
2

(N2 + 3N + 2)
N∑

i=1
1

= 1
2

N(N + 1)(2N + 1)
6

−
(

N + 3
2

)
N(N + 1)

2
+ N

2 + 3N + 2
2

N

= N
3 + 3N2 + 2N

6

We can avoid the cubic running time by removing a for loop. This is not always pos-
sible, but in this case there are an awful lot of unnecessary computations present in the
algorithm. The inefficiency that the improved algorithm corrects can be seen by noticing

that
∑j

k=i Ak = Aj +
∑j−1

k=i Ak, so the computation at lines 13 and 14 in algorithm 1 is
unduly expensive. Figure 2.6 shows an improved algorithm. Algorithm 2 is clearly O(N2);
the analysis is even simpler than before.

There is a recursive and relatively complicated O(N log N) solution to this problem,
which we now describe. If there didn’t happen to be an O(N) (linear) solution, this would
be an excellent example of the power of recursion. The algorithm uses a “divide-and-
conquer” strategy. The idea is to split the problem into two roughly equal subproblems,
which are then solved recursively. This is the “divide” part. The “conquer” stage consists
of patching together the two solutions of the subproblems, and possibly doing a small
amount of additional work, to arrive at a solution for the whole problem.

In our case, the maximum subsequence sum can be in one of three places. Either it
occurs entirely in the left half of the input, or entirely in the right half, or it crosses the
middle and is in both halves. The first two cases can be solved recursively. The last case
can be obtained by finding the largest sum in the first half that includes the last element

2.4 Running Time Calculations 41

1 /**
2 * Quadratic maximum contiguous subsequence sum algorithm.
3 */
4 public static int maxSubSum2( int [ ] a )
5 {
6 int maxSum = 0;
7
8 for( int i = 0; i < a.length; i++ ) 9 { 10 int thisSum = 0; 11 for( int j = i; j < a.length; j++ ) 12 { 13 thisSum += a[ j ]; 14 15 if( thisSum > maxSum )
16 maxSum = thisSum;
17 }
18 }
19
20 return maxSum;
21 }

Figure 2.6 Algorithm 2

in the first half, and the largest sum in the second half that includes the first element in
the second half. These two sums can then be added together. As an example, consider the
following input:

First Half Second Half

4 −3 5 −2 −1 2 6 −2

The maximum subsequence sum for the first half is 6 (elements A1 through A3) and for
the second half is 8 (elements A6 through A7).

The maximum sum in the first half that includes the last element in the first half is 4
(elements A1 through A4), and the maximum sum in the second half that includes the first
element in the second half is 7 (elements A5 through A7). Thus, the maximum sum that
spans both halves and goes through the middle is 4 + 7 = 11 (elements A1 through A7).

We see, then, that among the three ways to form a large maximum subsequence, for
our example, the best way is to include elements from both halves. Thus, the answer is 11.
Figure 2.7 shows an implementation of this strategy.

The code for algorithm 3 deserves some comment. The general form of the call for the
recursive method is to pass the input array along with the left and right borders, which

42 Chapter 2 Algorithm Analysis

1 /**
2 * Recursive maximum contiguous subsequence sum algorithm.
3 * Finds maximum sum in subarray spanning a[left..right].
4 * Does not attempt to maintain actual best sequence.
5 */
6 private static int maxSumRec( int [ ] a, int left, int right )
7 {
8 if( left == right ) // Base case
9 if( a[ left ] > 0 )

10 return a[ left ];
11 else
12 return 0;
13
14 int center = ( left + right ) / 2;
15 int maxLeftSum = maxSumRec( a, left, center );
16 int maxRightSum = maxSumRec( a, center + 1, right );
17
18 int maxLeftBorderSum = 0, leftBorderSum = 0;
19 for( int i = center; i >= left; i– )
20 {
21 leftBorderSum += a[ i ];
22 if( leftBorderSum > maxLeftBorderSum )
23 maxLeftBorderSum = leftBorderSum;
24 }
25
26 int maxRightBorderSum = 0, rightBorderSum = 0;
27 for( int i = center + 1; i <= right; i++ ) 28 { 29 rightBorderSum += a[ i ]; 30 if( rightBorderSum > maxRightBorderSum )
31 maxRightBorderSum = rightBorderSum;
32 }
33
34 return max3( maxLeftSum, maxRightSum,
35 maxLeftBorderSum + maxRightBorderSum );
36 }
37
38 /**
39 * Driver for divide-and-conquer maximum contiguous
40 * subsequence sum algorithm.
41 */
42 public static int maxSubSum3( int [ ] a )
43 {
44 return maxSumRec( a, 0, a.length – 1 );
45 }

Figure 2.7 Algorithm 3

2.4 Running Time Calculations 43

delimit the portion of the array that is operated upon. A one-line driver program sets this
up by passing the borders 0 and N − 1 along with the array.

Lines 8 to 12 handle the base case. If left == right, there is one element, and it is the
maximum subsequence if the element is nonnegative. The case left > right is not possible
unless N is negative (although minor perturbations in the code could mess this up). Lines
15 and 16 perform the two recursive calls. We can see that the recursive calls are always
on a smaller problem than the original, although minor perturbations in the code could
destroy this property. Lines 18 to 24 and 26 to 32 calculate the two maximum sums that
touch the center divider. The sum of these two values is the maximum sum that spans both
halves. The routine max3 (not shown) returns the largest of the three possibilities.

Algorithm 3 clearly requires more effort to code than either of the two previous algo-
rithms. However, shorter code does not always mean better code. As we have seen in the
earlier table showing the running times of the algorithms, this algorithm is considerably
faster than the other two for all but the smallest of input sizes.

The running time is analyzed in much the same way as for the program that computes
the Fibonacci numbers. Let T(N) be the time it takes to solve a maximum subsequence
sum problem of size N. If N = 1, then the program takes some constant amount of time
to execute lines 8 to 12, which we shall call one unit. Thus, T(1) = 1. Otherwise, the
program must perform two recursive calls, the two for loops between lines 19 and 32, and
some small amount of bookkeeping, such as lines 14 and 18. The two for loops combine
to touch every element in the subarray, and there is constant work inside the loops, so the
time expended in lines 19 to 32 is O(N). The code in lines 8 to 14, 18, 26, and 34 is all
a constant amount of work and can thus be ignored compared with O(N). The remainder
of the work is performed in lines 15 and 16. These lines solve two subsequence problems
of size N/2 (assuming N is even). Thus, these lines take T(N/2) units of time each, for a
total of 2T(N/2). The total time for the algorithm then is 2T(N/2) + O(N). This gives the
equations

T(1) = 1
T(N) = 2T(N/2) + O(N)

To simplify the calculations, we can replace the O(N) term in the equation above with
N; since T(N) will be expressed in Big-Oh notation anyway, this will not affect the answer.
In Chapter 7, we shall see how to solve this equation rigorously. For now, if T(N) =
2T(N/2)+N, and T(1) = 1, then T(2) = 4 = 2∗2, T(4) = 12 = 4∗3, T(8) = 32 = 8∗4,
and T(16) = 80 = 16∗5. The pattern that is evident, and can be derived, is that if N = 2k,
then T(N) = N ∗ (k + 1) = N log N + N = O(N log N).

This analysis assumes N is even, since otherwise N/2 is not defined. By the recursive
nature of the analysis, it is really valid only when N is a power of 2, since otherwise we
eventually get a subproblem that is not an even size, and the equation is invalid. When
N is not a power of 2, a somewhat more complicated analysis is required, but the Big-Oh
result remains unchanged.

In future chapters, we will see several clever applications of recursion. Here, we present
a fourth algorithm to find the maximum subsequence sum. This algorithm is simpler to
implement than the recursive algorithm and also is more efficient. It is shown in Figure 2.8.

44 Chapter 2 Algorithm Analysis

1 /**
2 * Linear-time maximum contiguous subsequence sum algorithm.
3 */
4 public static int maxSubSum4( int [ ] a )
5 {
6 int maxSum = 0, thisSum = 0;
7
8 for( int j = 0; j < a.length; j++ ) 9 { 10 thisSum += a[ j ]; 11 12 if( thisSum > maxSum )
13 maxSum = thisSum;
14 else if( thisSum < 0 ) 15 thisSum = 0; 16 } 17 18 return maxSum; 19 } Figure 2.8 Algorithm 4 It should be clear why the time bound is correct, but it takes a little thought to see why the algorithm actually works. To sketch the logic, note that, like algorithms 1 and 2, j is representing the end of the current sequence, while i is representing the start of the current sequence. It happens that the use of i can be optimized out of the program if we do not need to know where the actual best subsequence is, so in designing the algorithm, let’s pretend that i is needed, and that we are trying to improve algorithm 2. One observation is that if a[i] is negative, then it cannot possibly represent the start of the optimal sequence, since any subsequence that begins by including a[i] would be improved by beginning with a[i+1]. Similarly, any negative subsequence cannot possibly be a prefix of the optimal subsequence (same logic). If, in the inner loop, we detect that the subsequence from a[i] to a[j] is negative, then we can advance i. The crucial observation is that not only can we advance i to i+1, but we can also actually advance it all the way to j+1. To see this, let p be any index between i+1 and j. Any subsequence that starts at index p is not larger than the corresponding subsequence that starts at index i and includes the subsequence from a[i] to a[p-1], since the latter subsequence is not negative (j is the first index that causes the subsequence starting at index i to become negative). Thus advancing i to j+1 is risk free: we cannot miss an optimal solution. This algorithm is typical of many clever algorithms: The running time is obvious, but the correctness is not. For these algorithms, formal correctness proofs (more formal than the sketch above) are almost always required; even then, however, many people still are not convinced. In addition, many of these algorithms require trickier programming, leading to longer development. But when these algorithms work, they run quickly, and we can 2.4 Running Time Calculations 45 test much of the code logic by comparing it with an inefficient (but easily implemented) brute-force algorithm using small input sizes. An extra advantage of this algorithm is that it makes only one pass through the data, and once a[i] is read and processed, it does not need to be remembered. Thus, if the array is on a disk or is being transmitted over the Internet, it can be read sequentially, and there is no need to store any part of it in main memory. Furthermore, at any point in time, the algorithm can correctly give an answer to the subsequence problem for the data it has already read (the other algorithms do not share this property). Algorithms that can do this are called online algorithms. An online algorithm that requires only constant space and runs in linear time is just about as good as possible. 2.4.4 Logarithms in the Running Time The most confusing aspect of analyzing algorithms probably centers around the logarithm. We have already seen that some divide-and-conquer algorithms will run in O(N log N) time. Besides divide-and-conquer algorithms, the most frequent appearance of logarithms centers around the following general rule: An algorithm is O(log N) if it takes constant (O(1)) time to cut the problem size by a fraction (which is usually 12 ). On the other hand, if constant time is required to merely reduce the problem by a constant amount (such as to make the problem smaller by 1), then the algorithm is O(N). It should be obvious that only special kinds of problems can be O(log N). For instance, if the input is a list of N numbers, an algorithm must take �(N) merely to read the input in. Thus, when we talk about O(log N) algorithms for these kinds of problems, we usually presume that the input is preread. We provide three examples of logarithmic behavior. Binary Search The first example is usually referred to as binary search. Binary Search. Given an integer X and integers A0, A1, . . . , AN−1, which are presorted and already in memory, find i such that Ai = X, or return i = −1 if X is not in the input. The obvious solution consists of scanning through the list from left to right and runs in linear time. However, this algorithm does not take advantage of the fact that the list is sorted and is thus not likely to be best. A better strategy is to check if X is the middle element. If so, the answer is at hand. If X is smaller than the middle element, we can apply the same strategy to the sorted subarray to the left of the middle element; likewise, if X is larger than the middle element, we look to the right half. (There is also the case of when to stop.) Figure 2.9 shows the code for binary search (the answer is mid). As usual, the code reflects Java’s convention that arrays begin with index 0. Clearly, all the work done inside the loop takes O(1) per iteration, so the analysis requires determining the number of times around the loop. The loop starts with high - low = N − 1 and finishes with high - low ≥ −1. Every time through the loop the value high - low must be at least halved from its previous value; thus, the number of times around the loop is at most �log(N − 1)� + 2. (As an example, if high - low = 128, then 46 Chapter 2 Algorithm Analysis 1 /** 2 * Performs the standard binary search. 3 * @return index where item is found, or -1 if not found. 4 */ 5 public static >
6 int binarySearch( AnyType [ ] a, AnyType x )
7 {
8 int low = 0, high = a.length – 1;
9

10 while( low <= high ) 11 { 12 int mid = ( low + high ) / 2; 13 14 if( a[ mid ].compareTo( x ) < 0 ) 15 low = mid + 1; 16 else if( a[ mid ].compareTo( x ) > 0 )
17 high = mid – 1;
18 else
19 return mid; // Found
20 }
21 return NOT_FOUND; // NOT_FOUND is defined as -1
22 }

Figure 2.9 Binary search

the maximum values of high – low after each iteration are 64, 32, 16, 8, 4, 2, 1, 0, −1.)
Thus, the running time is O(log N). Equivalently, we could write a recursive formula for
the running time, but this kind of brute-force approach is usually unnecessary when you
understand what is really going on and why.

Binary search can be viewed as our first data structure implementation. It supports the
contains operation in O(log N) time, but all other operations (in particular insert) require
O(N) time. In applications where the data are static (that is, insertions and deletions are
not allowed), this could be very useful. The input would then need to be sorted once,
but afterward accesses would be fast. An example is a program that needs to maintain
information about the periodic table of elements (which arises in chemistry and physics).
This table is relatively stable, as new elements are added infrequently. The element names
could be kept sorted. Since there are only about 118 elements, at most eight accesses would
be required to find an element. Performing a sequential search would require many more
accesses.

Euclid’s Algorithm
A second example is Euclid’s algorithm for computing the greatest common divisor. The
greatest common divisor (gcd) of two integers is the largest integer that divides both. Thus,
gcd(50, 15) = 5. The algorithm in Figure 2.10 computes gcd(M, N), assuming M ≥ N. (If
N > M, the first iteration of the loop swaps them.)

2.4 Running Time Calculations 47

1 public static long gcd( long m, long n )
2 {
3 while( n != 0 )
4 {
5 long rem = m % n;
6 m = n;
7 n = rem;
8 }
9 return m;

10 }

Figure 2.10 Euclid’s algorithm

The algorithm works by continually computing remainders until 0 is reached. The last
nonzero remainder is the answer. Thus, if M = 1,989 and N = 1,590, then the sequence
of remainders is 399, 393, 6, 3, 0. Therefore, gcd(1989, 1590) = 3. As the example shows,
this is a fast algorithm.

As before, estimating the entire running time of the algorithm depends on determining
how long the sequence of remainders is. Although log N seems like a good answer, it is not
at all obvious that the value of the remainder has to decrease by a constant factor, since we
see that the remainder went from 399 to only 393 in the example. Indeed, the remainder
does not decrease by a constant factor in one iteration. However, we can prove that after
two iterations, the remainder is at most half of its original value. This would show that the
number of iterations is at most 2 log N = O(log N) and establish the running time. This
proof is easy, so we include it here. It follows directly from the following theorem.

Theorem 2.1.
If M > N, then M mod N < M/2. Proof. There are two cases. If N ≤ M/2, then since the remainder is smaller than N, the theorem is true for this case. The other case is N > M/2. But then N goes into M once
with a remainder M − N < M/2, proving the theorem. One might wonder if this is the best bound possible, since 2 log N is about 20 for our example, and only seven operations were performed. It turns out that the constant can be improved slightly, to roughly 1.44 log N, in the worst case (which is achievable if M and N are consecutive Fibonacci numbers). The average-case performance of Euclid’s algorithm requires pages and pages of highly sophisticated mathematical analysis, and it turns out that the average number of iterations is about (12 ln 2 ln N)/π2 + 1.47. Exponentiation Our last example in this section deals with raising an integer to a power (which is also an integer). Numbers that result from exponentiation are generally quite large, so an analysis works only if we can assume that we have a machine that can store such large integers 48 Chapter 2 Algorithm Analysis 1 public static long pow( long x, int n ) 2 { 3 if( n == 0 ) 4 return 1; 5 if( n == 1 ) 6 return x; 7 if( isEven( n ) ) 8 return pow( x * x, n / 2 ); 9 else 10 return pow( x * x, n / 2 ) * x; 11 } Figure 2.11 Efficient exponentiation (or a compiler that can simulate this). We will count the number of multiplications as the measurement of running time. The obvious algorithm to compute XN uses N−1 multiplications. A recursive algorithm can do better. N ≤ 1 is the base case of the recursion. Otherwise, if N is even, we have XN = XN/2 · XN/2, and if N is odd, XN = X(N−1)/2 · X(N−1)/2 · X. For instance, to compute X62, the algorithm does the following calculations, which involve only nine multiplications: X3 = (X2)X, X7 = (X3)2X, X15 = (X7)2X, X31 = (X15)2X, X62 = (X31)2 The number of multiplications required is clearly at most 2 log N, because at most two multiplications (if N is odd) are required to halve the problem. Again, a recurrence formula can be written and solved. Simple intuition obviates the need for a brute-force approach. Figure 2.11 implements this idea.2 It is sometimes interesting to see how much the code can be tweaked without affecting correctness. In Figure 2.11, lines 5 to 6 are actually unnecessary, because if N is 1, then line 10 does the right thing. Line 10 can also be rewritten as 10 return pow( x, n - 1 ) * x; without affecting the correctness of the program. Indeed, the program will still run in O(log N), because the sequence of multiplications is the same as before. However, all of the following alternatives for line 8 are bad, even though they look correct: 8a return pow( pow( x, 2 ), n / 2 ); 8b return pow( pow( x, n / 2 ), 2 ); 8c return pow( x, n / 2 ) * pow( x, n / 2 ); 2 Java provides a BigInteger class that can be used to manipulate arbitrarily large integers. Translating Figure 2.11 to use BigInteger instead of long is straightforward. Summary 49 Both lines 8a and 8b are incorrect because when N is 2, one of the recursive calls to pow has 2 as the second argument. Thus no progress is made, and an infinite loop results (in an eventual abnormal termination). Using line 8c affects the efficiency, because there are now two recursive calls of size N/2 instead of only one. An analysis will show that the running time is no longer O(log N). We leave it as an exercise to the reader to determine the new running time. 2.4.5 A Grain of Salt Sometimes the analysis is shown empirically to be an overestimate. If this is the case, then either the analysis needs to be tightened (usually by a clever observation), or it may be that the average running time is significantly less than the worst-case running time and no improvement in the bound is possible. For many complicated algorithms the worst-case bound is achievable by some bad input but is usually an overestimate in practice. Unfortunately, for most of these problems, an average-case analysis is extremely complex (in many cases still unsolved), and a worst-case bound, even though overly pessimistic, is the best analytical result known. Summary This chapter gives some hints on how to analyze the complexity of programs. Unfortunately, it is not a complete guide. Simple programs usually have simple analyses, but this is not always the case. As an example, later in the text we shall see a sorting algo- rithm (Shellsort, Chapter 7) and an algorithm for maintaining disjoint sets (Chapter 8), each of which requires about 20 lines of code. The analysis of Shellsort is still not com- plete, and the disjoint set algorithm has an analysis that is extremely difficult and requires pages and pages of intricate calculations. Most of the analyses that we will encounter here will be simple and involve counting through loops. An interesting kind of analysis, which we have not touched upon, is lower-bound analysis. We will see an example of this in Chapter 7, where it is proved that any algorithm that sorts by using only comparisons requires �(N log N) comparisons in the worst case. Lower-bound proofs are generally the most difficult, because they apply not to an algorithm but to a class of algorithms that solve a problem. We close by mentioning that some of the algorithms described here have real-life application. The gcd algorithm and the exponentiation algorithm are both used in cryptog- raphy. Specifically, a 600-digit number is raised to a large power (usually another 600-digit number), with only the low 600 or so digits retained after each multiplication. Since the calculations require dealing with 600-digit numbers, efficiency is obviously important. The straightforward algorithm for exponentiation would require about 10600 multiplications, whereas the algorithm presented requires only about 4,000, in the worst case. 50 Chapter 2 Algorithm Analysis Exercises 2.1 Order the following functions by growth rate: N, √ N, N1.5, N2, N log N, N log log N, N log2 N, N log(N2), 2/N, 2N, 2N/2, 37, N2 log N, N3. Indicate which functions grow at the same rate. 2.2 Suppose T1(N) = O(f(N)) and T2(N) = O(f(N)). Which of the following are true? a. T1(N) + T2(N) = O(f(N)) b. T1(N) − T2(N) = o(f(N)) c. T1(N) T2(N) = O(1) d. T1(N) = O(T2(N)) 2.3 Which function grows faster: N log N or N1+ / √ log N, > 0?

2.4 Prove that for any constant, k, logk N = o(N).
2.5 Find two functions f(N) and g(N) such that neither f(N) = O(g(N)) nor g(N) =

O(f(N)).

2.6 In a recent court case, a judge cited a city for contempt and ordered a
fine of $2 for the first day. Each subsequent day, until the city followed the
judge’s order, the fine was squared (that is, the fine progressed as follows:
$2, $4, $16, $256, $65, 536, . . .).
a. What would be the fine on day N?
b. How many days would it take the fine to reach D dollars? (A Big-Oh answer

will do.)

2.7 For each of the following six program fragments:
a. Give an analysis of the running time (Big-Oh will do).
b. Implement the code in Java, and give the running time for several values of N.
c. Compare your analysis with the actual running times.

(1) sum = 0;
for( i = 0; i < n; i++ ) sum++; (2) sum = 0; for( i = 0; i < n; i++ ) for( j = 0; j < n; j++ ) sum++; (3) sum = 0; for( i = 0; i < n; i++ ) for( j = 0; j < n * n; j++ ) sum++; (4) sum = 0; for( i = 0; i < n; i++ ) for( j = 0; j < i; j++ ) sum++; Exercises 51 (5) sum = 0; for( i = 0; i < n; i++ ) for( j = 0; j < i * i; j++ ) for( k = 0; k < j; k++ ) sum++; (6) sum = 0; for( i = 1; i < n; i++ ) for( j = 1; j < i * i; j++ ) if( j % i == 0 ) for( k = 0; k < j; k++ ) sum++; 2.8 Suppose you need to generate a random permutation of the first N integers. For example, {4, 3, 1, 5, 2} and {3, 1, 4, 2, 5} are legal permutations, but {5, 4, 1, 2, 1} is not, because one number (1) is duplicated and another (3) is missing. This routine is often used in simulation of algorithms. We assume the exis- tence of a random number generator, r, with method randInt(i, j), that generates integers between i and j with equal probability. Here are three algorithms: 1. Fill the array a from a[0] to a[n-1] as follows: To fill a[i], generate random numbers until you get one that is not already in a[0], a[1], . . . , a[i-1]. 2. Same as algorithm (1), but keep an extra array called the used array. When a random number, ran, is first put in the array a, set used[ran] = true. This means that when filling a[i] with a random number, you can test in one step to see whether the random number has been used, instead of the (possibly) i steps in the first algorithm. 3. Fill the array such that a[i] = i + 1. Then for( i = 1; i < n; i++ ) swapReferences( a[ i ], a[ randInt( 0, i ) ] ); a. Prove that all three algorithms generate only legal permutations and that all permutations are equally likely. b. Give as accurate (Big-Oh) an analysis as you can of the expected running time of each algorithm. c. Write (separate) programs to execute each algorithm 10 times, to get a good average. Run program (1) for N = 250, 500, 1,000, 2,000; program (2) for N = 25,000, 50,000, 100,000, 200,000, 400,000, 800,000; and program (3) for N = 100,000, 200,000, 400,000, 800,000, 1,600,000, 3,200,000, 6,400,000. d. Compare your analysis with the actual running times. e. What is the worst-case running time of each algorithm? 2.9 Complete the table in Figure 2.2 with estimates for the running times that were too long to simulate. Interpolate the running times for these algorithms and esti- mate the time required to compute the maximum subsequence sum of 1 million numbers. What assumptions have you made? 52 Chapter 2 Algorithm Analysis 2.10 Determine, for the typical algorithms that you use to perform calculations by hand, the running time to do the following: a. Add two N-digit integers. b. Multiply two N-digit integers. c. Divide two N-digit integers. 2.11 An algorithm takes 0.5 ms for input size 100. How long will it take for input size 500 if the running time is the following (assume low-order terms are negligible): a. linear b. O(N log N) c. quadratic d. cubic 2.12 An algorithm takes 0.5 ms for input size 100. How large a problem can be solved in 1 min if the running time is the following (assume low-order terms are negligible): a. linear b. O(N log N) c. quadratic d. cubic 2.13 How much time is required to compute f(x) = ∑Ni=0 aixi: a. Using a simple routine to perform exponentiation? b. Using the routine in Section 2.4.4? 2.14 Consider the following algorithm (known as Horner’s rule) to evaluate f(x) =∑N i=0 aix i: poly = 0; for( i = n; i >= 0; i– )

poly = x * poly + a[i];

a. Show how the steps are performed by this algorithm for x = 3, f(x) = 4×4 +
8×3 + x + 2.

b. Explain why this algorithm works.
c. What is the running time of this algorithm?

2.15 Give an efficient algorithm to determine if there exists an integer i such that Ai = i
in an array of integers A1 < A2 < A3 < · · · < AN. What is the running time of your algorithm? 2.16 Write an alternative gcd algorithm based on the following observations (arrange so that a > b):

� gcd(a, b) = 2gcd(a/2, b/2) if a and b are both even.
� gcd(a, b) = gcd(a/2, b) if a is even and b is odd.
� gcd(a, b) = gcd(a, b/2) if a is odd and b is even.
� gcd(a, b) = gcd((a + b)/2), (a − b)/2) if a and b are both odd.

Exercises 53

2.17 Give efficient algorithms (along with running time analyses) to:
a. Find the minimum subsequence sum.

�b. Find the minimum positive subsequence sum.
�c. Find the maximum subsequence product.

2.18 An important problem in numerical analysis is to find a solution to the equation
f(X) = 0 for some arbitrary f . If the function is continuous and has two points
low and high such that f(low) and f(high) have opposite signs, then a root must
exist between low and high and can be found by a binary search. Write a function
that takes as parameters f , low, and high and solves for a zero. (To implement a
generic function as a parameter, pass a function object that implements the Function
interface, which you can define to contain a single method f.) What must you do
to ensure termination?

2.19 The maximum contiguous subsequence sum algorithms in the text do not give any
indication of the actual sequence. Modify them so that they return in a single object
the value of the maximum subsequence and the indices of the actual sequence.

2.20 a. Write a program to determine if a positive integer, N, is prime.
b. In terms of N, what is the worst-case running time of your program? (You should

be able to do this in O(
√

N).)
c. Let B equal the number of bits in the binary representation of N. What is the

value of B?
d. In terms of B, what is the worst-case running time of your program?
e. Compare the running times to determine if a 20-bit number and a 40-bit number

are prime.
f. Is it more reasonable to give the running time in terms of N or B? Why?

�2.21 The Sieve of Eratosthenes is a method used to compute all primes less than N. We
begin by making a table of integers 2 to N. We find the smallest integer, i, that is
not crossed out, print i, and cross out i, 2i, 3i, . . . . When i >

√
N, the algorithm

terminates. What is the running time of this algorithm?

2.22 Show that X62 can be computed with only eight multiplications.

2.23 Write the fast exponentiation routine without recursion.

2.24 Give a precise count on the number of multiplications used by the fast exponenti-
ation routine. (Hint: Consider the binary representation of N.)

2.25 Programs A and B are analyzed and found to have worst-case running times no
greater than 150N log2 N and N

2, respectively. Answer the following questions, if
possible:
a. Which program has the better guarantee on the running time, for large values of

N (N > 10,000)?
b. Which program has the better guarantee on the running time, for small values

of N (N < 100)? c. Which program will run faster on average for N = 1,000? d. Is it possible that program B will run faster than program A on all possible inputs? 54 Chapter 2 Algorithm Analysis 2.26 A majority element in an array, A, of size N is an element that appears more than N/2 times (thus, there is at most one). For example, the array 3, 3, 4, 2, 4, 4, 2, 4, 4 has a majority element (4), whereas the array 3, 3, 4, 2, 4, 4, 2, 4 does not. If there is no majority element, your program should indicate this. Here is a sketch of an algorithm to solve the problem: First, a candidate majority element is found (this is the harder part). This candidate is the only element that could possibly be the majority element. The second step determines if this candidate is actually the majority. This is just a sequential search through the array. To find a candidate in the array, A, form a second array, B. Then compare A1 and A2. If they are equal, add one of these to B; otherwise do nothing. Then compare A3 and A4. Again if they are equal, add one of these to B; otherwise do nothing. Continue in this fashion until the entire array is read. Then recursively find a candidate for B; this is the candidate for A (why?). a. How does the recursion terminate? �b. How is the case where N is odd handled? �c. What is the running time of the algorithm? d. How can we avoid using an extra array B? �e. Write a program to compute the majority element. 2.27 The input is an N by N matrix of numbers that is already in memory. Each individ- ual row is increasing from left to right. Each individual column is increasing from top to bottom. Give an O(N) worst-case algorithm that decides if a number X is in the matrix. 2.28 Design efficient algorithms that take an array of positive numbers a, and determine: a. the maximum value of a[j]+a[i], with j ≥ i. b. the maximum value of a[j]-a[i], with j ≥ i. c. the maximum value of a[j]*a[i], with j ≥ i. d. the maximum value of a[j]/a[i], with j ≥ i. �2.29 Why is it important to assume that integers in our computer model have a fixed size? 2.30 Consider the word puzzle problem described in Chapter 1. Suppose we fix the size of the longest word to be 10 characters. a. In terms of R and C, which are the number of rows and columns in the puz- zle, and W, which is the number of words, what are the running times of the algorithms described in Chapter 1? b. Suppose the word list is presorted. Show how to use binary search to obtain an algorithm with significantly better running time. References 55 2.31 Suppose that line 15 in the binary search routine had the statement low = mid instead of low = mid + 1. Would the routine still work? 2.32 Implement the binary search so that only one two-way comparison is performed in each iteration. (The text implementation uses three-way comparisons. Assume that only a lessThan method is available.) 2.33 Suppose that lines 15 and 16 in algorithm 3 (Fig. 2.7) are replaced by 15 int maxLeftSum = maxSubSum( a, left, center - 1 ); 16 int maxRightSum = maxSubSum( a, center, right ); Would the routine still work? �2.34 The inner loop of the cubic maximum subsequence sum algorithm performs N(N+1)(N+2)/6 iterations of the innermost code. The quadratic version performs N(N + 1)/2 iterations. The linear version performs N iterations. What pattern is evident? Can you give a combinatoric explanation of this phenomenon? References Analysis of the running time of algorithms was first made popular by Knuth in the three-part series [5], [6], and [7]. Analysis of the gcd algorithm appears in [6]. Another early text on the subject is [1]. Big-Oh, Big-Omega, Big-Theta, and little-oh notation were advocated by Knuth in [8]. There is still not uniform agreement on the matter, especially when it comes to using �(). Many people prefer to use O(), even though it is less expressive. Additionally, O() is still used in some corners to express a lower bound, when �() is called for. The maximum subsequence sum problem is from [3]. The series of books [2], [3], and [4] show how to optimize programs for speed. 1. A. V. Aho, J. E. Hopcroft, and J. D. Ullman, The Design and Analysis of Computer Algorithms, Addison-Wesley, Reading, Mass., 1974. 2. J. L. Bentley, Writing Efficient Programs, Prentice Hall, Englewood Cliffs, N.J., 1982. 3. J. L. Bentley, Programming Pearls, Addison-Wesley, Reading, Mass., 1986. 4. J. L. Bentley, More Programming Pearls, Addison-Wesley, Reading, Mass., 1988. 5. D. E. Knuth, The Art of Computer Programming, Vol 1: Fundamental Algorithms, 3d ed., Addison-Wesley, Reading, Mass., 1997. 6. D. E. Knuth, The Art of Computer Programming, Vol 2: Seminumerical Algorithms, 3d ed., Addison-Wesley, Reading, Mass., 1998. 7. D. E. Knuth, The Art of Computer Programming, Vol 3: Sorting and Searching, 2d ed., Addison- Wesley, Reading, Mass., 1998. 8. D. E. Knuth, “Big Omicron and Big Omega and Big Theta,” ACM SIGACT News, 8 (1976), 18–23. This page intentionally left blank C H A P T E R 3 Lists, Stacks, and Queues This chapter discusses three of the most simple and basic data structures. Virtually every significant program will use at least one of these structures explicitly, and a stack is always implicitly used in a program, whether or not you declare one. Among the highlights of this chapter, we will � Introduce the concept of Abstract Data Types (ADTs). � Show how to efficiently perform operations on lists. � Introduce the stack ADT and its use in implementing recursion. � Introduce the queue ADT and its use in operating systems and algorithm design. In this chapter, we provide code that implements a significant subset of two library classes: ArrayList and LinkedList. 3.1 Abstract Data Types (ADTs) An abstract data type (ADT) is a set of objects together with a set of operations. Abstract data types are mathematical abstractions; nowhere in an ADT’s definition is there any men- tion of how the set of operations is implemented. Objects such as lists, sets, and graphs, along with their operations, can be viewed as abstract data types, just as integers, reals, and booleans are data types. Integers, reals, and booleans have operations associated with them, and so do abstract data types. For the set ADT, we might have such operations as add, remove, and contains. Alternatively, we might only want the two operations union and find, which would define a different ADT on the set. The Java class allows for the implementation of ADTs, with appropriate hiding of imple- mentation details. Thus any other part of the program that needs to perform an operation on the ADT can do so by calling the appropriate method. If for some reason implementa- tion details need to be changed, it should be easy to do so by merely changing the routines that perform the ADT operations. This change, in a perfect world, would be completely transparent to the rest of the program. There is no rule telling us which operations must be supported for each ADT; this is a design decision. Error handling and tie breaking (where appropriate) are also generally up to the program designer. The three data structures that we will study in this chapter are 57 58 Chapter 3 Lists, Stacks, and Queues primary examples of ADTs. We will see how each can be implemented in several ways, but if they are done correctly, the programs that use them will not necessarily need to know which implementation was used. 3.2 The List ADT We will deal with a general list of the form A0, A1, A2, . . ., AN−1. We say that the size of this list is N. We will call the special list of size 0 an empty list. For any list except the empty list, we say that Ai follows (or succeeds) Ai−1 (i < N) and that Ai−1 precedes Ai (i > 0). The first element of the list is A0, and the last element
is AN−1. We will not define the predecessor of A0 or the successor of AN−1. The position
of element Ai in a list is i. Throughout this discussion, we will assume, to simplify matters,
that the elements in the list are integers, but in general, arbitrarily complex elements are
allowed (and easily handled by a generic Java class).

Associated with these “definitions” is a set of operations that we would like to perform
on the list ADT. Some popular operations are printList and makeEmpty, which do the obvious
things; find, which returns the position of the first occurrence of an item; insert and
remove, which generally insert and remove some element from some position in the list;
and findKth, which returns the element in some position (specified as an argument). If the
list is 34, 12, 52, 16, 12, then find(52) might return 2; insert(x,2) might make the list
into 34, 12, x, 52, 16, 12 (if we insert into the position given); and remove(52) might turn
that list into 34, 12, x, 16, 12.

Of course, the interpretation of what is appropriate for a method is entirely up to the
programmer, as is the handling of special cases (for example, what does find(1) return
above?). We could also add operations such as next and previous, which would take a
position as argument and return the position of the successor and predecessor, respectively.

3.2.1 Simple Array Implementation of Lists
All these instructions can be implemented just by using an array. Although arrays are cre-
ated with a fixed capacity, we can create a different array with double the capacity when
needed. This solves the most serious problem with using an array, namely that historically,
to use an array, an estimate of the maximum size of the list was required. This estimate is
not needed in Java, or any modern programming language. The following code fragment
illustrates how an array, arr, which initially has length 10, can be expanded as needed:

int [ ] arr = new int[ 10 ];
…

// Later on we decide arr needs to be larger.
int [ ] newArr = new int[ arr.length * 2 ];
for( int i = 0; i < arr.length; i++ ) newArr[ i ] = arr[ i ]; arr = newArr; 3.2 The List ADT 59 An array implementation allows printList to be carried out in linear time, and the findKth operation takes constant time, which is as good as can be expected. However, insertion and deletion are potentially expensive, depending on where the insertions and deletions occur. In the worst case, inserting into position 0 (in other words, at the front of the list) requires pushing the entire array down one spot to make room, and deleting the first element requires shifting all the elements in the list up one spot, so the worst case for these operations is O(N). On average, half of the list needs to be moved for either operation, so linear time is still required. On the other hand, if all the operations occur at the high end of the list, then no elements need to be shifted, and then adding and deleting take O(1) time. There are many situations where the list is built up by insertions at the high end, and then only array accesses (i.e., findKth operations) occur. In such a case, the array is a suitable implementation. However, if insertions and deletions occur throughout the list, and in particular, at the front of the list, then the array is not a good option. The next subsection deals with the alternative: the linked list. 3.2.2 Simple Linked Lists In order to avoid the linear cost of insertion and deletion, we need to ensure that the list is not stored contiguously, since otherwise entire parts of the list will need to be moved. Figure 3.1 shows the general idea of a linked list. The linked list consists of a series of nodes, which are not necessarily adjacent in memory. Each node contains the element and a link to a node containing its successor. We call this the next link. The last cell’s next link references null. To execute printList or find(x) we merely start at the first node in the list and then traverse the list by following the next links. This operation is clearly linear-time, as in the array implementation, although the constant is likely to be larger than if an array implementation were used. The findKth operation is no longer quite as efficient as an array implementation; findKth(i) takes O(i) time and works by traversing down the list in the obvious manner. In practice, this bound is pessimistic, because frequently the calls to findKth are in sorted order (by i). As an example, findKth(2), findKth(3), findKth(4), and findKth(6) can all be executed in one scan down the list. The remove method can be executed in one next reference change. Figure 3.2 shows the result of deleting the third element in the original list. The insert method requires obtaining a new node from the system by using a new call and then executing two reference maneuvers. The general idea is shown in Figure 3.3. The dashed line represents the old next reference. A0 A1 A2 A3 A4 Figure 3.1 A linked list 60 Chapter 3 Lists, Stacks, and Queues A0 A1 A2 A3 A4 Figure 3.2 Deletion from a linked list A0 A1 A2 A3 A4 X Figure 3.3 Insertion into a linked list As we can see, in principle, if we know where a change is to be made, inserting or removing an item from a linked list does not require moving lots of items and instead involves only a constant number of changes to node links. The special case of adding to the front or removing the first item is thus a constant- time operation, presuming of course that a link to the front of the linked list is maintained. The special case of adding at the end (i.e., making the new item as the last item) can be constant-time, as long as we maintain a link to the last node. Thus, a typical linked list keeps links to both ends of the list. Removing the last item is trickier, because we have to find the next-to-last item, change its next link to null, and then update the link that maintains the last node. In the classic linked list, where each node stores a link to its next node, having a link to the last node provides no information about the next-to-last node. The obvious idea of maintaining a third link to the next-to-last node doesn’t work, because it too would need to be updated during a remove. Instead, we have every node maintain a link to its previous node in the list. This is shown in Figure 3.4 and is known as a doubly linked list. first last a b c d Figure 3.4 A doubly linked list 3.3 Lists in the Java Collections API 61 3.3 Lists in the Java Collections API The Java language includes, in its library, an implementation of common data structures. This part of the language is popularly known as the Collections API. The List ADT is one of the data structures implemented in the Collections API. We will see some others in Chapters 4 and 5. 3.3.1 Collection Interface The Collections API resides in package java.util. The notion of a collection, which stores a collection of identically typed objects, is abstracted in the Collection interface. Figure 3.5 shows the most important parts of this interface (some methods are not shown). Many of the methods in the Collection interface do the obvious things that their names suggest. So size returns the number of items in the collection; isEmpty returns true if and only if the size of the collection is zero. contains returns true if x is in the collection. Note that the interface doesn’t specify how the collection decides if x is in the collection—this is determined by the actual classes that implement the Collection interface. add and remove add and remove item x from the collection, returning true if the operation succeeds and false if it fails for a plausible (nonexceptional) reason. For instance, a remove can fail if the item is not present in the collection, and if the particular collection does not allow duplicates, then add can fail when an attempt is made to insert a duplicate. The Collection interface extends the Iterable interface. Classes that implement the Iterable interface can have the enhanced for loop used on them to view all their items. For instance, the routine in Figure 3.6 can be used to print all the items in any collection. The implementation of this version of print is identical, character-for-character, with a corresponding implementation that could be used if coll had type AnyType[]. 3.3.2 Iterator s Collections that implement the Iterable interface must provide a method named iterator that returns an object of type Iterator. The Iterator is an interface defined in package java.util and is shown in Figure 3.7. 1 public interface Collection extends Iterable
2 {
3 int size( );
4 boolean isEmpty( );
5 void clear( );
6 boolean contains( AnyType x );
7 boolean add( AnyType x );
8 boolean remove( AnyType x );
9 java.util.Iterator iterator( );

10 }

Figure 3.5 Subset of the Collection interface in package java.util

62 Chapter 3 Lists, Stacks, and Queues

1 public static void print( Collection coll )
2 {
3 for( AnyType item : coll )
4 System.out.println( item );
5 }

Figure 3.6 Using the enhanced for loop on an Iterable type

1 public interface Iterator
2 {
3 boolean hasNext( );
4 AnyType next( );
5 void remove( );
6 }

Figure 3.7 The Iterator interface in package java.util

The idea of the Iterator is that via the iterator method, each collection can create, and
return to the client, an object that implements the Iterator interface and stores internally
its notion of a current position.

Each call to next gives the next item in the collection (that has not yet been seen). Thus
the first call to next gives the first item, the second call gives the second item, and so forth.
hasNext can be used to tell you if there is a next item. When the compiler sees an enhanced
for loop being used on an object that is Iterable, it mechanically replaces the enhanced
for loop with calls to the iterator method to obtain an Iterator and then calls to next and
hasNext. Thus the previously seen print routine is rewritten by the compiler as shown in
Figure 3.8.

Because of the limited set of methods available in the Iterator interface, it is hard to
use the Iterator for anything more than a simple traversal through the Collection. The
Iterator interface also contains a method called remove. With this method you can remove
the last item returned by next (after which you cannot call remove again until after another

1 public static void print( Collection coll )
2 {
3 Iterator itr = coll.iterator( );
4 while( itr.hasNext( ) )
5 {
6 AnyType item = itr.next( );
7 System.out.println( item );
8 }
9 }

Figure 3.8 The enhanced for loop on an Iterable type rewritten by the compiler to use
an iterator

3.3 Lists in the Java Collections API 63

call to next). Although the Collection interface also contains a remove method, there are
presumably advantages to using the Iterator’s remove method instead.

The main advantage of the Iterator’s remove method is that the Collection’s remove
method must first find the item to remove. Presumably it is much less expensive to remove
an item if you know exactly where it is. An example that we will see in the next section
removes every other item in the collection. This code is easy to write with an iterator, and
potentially more efficient than using the Collection’s remove method.

When using the iterator directly (rather than indirectly via an enhanced for loop) it
is important to keep in mind a fundamental rule: If you make a structural change to the
collection being iterated (i.e., an add, remove, or clear method is applied on the collection),
then the iterator is no longer valid (and a ConcurrentModificationException is thrown on
subsequent attempts to use the iterator). This is necessary to avoid ugly situations in which
the iterator is prepared to give a certain item as the next item, and then that item is either
removed, or perhaps a new item is inserted just prior to the next item. This means that you
shouldn’t obtain an iterator until immediately prior to the need to use it. However, if the
iterator invokes its remove method, then the iterator is still valid. This is a second reason to
prefer the iterator’s remove method sometimes.

3.3.3 The List Interface, ArrayList, and LinkedList
The collection that concerns us the most in this section is the list, which is specified by the
List interface in package java.util. The List interface extends Collection, so it contains
all the methods in the Collection interface, plus a few others. Figure 3.9 illustrates the
most important of these methods.

get and set allow the client to access or change an item at the specified position in the
list, given by its index, idx. Index 0 is the front of the list, index size()-1 represents the last
item in the list, and index size() represents the position where a newly added item can be
placed. add allows the placement of a new item in position idx (pushing subsequent items
one position higher). Thus, an add at position 0 is adding at the front, whereas an add at
position size() is adding an item as the new last item. In addition to the standard remove
that takes AnyType as a parameter, remove is overloaded to remove an item at a specified
position. Finally, the List interface specifies the listIterator method that produces a more

1 public interface List extends Collection
2 {
3 AnyType get( int idx );
4 AnyType set( int idx, AnyType newVal );
5 void add( int idx, AnyType x );
6 void remove( int idx );
7
8 ListIterator listIterator( int pos );
9 }

Figure 3.9 Subset of the List interface in package java.util

64 Chapter 3 Lists, Stacks, and Queues

complicated iterator than normally expected. The ListIterator interface is discussed in
Section 3.3.5.

There are two popular implementations of the List ADT. The ArrayList provides a grow-
able array implementation of the List ADT. The advantage of using the ArrayList is that
calls to get and set take constant time. The disadvantage is that insertion of new items
and removal of existing items is expensive, unless the changes are made at the end of the
ArrayList. The LinkedList provides a doubly linked list implementation of the List ADT. The
advantage of using the LinkedList is that insertion of new items and removal of existing
items is cheap, provided that the position of the changes is known. This means that adds
and removes from the front of the list are constant-time operations, so much so that the
LinkedList provides methods addFirst and removeFirst, addLast and removeLast, and get-
First and getLast to efficiently add, remove, and access the items at both ends of the list.
The disadvantage is that the LinkedList is not easily indexable, so calls to get are expensive
unless they are very close to one of the ends of the list (if the call to get is for an item near
the back of the list, the search can proceed from the back of the list). To see the differences,
we look at some methods that operate on a List. First, suppose we construct a List by
adding items at the end.

public static void makeList1( List lst, int N )
{

lst.clear( );
for( int i = 0; i < N; i++ ) lst.add( i ); } Regardless of whether an ArrayList or LinkedList is passed as a parameter, the running time of makeList1 is O(N) because each call to add, being at the end of the list, takes constant time (the occasional expansion of the ArrayList is safe to ignore). On the other hand, if we construct a List by adding items at the front, public static void makeList2( List lst, int N )
{

lst.clear( );
for( int i = 0; i < N; i++ ) lst.add( 0, i ); } the running time is O(N) for a LinkedList, but O(N2) for an ArrayList, because in an ArrayList, adding at the front is an O(N) operation. The next routine attempts to compute the sum of the numbers in a List: public static int sum( List lst )
{

int total = 0;
for( int i = 0; i < N; i++ ) total += lst.get( i ); return total; } 3.3 Lists in the Java Collections API 65 Here, the running time is O(N) for an ArrayList, but O(N2) for a LinkedList, because in a LinkedList, calls to get are O(N) operations. Instead, use an enhanced for loop, which will make the running time O(N) for any List, because the iterator will efficiently advance from one item to the next. Both ArrayList and LinkedList are inefficient for searches, so calls to the Collection contains and remove methods (that take an AnyType as parameter) take linear time. In an ArrayList, there is a notion of a capacity, which represents the size of the under- lying array. The ArrayList automatically increases the capacity as needed to ensure that it is at least as large as the size of the list. If an early estimate of the size is available, ensureCa- pacity can set the capacity to a sufficiently large amount to avoid a later expansion of the array capacity. Also, trimToSize can be used after all ArrayList adds are completed to avoid wasted space. 3.3.4 Example: Using remove on a LinkedList As an example, we provide a routine that removes all even-valued items in a list. Thus, if the list contains 6, 5, 1, 4, 2, then after the method is invoked it will contain 5, 1. There are several possible ideas for an algorithm that deletes items from the list as they are encountered. Of course, one idea is to construct a new list containing all the odd numbers, and then clear the original list and copy the odd numbers back into it. But we are more interested in writing a clean version that avoids making a copy and instead removes items from the list as they are encountered. This is almost certainly a losing strategy for an ArrayList, since removing from almost anywhere in an ArrayList is expensive. In a LinkedList, there is some hope, as we know that removing from a known position can be done efficiently by rearranging some links. Figure 3.10 shows the first attempt. On an ArrayList, as expected, the remove is not efficient, so the routine takes quadratic time. A LinkedList exposes two problems. First, the call to get is not efficient, so the routine takes quadratic time. Additionally, the call to remove is equally inefficient, because it is expensive to get to position i. Figure 3.11 shows one attempt to rectify the problem. Instead of using get, we use an iterator to step through the list. This is efficient. But then we use the Collection’s remove 1 public static void removeEvensVer1( List lst )
2 {
3 int i = 0;
4 while( i < lst.size( ) ) 5 if( lst.get( i ) % 2 == 0 ) 6 lst.remove( i ); 7 else 8 i++; 9 } Figure 3.10 Removes the even numbers in a list; quadratic on all types of lists 66 Chapter 3 Lists, Stacks, and Queues 1 public static void removeEvensVer2( List lst )
2 {
3 for( Integer x : lst )
4 if( x % 2 == 0 )
5 lst.remove( x );
6 }

Figure 3.11 Removes the even numbers in a list; doesn’t work because of
ConcurrentModificationException

1 public static void removeEvensVer3( List lst )
2 {
3 Iterator itr = lst.iterator( );
4
5 while( itr.hasNext( ) )
6 if( itr.next( ) % 2 == 0 )
7 itr.remove( );
8 }

Figure 3.12 Removes the even numbers in a list; quadratic on ArrayList, but linear time
for LinkedList

method to remove an even-valued item. This is not an efficient operation because the
remove method has to search for the item again, which takes linear time. But if we run the
code, we find out that the situation is even worse: The program generates an exception
because when an item is removed, the underlying iterator used by the enhanced for loop
is invalidated. (The code in Figure 3.10 explains why: we cannot expect the enhanced for
loop to understand that it must advance only if an item is not removed.)

Figure 3.12 shows an idea that works: After the iterator finds an even-valued item,
we can use the iterator to remove the value it has just seen. For a LinkedList, the call to
the iterator’s remove method is only constant time, because the iterator is at (or near) the
node that needs to be removed. Thus, for a LinkedList, the entire routine takes linear time,
rather than quadratic time. For an ArrayList, even though the iterator is at the point that
needs to be removed, the remove is still expensive, because array items must be shifted, so
as expected, the entire routine still takes quadratic time for an ArrayList.

If we run the code in Figure 3.12, passing a LinkedList, it takes 0.039 seconds
for an 800,000-item list, and 0.073 seconds for a 1,600,000 item LinkedList, and is
clearly a linear-time routine, because the running time increases by the same factor as the
input size. When we pass an ArrayList, the routine takes almost five minutes
for an 800,000-item ArrayList, and about twenty minutes for a 1,600,000-item ArrayList;
the fourfold increase in running time when the input increases by only a factor of two is
consistent with quadratic behavior.

3.4 Implementation of ArrayList 67

1 public interface ListIterator extends Iterator
2 {
3 boolean hasPrevious( );
4 AnyType previous( );
5
6 void add( AnyType x );
7 void set( AnyType newVal );
8 }

Figure 3.13 Subset of the ListIterator interface in package java.util

5 8 6 914 5 8 6 914 5 8 6 914

(a) (b) (c)

Figure 3.14 (a) Normal starting point: next returns 5, previous is illegal, add places item
before 5; (b) next returns 8, previous returns 5, add places item between 5 and 8; (c) next
is illegal, previous returns 9, add places item after 9

3.3.5 ListIterators
Figure 3.13 shows that a ListIterator extends the functionality of an Iterator for Lists.
previous and hasPrevious allow traversal of the list from the back to the front. add places
a new item into the list in the current position. The notion of the current position is
abstracted by viewing the iterator as being between the item that would be given by a
call to next and the item that would be given by a call to previous, an abstraction that is
illustrated in Figure 3.14. add is a constant-time operation for a LinkedList but is expensive
for an ArrayList. set changes the last value seen by the iterator and is convenient for
LinkedLists. As an example, it can be used to subtract 1 from all the even numbers in
a List, which would be hard to do on a LinkedList without using the ListIterator’s set
method.

3.4 Implementation of ArrayList
In this section, we provide the implementation of a usable ArrayList generic class. To avoid
ambiguities with the library class, we will name our class MyArrayList. We do not provide
a MyCollection or MyList interface; rather, MyArrayList is standalone. Before examining the
(nearly one hundred lines of) MyArrayList code, we outline the main details.

1. The MyArrayList will maintain the underlying array, the array capacity, and the current
number of items stored in the MyArrayList.

68 Chapter 3 Lists, Stacks, and Queues

2. The MyArrayList will provide a mechanism to change the capacity of the underlying
array. The capacity is changed by obtaining a new array, copying the old array into the
new array, and allowing the Virtual Machine to reclaim the old array.

3. The MyArrayList will provide an implementation of get and set.

4. The MyArrayList will provide basic routines, such as size, isEmpty, and clear, which are
typically one-liners; a version of remove; and also two versions of add. The add routines
will increase capacity if the size and capacity are the same.

5. The MyArrayList will provide a class that implements the Iterator interface. This class
will store the index of the next item in the iteration sequence and provide implemen-
tations of next, hasNext, and remove. The MyArrayList’s iterator method simply returns
a newly constructed instance of the class that implements the Iterator interface.

3.4.1 The Basic Class
Figure 3.15 and Figure 3.16 show the MyArrayList class. Like its Collections API counter-
part, there is some error checking to ensure valid bounds; however, in order to concentrate
on the basics of writing the iterator class, we do not check for a structural modification that
could invalidate an iterator, nor do we check for an illegal iterator remove. These checks are
shown in the subsequent implementation of MyLinkedList in Section 3.5 and are exactly
the same for both list implementations.

As shown on lines 5–6, the MyArrayList stores the size and array as its data members.
A host of short routines, namely clear, doClear (used to avoid having the constructor

invoke an overridable method), size, trimToSize, isEmpty, get, and set, are implemented
in lines 11 to 38.

The ensureCapacity routine is shown at lines 40 to 49. Expanding capacity is done with
the same logic outlined earlier: saving a reference to the original array at line 45, allocation
of a new array at line 46, and copying of the old contents at lines 47 to 48. As shown
at lines 42 to 43, the ensureCapacity routine can also be used to shrink the underlying
array, but only if the specified new capacity is at least as large as the size. If it isn’t, the
ensureCapacity request is ignored. At line 46, we see an idiom that is required because
generic array creation is illegal. Instead, we create an array of the generic type’s bound and
then use an array cast. This will generate a compiler warning but is unavoidable in the
implementation of generic collections.

Two versions of add are shown. The first adds at the end of the list and is trivially
implemented by calling the more general version that adds at the specified position. That
version is computationally expensive because it requires shifting elements that are at or
after the specified position an additional position higher. add may require increasing capac-
ity. Expanding capacity is very expensive, so if the capacity is expanded, it is made twice
as large as the size to avoid having to change the capacity again unless the size increases
dramatically (the +1 is used in case the size is 0).

The remove method is similar to add, in that elements that are at or after the specified
position must be shifted to one position lower.

The remaining routine deals with the iterator method and the implementation of the
associated iterator class. In Figure 3.16, this is shown at lines 77 to 96. The iterator

1 public class MyArrayList implements Iterable
2 {
3 private static final int DEFAULT_CAPACITY = 10;
4
5 private int theSize;
6 private AnyType [ ] theItems;
7
8 public MyArrayList( )
9 { doClear( ); }

10
11 public void clear( )
12 { doClear( ); }
13
14 private void doClear( )
15 { theSize = 0; ensureCapacity( DEFAULT_CAPACITY ); }
16
17 public int size( )
18 { return theSize; }
19 public boolean isEmpty( )
20 { return size( ) == 0; }
21 public void trimToSize( )
22 { ensureCapacity( size( ) ); }
23
24 public AnyType get( int idx )
25 {
26 if( idx < 0 || idx >= size( ) )
27 throw new ArrayIndexOutOfBoundsException( );
28 return theItems[ idx ];
29 }
30
31 public AnyType set( int idx, AnyType newVal )
32 {
33 if( idx < 0 || idx >= size( ) )
34 throw new ArrayIndexOutOfBoundsException( );
35 AnyType old = theItems[ idx ];
36 theItems[ idx ] = newVal;
37 return old;
38 }
39
40 public void ensureCapacity( int newCapacity )
41 {
42 if( newCapacity < theSize ) 43 return; 44 45 AnyType [ ] old = theItems; 46 theItems = (AnyType []) new Object[ newCapacity ]; 47 for( int i = 0; i < size( ); i++ ) 48 theItems[ i ] = old[ i ]; 49 } Figure 3.15 MyArrayList class (Part 1 of 2) 50 public boolean add( AnyType x ) 51 { 52 add( size( ), x ); 53 return true; 54 } 55 56 public void add( int idx, AnyType x ) 57 { 58 if( theItems.length == size( ) ) 59 ensureCapacity( size( ) * 2 + 1 ); 60 for( int i = theSize; i > idx; i– )
61 theItems[ i ] = theItems[ i – 1 ];
62 theItems[ idx ] = x;
63
64 theSize++;
65 }
66
67 public AnyType remove( int idx )
68 {
69 AnyType removedItem = theItems[ idx ];
70 for( int i = idx; i < size( ) - 1; i++ ) 71 theItems[ i ] = theItems[ i + 1 ]; 72 73 theSize--; 74 return removedItem; 75 } 76 77 public java.util.Iterator iterator( )
78 { return new ArrayListIterator( ); }
79
80 private class ArrayListIterator implements java.util.Iterator
81 {
82 private int current = 0;
83
84 public boolean hasNext( )
85 { return current < size( ); } 86 87 public AnyType next( ) 88 { 89 if( !hasNext( ) ) 90 throw new java.util.NoSuchElementException( ); 91 return theItems[ current++ ]; 92 } 93 94 public void remove( ) 95 { MyArrayList.this.remove( --current ); } 96 } 97 } Figure 3.16 MyArrayList class (Part 2 of 2) 3.4 Implementation of ArrayList 71 method simply returns an instance of ArrayListIterator, which is a class that implements the Iterator interface. The ArrayListIterator stores the notion of a current position, and provides implementations of hasNext, next, and remove. The current position represents the (array index of the) next element that is to be viewed, so initially the current position is 0. 3.4.2 The Iterator and Java Nested and Inner Classes The ArrayListIterator class uses a tricky Java construct known as the inner class. Clearly the class is declared inside of the MyArrayList class, a feature that is supported by many languages. However, an inner class in Java has a more subtle property. To see how an inner class works, Figure 3.17 sketches the iterator idea (however, the code is flawed), making ArrayListIterator a top-level class. We focus only on the data fields of MyArrayList, the iterator method in MyArrayList, and the ArrayListIterator (but not its remove method). In Figure 3.17, ArrayListIterator is generic, it stores a current position, and the code attempts to use the current position in next to index the array and then advance. Note that if arr is an array, arr[idx++] uses idx to the array, and then advances idx. The positioning of the ++ matters. The form we used is called the postfix ++ operator, in which the ++ is after idx. But in the prefix ++ operator, arr[++idx] advances idx and then uses the new idx to index the array. The problem with Figure 3.17 is that theItems[current++] is illegal, because theItems is not part of the ArrayListIterator class; it is part of the MyArrayList. Thus the code doesn’t make sense at all. 1 public class MyArrayList implements Iterable
2 {
3 private int theSize;
4 private AnyType [ ] theItems;
5 …
6 public java.util.Iterator iterator( )
7 { return new ArrayListIterator( ); }
8 }
9 class ArrayListIterator implements java.util.Iterator

10 {
11 private int current = 0;
12 …
13 public boolean hasNext( )
14 { return current < size( ); } 15 public AnyType next( ) 16 { return theItems[ current++ ]; } 17 } Figure 3.17 Iterator Version #1 (doesn’t work): The iterator is a top-level class and stores the current position. It doesn’t work because theItems and size() are not part of the ArrayListIterator class 72 Chapter 3 Lists, Stacks, and Queues 1 public class MyArrayList implements Iterable
2 {
3 private int theSize;
4 private AnyType [ ] theItems;
5 …
6 public java.util.Iterator iterator( )
7 { return new ArrayListIterator( this ); }
8 }
9 class ArrayListIterator implements java.util.Iterator

10 {
11 private int current = 0;
12 private MyArrayList theList;
13 …
14 public ArrayListIterator( MyArrayList list )
15 { theList = list; }
16
17 public boolean hasNext( )
18 { return current < theList.size( ); } 19 public AnyType next( ) 20 { return theList.theItems[ current++ ]; } 21 } Figure 3.18 Iterator Version #2 (almost works): The iterator is a top-level class and stores the current position and a link to the MyArrayList. It doesn’t work because theItems is private in the MyArrayList class The simplest solution is shown in Figure 3.18, which is unfortunately also flawed, but in a more minor way. In Figure 3.18, we solve the problem of not having the array in the iterator by having the iterator store a reference to the MyArrayList that it is iterating over. This reference is a second data field and is initialized by a new one-parameter constructor for ArrayListIterator. Now that we have a reference to MyArrayList, we can access the array field that is contained in MyArrayList (and also get the size of the MyArrayList, which is needed in hasNext). The flaw in Figure 3.18 is that theItems is a private field in MyArrayList, and since ArrayListIterator is a different class, it is illegal to access theItems in the next method. The simplest fix would be to change the visibility of theItems in MyArrayList from private to something less restrictive (such as public, or the default which is known as package visibility). But this violates basic principles of good object-oriented programming, which requires data to be as hidden as possible. Instead, Figure 3.19 shows a solution that works: Make the ArrayListIterator class a nested class. When we make ArrayListIterator a nested class, it is placed inside of another class (in this case MyArrayList) which is the outer class. We must use the word static to signify that it is nested; without static we will get an inner class, which is some- times good and sometimes bad. The nested class is the type of class that is typical of many programming languages. Observe that the nested class can be made private, which is nice 3.4 Implementation of ArrayList 73 1 public class MyArrayList implements Iterable
2 {
3 private int theSize;
4 private AnyType [ ] theItems;
5 …
6 public java.util.Iterator iterator( )
7 { return new ArrayListIterator( this ); }
8
9 private static class ArrayListIterator

10 implements java.util.Iterator
11 {
12 private int current = 0;
13 private MyArrayList theList;
14 …
15 public ArrayListIterator( MyArrayList list )
16 { theList = list; }
17
18 public boolean hasNext( )
19 { return current < theList.size( ); } 20 public AnyType next( ) 21 { return theList.theItems[ current++ ]; } 22 } 23 } Figure 3.19 Iterator Version #3 (works): The iterator is a nested class and stores the current position and a link to the MyArrayList. It works because the nested class is considered part of the MyArrayList class because then it is inaccessible except by the outer class MyArrayList. More importantly, because the nested class is considered to be part of the outer class, there are no visibility issues that arise: theItems is a visible member of class MyArrayList, because next is part of MyArrayList. Now that we have a nested class, we can discuss the inner class. The problem with the nested class is that in our original design, when we wrote theItems without referring to MyArrayList that it was contained in, the code looked nice, and kind of made sense, but was illegal because it was impossible for the compiler to deduce which MyArrayList was being referred to. It would be nice not to have to keep track of this ourselves. This is exactly what an inner class does for you. When you declare an inner class, the compiler adds an implicit reference to the outer class object that caused the inner class object’s construction. If the name of the outer class is Outer, then the implicit reference is Outer.this. Thus if ArrayListIterator is declared as an inner class, without the static, then MyArrayList.this and theList would both be referencing the same MyArrayList. Thus theList would be redundant and could be removed. 74 Chapter 3 Lists, Stacks, and Queues lst itr1 items: 3, 5, 2 theSize: 3 MyArrayList.this current = 3 MyArrayList.this current = 0 itr2 Figure 3.20 Iterator/container with inner classes The inner class is useful in a situation in which each inner class object is associated with exactly one instance of an outer class object. In such a case, the inner class object can never exist without having an outer class object with which to be associated. In the case of the MyArrayList and its iterator, Figure 3.20 shows the relationship between the iterator class and MyArrayList class, when inner classes are used to implement the iterator. The use of theList.theItems could be replaced with MyArrayList.this.theItems. This is hardly an improvement, but a further simplification is possible. Just as this.data can be written simply as data (provided there is no other variable named data that could clash), MyArrayList.this.theItems can be written simply as theItems. Figure 3.21 shows the simplification of the ArrayListIterator. 1 public class MyArrayList implements Iterable
2 {
3 private int theSize;
4 private AnyType [ ] theItems;
5 …
6 public java.util.Iterator iterator( )
7 { return new ArrayListIterator( ); }
8
9 private class ArrayListIterator implements java.util.Iterator

10 {
11 private int current = 0;
12
13 public boolean hasNext( )
14 { return current < size( ); } 15 public AnyType next( ) 16 { return theItems[ current++ ]; } 17 public void remove( ) 18 { MyArrayList.this.remove( --current ); } 19 } 20 } Figure 3.21 Iterator Version #4 (works): The iterator is an inner class and stores the current position and an implicit link to the MyArrayList 3.5 Implementation of LinkedList 75 First, the ArrayListIterator is implicitly generic, since it is now tied to MyArrayList, which is generic; we don’t have to say so. Second, theList is gone, and we use size() and theItems[current++] as shorthands for MyArrayList.this.size() and MyArrayList.this.theItems[current++]. The removal of the- List as a data member also removes the associated constructor, so the code reverts back to the style in Version #1. We can implement the iterator’s remove by calling MyArrayList’s remove. Since MyArrayList’s remove would conflict with ArrayListIterator’s remove, we have to use MyArrayList.this.remove. Note that after the item is removed, elements shift, so for current to be viewing the same element, it must also shift. Hence the use of --, rather than -1. Inner classes are a syntactical convenience for Java programmers. They are not needed to write any Java code, but their presence in the language allows the Java programmer to write code in the style that was natural (like Version #1), with the compiler writing the extra code required to associate the inner class object with the outer class object. 3.5 Implementation of LinkedList In this section, we provide the implementation of a usable LinkedList generic class. As in the case of the ArrayList class, our list class will be named MyLinkedList to avoid ambiguities with the library class. Recall that the LinkedList class will be implemented as a doubly linked list, and that we will need to maintain references to both ends of the list. Doing so allows us to maintain constant time cost per operation, so long as the operation occurs at a known position. The known position can be either end, or at a position specified by an iterator (however, we do not implement a ListIterator, thus leaving some code for the reader). In considering the design, we will need to provide three classes: 1. The MyLinkedList class itself, which contains links to both ends, the size of the list, and a host of methods. 2. The Node class, which is likely to be a private nested class. A node contains the data and links to the previous and next nodes, along with appropriate constructors. 3. The LinkedListIterator class, which abstracts the notion of a position and is a private inner class, implementing the Iterator interface. It provides implementations of next, hasNext, and remove. Because the iterator classes store a reference to the “current node,” and the end marker is a valid position, it makes sense to create an extra node at the end of the list to represent the end marker. Further, we can create an extra node at the front of the list, logically representing the beginning marker. These extra nodes are sometimes known as sentinel nodes; specifically, the node at the front is sometimes known as a header node, and the node at the end is sometimes known as a tail node. 76 Chapter 3 Lists, Stacks, and Queues head tail a b Figure 3.22 A doubly linked list with header and tail nodes head tail Figure 3.23 An empty doubly linked list with header and tail nodes The advantage of using these extra nodes is that they greatly simplify the coding by removing a host of special cases. For instance, if we do not use a header node, then remov- ing the first node becomes a special case, because we must reset the list’s link to the first node during the remove, and also because the remove algorithm in general needs to access the node prior to the node being removed (and without a header node, the first node does not have a node prior to it). Figure 3.22 shows a doubly linked list with header and tail nodes. Figure 3.23 shows an empty list. Figure 3.24 shows the outline and partial implementation of the MyLinkedList class. We can see at line 3 the beginning of the declaration of the private nested Node class. Figure 3.25 shows the Node class, consisting of the stored item, links to the previous and next Node, and a constructor. All the data members are public. Recall that in a class, the data members are normally private. However, members in a nested class are visible even in the outer class. Since the Node class is private, the visibility of the data members in the Node class is irrelevant; the MyLinkedList methods can see all Node data members, and classes outside of MyLinkedList cannot see the Node class at all. Back in Figure 3.24, lines 46 to 49 contain the data members for MyLinkedList, namely the reference to the header and tail nodes. We also keep track of the size in a data mem- ber, so that the size method can be implemented in constant time. At line 47, we have one additional data field that is used to help the iterator detect changes in the collection. modCount represents the number of changes to the linked list since construction. Each call to add or remove will update modCount. The idea is that when an iterator is created, it will store the modCount of the collection. Each call to an iterator method (next or remove) will check the stored modCount in the iterator with the current modCount in the linked list and will throw a ConcurrentModificationException if these two counts don’t match. The rest of the MyLinkedList class consists of the constructor, the implementation of the iterator, and a host of methods. Many of the methods are one-liners. 1 public class MyLinkedList implements Iterable
2 {
3 private static class Node
4 { /* Figure 3.25 */ }
5
6 public MyLinkedList( )
7 { doClear( ); }
8
9 public void clear( )

10 { /* Figure 3.26 */ }
11 public int size( )
12 { return theSize; }
13 public boolean isEmpty( )
14 { return size( ) == 0; }
15
16 public boolean add( AnyType x )
17 { add( size( ), x ); return true; }
18 public void add( int idx, AnyType x )
19 { addBefore( getNode( idx, 0, size( ) ), x ); }
20 public AnyType get( int idx )
21 { return getNode( idx ).data; }
22 public AnyType set( int idx, AnyType newVal )
23 {
24 Node p = getNode( idx );
25 AnyType oldVal = p.data;
26 p.data = newVal;
27 return oldVal;
28 }
29 public AnyType remove( int idx )
30 { return remove( getNode( idx ) ); }
31
32 private void addBefore( Node p, AnyType x )
33 { /* Figure 3.28 */ }
34 private AnyType remove( Node p )
35 { /* Figure 3.30 */ }
36 private Node getNode( int idx )
37 { /* Figure 3.31 */ }
38 private Node getNode( int idx, int lower, int upper )
39 { /* Figure 3.31 */ }
40
41 public java.util.Iterator iterator( )
42 { return new LinkedListIterator( ); }
43 private class LinkedListIterator implements java.util.Iterator
44 { /* Figure 3.32 */ }
45
46 private int theSize;
47 private int modCount = 0;
48 private Node beginMarker;
49 private Node endMarker;
50 }

Figure 3.24 MyLinkedList class

78 Chapter 3 Lists, Stacks, and Queues

1 private static class Node
2 {
3 public Node( AnyType d, Node p, Node n )
4 { data = d; prev = p; next = n; }
5
6 public AnyType data;
7 public Node prev;
8 public Node next;
9 }

Figure 3.25 Nested Node class for MyLinkedList class

1 public void clear( )
2 { doClear( ); }
3
4 private void doClear( )
5 {
6 beginMarker = new Node( null, null, null );
7 endMarker = new Node( null, beginMarker, null );
8 beginMarker.next = endMarker;
9

10 theSize = 0;
11 modCount++;
12 }

Figure 3.26 clear routine for MyLinkedList class, which invokes private doClear

The doClear method in Figure 3.26 is invoked by the constructor. It creates and
connects the header and tail nodes and then sets the size to 0.

In Figure 3.24, at line 43 we see the beginning of the declaration of the pri-
vate inner LinkedListIterator class. We’ll discuss those details when we see the actual
implementations later.

Figure 3.27 illustrates how a new node containing x is spliced in between a node
referenced by p and p.prev. The assignment to the node links can be described as follows:

Node newNode = new Node( x, p.prev, p ); // Steps 1 and 2
p.prev.next = newNode; // Step 3
p.prev = newNode; // Step 4

Steps 3 and 4 can be combined, yielding only two lines:

Node newNode = new Node( x, p.prev, p ); // Steps 1 and 2
p.prev = p.prev.next = newNode; // Steps 3 and 4

But then these two lines can also be combined, yielding:

p.prev = p.prev.next = new Node( x, p.prev, p );

3.5 Implementation of LinkedList 79

prev

x

3

1

2
4

p

… …

Figure 3.27 Insertion in a doubly linked list by getting new node and then changing
pointers in the order indicated

This makes the addBefore routine in Figure 3.28 short.
Figure 3.29 shows the logic of removing a node. If p references the node being

removed, only two links change before the node is disconnected and eligible to be
reclaimed by the Virtual Machine:

p.prev.next = p.next;
p.next.prev = p.prev;

1 /**
2 * Adds an item to this collection, at specified position p.
3 * Items at or after that position are slid one position higher.
4 * @param p Node to add before.
5 * @param x any object.
6 * @throws IndexOutOfBoundsException if idx is not between 0 and size(),.
7 */
8 private void addBefore( Node p, AnyType x )
9 {

10 Node newNode = new Node<>( x, p.prev, p );
11 newNode.prev.next = newNode;
12 p.prev = newNode;
13 theSize++;
14 modCount++;
15 }

Figure 3.28 add routine for MyLinkedList class

p

. . .. . .

Figure 3.29 Removing node specified by p from a doubly linked list

80 Chapter 3 Lists, Stacks, and Queues

1 /**
2 * Removes the object contained in Node p.
3 * @param p the Node containing the object.
4 * @return the item was removed from the collection.
5 */
6 private AnyType remove( Node p )
7 {
8 p.next.prev = p.prev;
9 p.prev.next = p.next;

10 theSize–;
11 modCount++;
12
13 return p.data;
14 }

Figure 3.30 remove routine for MyLinkedList class

Figure 3.30 shows the basic private remove routine that contains the two lines of code
shown above.

Figure 3.31 has the previously mentioned private getNode methods. If the index repre-
sents a node in the first half of the list, then at lines 29 to 34 we step through the linked
list, in the forward direction. Otherwise, we go backward, starting at the end, as shown in
lines 37 to 39.

The LinkedListIterator, shown in Figure 3.32, has logic that is similar to the
ArrayListIterator but incorporates significant error checking. The iterator maintains a cur-
rent position, shown at line 3. current represents the node containing the item that is to
be returned by a call to next. Observe that when current is positioned at the endMarker, a
call to next is illegal.

In order to detect a situation in which the collection has been modified during the
iteration, at line 4 the iterator stores in the data field expectedModCount the modCount of the
linked list at the time the iterator is constructed. At line 5, the Boolean data field okToRemove
is true if a next has been performed, without a subsequent remove. Thus okToRemove is
initially false, set to true in next, and set to false in remove.

hasNext is fairly routine. As in java.util.LinkedList’s iterator, it does not check for
modification of the linked list.

The next method advances current (line 18) after getting the value in the node (line
17) that is to be returned (line 20). okToRemove is updated at line 19.

Finally, the iterator’s remove method is shown at lines 23 to 33. It is mostly error check-
ing (which is why we avoided the error checks in the ArrayListIterator). The actual remove
at line 30 mimics the logic in the ArrayListIterator. But here, current remains unchanged,
because the node that current is viewing is unaffected by the removal of the prior node (in
the ArrayListIterator, items shifted, requiring an update of current).

3.5 Implementation of LinkedList 81

1 /**
2 * Gets the Node at position idx, which must range from 0 to size( ) – 1.
3 * @param idx index to search at.
4 * @return internal node corresponding to idx.
5 * @throws IndexOutOfBoundsException if idx is not
6 * between 0 and size( ) – 1, inclusive.
7 */
8 private Node getNode( int idx )
9 {

10 return getNode( idx, 0, size( ) – 1 );
11 }
12
13 /**
14 * Gets the Node at position idx, which must range from lower to upper.
15 * @param idx index to search at.
16 * @param lower lowest valid index.
17 * @param upper highest valid index.
18 * @return internal node corresponding to idx.
19 * @throws IndexOutOfBoundsException if idx is not
20 * between lower and upper, inclusive.
21 */
22 private Node getNode( int idx, int lower, int upper )
23 {
24 Node p;
25
26 if( idx < lower || idx > upper )
27 throw new IndexOutOfBoundsException( );
28
29 if( idx < size( ) / 2 ) 30 { 31 p = beginMarker.next; 32 for( int i = 0; i < idx; i++ ) 33 p = p.next; 34 } 35 else 36 { 37 p = endMarker; 38 for( int i = size( ); i > idx; i– )
39 p = p.prev;
40 }
41
42 return p;
43 }

Figure 3.31 Private getNode routine for MyLinkedList class

82 Chapter 3 Lists, Stacks, and Queues

1 private class LinkedListIterator implements java.util.Iterator
2 {
3 private Node current = beginMarker.next;
4 private int expectedModCount = modCount;
5 private boolean okToRemove = false;
6
7 public boolean hasNext( )
8 { return current != endMarker; }
9

10 public AnyType next( )
11 {
12 if( modCount != expectedModCount )
13 throw new java.util.ConcurrentModificationException( );
14 if( !hasNext( ) )
15 throw new java.util.NoSuchElementException( );
16
17 AnyType nextItem = current.data;
18 current = current.next;
19 okToRemove = true;
20 return nextItem;
21 }
22
23 public void remove( )
24 {
25 if( modCount != expectedModCount )
26 throw new java.util.ConcurrentModificationException( );
27 if( !okToRemove )
28 throw new IllegalStateException( );
29
30 MyLinkedList.false.remove( current.prev );
31 expectedModCount++;
32 okToRemove = false;
33 }
34 }

Figure 3.32 Inner Iterator class for MyList class

3.6 The Stack ADT

3.6.1 Stack Model
A stack is a list with the restriction that insertions and deletions can be performed in only
one position, namely, the end of the list, called the top. The fundamental operations on a
stack are push, which is equivalent to an insert, and pop, which deletes the most recently

3.6 The Stack ADT 83

push
Stack

pop

top

Figure 3.33 Stack model: input to a stack is by push, output is by pop and top

6

3

1

4

2
top

Figure 3.34 Stack model: Only the top element is accessible

inserted element. The most recently inserted element can be examined prior to performing
a pop by use of the top routine. A pop or top on an empty stack is generally considered an
error in the stack ADT. On the other hand, running out of space when performing a push is
an implementation limit but not an ADT error.

Stacks are sometimes known as LIFO (last in, first out) lists. The model depicted in
Figure 3.33 signifies only that pushes are input operations and pops and tops are output.
The usual operations to make empty stacks and test for emptiness are part of the repertoire,
but essentially all that you can do to a stack is push and pop.

Figure 3.34 shows an abstract stack after several operations. The general model is that
there is some element that is at the top of the stack, and it is the only element that is visible.

3.6.2 Implementation of Stacks
Since a stack is a list, any list implementation will do. Clearly ArrayList and LinkedList sup-
port stack operations; 99% of the time they are the most reasonable choice. Occasionally
it can be faster to design a special-purpose implementation (for instance, if the items being
placed on the stack are a primitive type). Because stack operations are constant-time oper-
ations, this is unlikely to yield any discernable improvement except under very unique
circumstances. For these special times, we will give two popular implementations. One

84 Chapter 3 Lists, Stacks, and Queues

uses a linked structure and the other uses an array, and both simplify the logic in ArrayList
and LinkedList, so we do not provide code.

Linked List Implementation of Stacks
The first implementation of a stack uses a singly linked list. We perform a push by inserting
at the front of the list. We perform a pop by deleting the element at the front of the list.
A top operation merely examines the element at the front of the list, returning its value.
Sometimes the pop and top operations are combined into one.

Array Implementation of Stacks
An alternative implementation avoids links and is probably the more popular solution.
Mimicking the ArrayList add operation, the implementation is trivial. Associated with each
stack is theArray and topOfStack, which is −1 for an empty stack (this is how an empty
stack is initialized). To push some element x onto the stack, we increment topOfStack and
then set theArray[topOfStack] = x. To pop, we set the return value to theArray[topOfStack]
and then decrement topOfStack.

Notice that these operations are performed in not only constant time, but very fast con-
stant time. On some machines, pushes and pops (of integers) can be written in one machine
instruction, operating on a register with auto-increment and auto-decrement addressing.
The fact that most modern machines have stack operations as part of the instruction
set enforces the idea that the stack is probably the most fundamental data structure in
computer science, after the array.

3.6.3 Applications
It should come as no surprise that if we restrict the operations allowed on a list, those oper-
ations can be performed very quickly. The big surprise, however, is that the small number
of operations left are so powerful and important. We give three of the many applications
of stacks. The third application gives a deep insight into how programs are organized.

Balancing Symbols
Compilers check your programs for syntax errors, but frequently a lack of one symbol
(such as a missing brace or comment starter) will cause the compiler to spill out a hundred
lines of diagnostics without identifying the real error. (Fortunately, most Java compilers are
pretty good about this. But not all languages and compilers are as responsible.)

A useful tool in this situation is a program that checks whether everything is balanced.
Thus, every right brace, bracket, and parenthesis must correspond to its left counterpart.
The sequence [()] is legal, but [(]) is wrong. Obviously, it is not worthwhile writing a
huge program for this, but it turns out that it is easy to check these things. For simplicity,
we will just check for balancing of parentheses, brackets, and braces and ignore any other
character that appears.

The simple algorithm uses a stack and is as follows:

Make an empty stack. Read characters until end of file. If the character is an opening
symbol, push it onto the stack. If it is a closing symbol, then if the stack is empty report

3.6 The Stack ADT 85

an error. Otherwise, pop the stack. If the symbol popped is not the corresponding
opening symbol, then report an error. At end of file, if the stack is not empty report an
error.

You should be able to convince yourself that this algorithm works. It is clearly linear
and actually makes only one pass through the input. It is thus online and quite fast. Extra
work can be done to attempt to decide what to do when an error is reported—such as
identifying the likely cause.

Postfix Expressions
Suppose we have a pocket calculator and would like to compute the cost of a shopping
trip. To do so, we add a list of numbers and multiply the result by 1.06; this computes the
purchase price of some items with local sales tax added. If the items are 4.99, 5.99, and
6.99, then a natural way to enter this would be the sequence

4.99 + 5.99 + 6.99 ∗ 1.06 =
Depending on the calculator, this produces either the intended answer, 19.05, or the sci-
entific answer, 18.39. Most simple four-function calculators will give the first answer, but
many advanced calculators know that multiplication has higher precedence than addition.

On the other hand, some items are taxable and some are not, so if only the first and
last items were actually taxable, then the sequence

4.99 ∗ 1.06 + 5.99 + 6.99 ∗ 1.06 =
would give the correct answer (18.69) on a scientific calculator and the wrong answer
(19.37) on a simple calculator. A scientific calculator generally comes with parentheses, so
we can always get the right answer by parenthesizing, but with a simple calculator we need
to remember intermediate results.

A typical evaluation sequence for this example might be to multiply 4.99 and 1.06,
saving this answer as A1. We then add 5.99 and A1, saving the result in A1. We multiply
6.99 and 1.06, saving the answer in A2, and finish by adding A1 and A2, leaving the final
answer in A1. We can write this sequence of operations as follows:

4.99 1.06 ∗ 5.99 + 6.99 1.06 ∗ +
This notation is known as postfix or reverse Polish notation and is evaluated exactly as
we have described above. The easiest way to do this is to use a stack. When a number is
seen, it is pushed onto the stack; when an operator is seen, the operator is applied to the
two numbers (symbols) that are popped from the stack, and the result is pushed onto the
stack. For instance, the postfix expression

6 5 2 3 + 8 ∗ + 3 + ∗
is evaluated as follows: The first four symbols are placed on the stack. The resulting
stack is

86 Chapter 3 Lists, Stacks, and Queues

3
2
5
6

topOfStack →

Next a ‘+’ is read, so 3 and 2 are popped from the stack and their sum, 5, is pushed.

5
5

6

topOfStack →

Next 8 is pushed.

5
5
8

6

topOfStack →

Now a ‘∗’ is seen, so 8 and 5 are popped and 5 ∗ 8 = 40 is pushed.

40
5
6

topOfStack →

Next a ‘+’ is seen, so 40 and 5 are popped and 5 + 40 = 45 is pushed.

45
6

topOfStack →

3.6 The Stack ADT 87

Now, 3 is pushed.

45
6

3topOfStack →

Next ‘+’ pops 3 and 45 and pushes 45 + 3 = 48.

48
6

topOfStack →

Finally, a ‘∗’ is seen and 48 and 6 are popped; the result, 6 ∗ 48 = 288, is pushed.

288topOfStack →

The time to evaluate a postfix expression is O(N), because processing each element in
the input consists of stack operations and thus takes constant time. The algorithm to do
so is very simple. Notice that when an expression is given in postfix notation, there is no
need to know any precedence rules; this is an obvious advantage.

Infix to Postfix Conversion
Not only can a stack be used to evaluate a postfix expression, but we can also use a stack
to convert an expression in standard form (otherwise known as infix) into postfix. We
will concentrate on a small version of the general problem by allowing only the operators
+, *, (, ), and insisting on the usual precedence rules. We will further assume that the
expression is legal. Suppose we want to convert the infix expression

a + b * c + ( d * e + f ) * g

into postfix. A correct answer is a b c * + d e * f + g * +.
When an operand is read, it is immediately placed onto the output. Operators are not

immediately output, so they must be saved somewhere. The correct thing to do is to place
operators that have been seen, but not placed on the output, onto the stack. We will also
stack left parentheses when they are encountered. We start with an initially empty stack.

88 Chapter 3 Lists, Stacks, and Queues

If we see a right parenthesis, then we pop the stack, writing symbols until we encounter
a (corresponding) left parenthesis, which is popped but not output.

If we see any other symbol (+, *, (), then we pop entries from the stack until we find
an entry of lower priority. One exception is that we never remove a ( from the stack except
when processing a ). For the purposes of this operation, + has lowest priority and ( highest.
When the popping is done, we push the operator onto the stack.

Finally, if we read the end of input, we pop the stack until it is empty, writing symbols
onto the output.

The idea of this algorithm is that when an operator is seen, it is placed on the stack.
The stack represents pending operators. However, some of the operators on the stack that
have high precedence are now known to be completed and should be popped, as they will
no longer be pending. Thus prior to placing the operator on the stack, operators that are
on the stack and are to be completed prior to the current operator, are popped. This is
illustrated in the following table:

Stack When Third
Expression Operator Is Processed Action

a*b-c+d – – is completed; + is pushed
a/b+c*d + Nothing is completed; * is pushed
a-b*c/d – * * is completed; / is pushed
a-b*c+d – * * and – are completed; + is pushed

Parentheses simply add an additional complication. We can view a left parenthesis
as a high-precedence operator when it is an input symbol (so that pending operators
remain pending), and a low-precedence operator when it is on the stack (so that it is
not accidentally removed by an operator). Right parentheses are treated as the special case.

To see how this algorithm performs, we will convert the long infix expression above
into its postfix form. First, the symbol a is read, so it is passed through to the output. Then
+ is read and pushed onto the stack. Next b is read and passed through to the output. The
state of affairs at this juncture is as follows:

a b
OutputStack

+

Next a * is read. The top entry on the operator stack has lower precedence than *, so
nothing is output and * is put on the stack. Next, c is read and output. Thus far, we have

a b c
OutputStack

+
*

3.6 The Stack ADT 89

The next symbol is a +. Checking the stack, we find that we will pop a * and place it on
the output; pop the other +, which is not of lower but equal priority, on the stack; and then
push the +.

a b c * +
OutputStack

+

The next symbol read is a (, which, being of highest precedence, is placed on the stack.
Then d is read and output.

a b c * + d
OutputStack

+

(

We continue by reading a *. Since open parentheses do not get removed except when a
closed parenthesis is being processed, there is no output. Next, e is read and output.

a b c * + d e
OutputStack

+
(
*

The next symbol read is a +. We pop and output * and then push +. Then we read and
output f.

a b c * + d e * f
OutputStack

+
(

+

Now we read a ), so the stack is emptied back to the (. We output a +.

a b c * + d e * f +
OutputStack

+

We read a * next; it is pushed onto the stack. Then g is read and output.

90 Chapter 3 Lists, Stacks, and Queues

a b c * + d e * f + g
OutputStack

+
*

The input is now empty, so we pop and output symbols from the stack until it is empty.

a b c * + d e * f + g * +
OutputStack

As before, this conversion requires only O(N) time and works in one pass through the
input. We can add subtraction and division to this repertoire by assigning subtraction and
addition equal priority and multiplication and division equal priority. A subtle point is that
the expression a-b-c will be converted to ab-c- and not abc–. Our algorithm does the right
thing, because these operators associate from left to right. This is not necessarily the case

in general, since exponentiation associates right to left: 22
3 = 28 = 256, not 43 = 64. We

leave as an exercise the problem of adding exponentiation to the repertoire of operators.

Method Calls
The algorithm to check balanced symbols suggests a way to implement method calls in
compiled procedural and object-oriented languages.1 The problem here is that when a call
is made to a new method, all the variables local to the calling routine need to be saved
by the system, since otherwise the new method will overwrite the memory used by the
calling routine’s variables. Furthermore, the current location in the routine must be saved
so that the new method knows where to go after it is done. The variables have generally
been assigned by the compiler to machine registers, and there are certain to be conflicts
(usually all methods get some variables assigned to register #1), especially if recursion is
involved. The reason that this problem is similar to balancing symbols is that a method call
and method return are essentially the same as an open parenthesis and closed parenthesis,
so the same ideas should work.

When there is a method call, all the important information that needs to be saved, such
as register values (corresponding to variable names) and the return address (which can be
obtained from the program counter, which is typically in a register), is saved “on a piece
of paper” in an abstract way and put at the top of a pile. Then the control is transferred
to the new method, which is free to replace the registers with its values. If it makes other
method calls, it follows the same procedure. When the method wants to return, it looks
at the “paper” at the top of the pile and restores all the registers. It then makes the return
jump.

1 Since Java is interpreted, rather than compiled, some details in this section may not apply to Java, but the
general concepts still do in Java and many other languages.

3.6 The Stack ADT 91

1 /**
2 * Print container from itr.
3 */
4 public static void printList( Iterator itr )
5 {
6 if( !itr.hasNext( ) )
7 return;
8
9 System.out.println( itr.next( ) );

10 printList( itr );
11 }

Figure 3.35 A bad use of recursion: printing a linked list

Clearly, all of this work can be done using a stack, and that is exactly what happens in
virtually every programming language that implements recursion. The information saved
is called either an activation record or stack frame. Typically, a slight adjustment is made:
The current environment is represented at the top of the stack. Thus, a return gives the
previous environment (without copying). The stack in a real computer frequently grows
from the high end of your memory partition downward, and on many non-Java systems
there is no checking for overflow. There is always the possibility that you will run out of
stack space by having too many simultaneously active methods. Needless to say, running
out of stack space is always a fatal error.

In languages and systems that do not check for stack overflow, programs crash without
an explicit explanation. In Java, an exception is thrown.

In normal events, you should not run out of stack space; doing so is usually an indica-
tion of runaway recursion (forgetting a base case). On the other hand, some perfectly legal
and seemingly innocuous programs can cause you to run out of stack space. The routine in
Figure 3.35, which prints out a collection, is perfectly legal and actually correct. It properly
handles the base case of an empty collection, and the recursion is fine. This program can be
proven correct. Unfortunately, if the collection contains 20,000 elements to print, there will
be a stack of 20,000 activation records representing the nested calls of line 10. Activation
records are typically large because of all the information they contain, so this program is
likely to run out of stack space. (If 20,000 elements are not enough to make the program
crash, replace the number with a larger one.)

This program is an example of an extremely bad use of recursion known as tail
recursion. Tail recursion refers to a recursive call at the last line. Tail recursion can be
mechanically eliminated by enclosing the body in a while loop and replacing the recursive
call with one assignment per method argument. This simulates the recursive call because
nothing needs to be saved; after the recursive call finishes, there is really no need to know
the saved values. Because of this, we can just go to the top of the method with the val-
ues that would have been used in a recursive call. The method in Figure 3.36 shows the
mechanically improved version. Removal of tail recursion is so simple that some compilers
do it automatically. Even so, it is best not to find out that yours does not.

92 Chapter 3 Lists, Stacks, and Queues

1 /**
2 * Print container from itr.
3 */
4 public static void printList( Iterator itr )
5 {
6 while( true )
7 {
8 if( !itr.hasNext( ) )
9 return;

10
11 System.out.println( itr.next( ) );
12 }
13 }

Figure 3.36 Printing a list without recursion; a compiler might do this

Recursion can always be completely removed (compilers do so in converting to assem-
bly language), but doing so can be quite tedious. The general strategy requires using a
stack and is worthwhile only if you can manage to put the bare minimum on the stack. We
will not dwell on this further, except to point out that although nonrecursive programs are
certainly generally faster than equivalent recursive programs, the speed advantage rarely
justifies the lack of clarity that results from removing the recursion.

3.7 The Queue ADT
Like stacks, queues are lists. With a queue, however, insertion is done at one end, whereas
deletion is performed at the other end.

3.7.1 Queue Model
The basic operations on a queue are enqueue, which inserts an element at the end of the list
(called the rear), and dequeue, which deletes (and returns) the element at the start of the
list (known as the front). Figure 3.37 shows the abstract model of a queue.

3.7.2 Array Implementation of Queues
As with stacks, any list implementation is legal for queues. Like stacks, both the linked list
and array implementations give fast O(1) running times for every operation. The linked
list implementation is straightforward and left as an exercise. We will now discuss an array
implementation of queues.

For each queue data structure, we keep an array, theArray, and the positions front and
back, which represent the ends of the queue. We also keep track of the number of elements

3.7 The Queue ADT 93

enqueue
Queue

dequeue

Figure 3.37 Model of a queue

that are actually in the queue, currentSize. The following figure shows a queue in some
intermediate state.

front back

15 2 7

↑↑

The operations should be clear. To enqueue an element x, we increment currentSize
and back, then set theArray[back]=x. To dequeue an element, we set the return value to
theArray[front], decrement currentSize, and then increment front. Other strategies are
possible (this is discussed later). We will comment on checking for errors presently.

There is one potential problem with this implementation. After 10 enqueues, the queue
appears to be full, since back is now at the last array index, and the next enqueue would
be in a nonexistent position. However, there might only be a few elements in the queue,
because several elements may have already been dequeued. Queues, like stacks, frequently
stay small even in the presence of a lot of operations.

The simple solution is that whenever front or back gets to the end of the array, it is
wrapped around to the beginning. The following figures show the queue during some
operations. This is known as a circular array implementation.

front back

2 4

Initial State

↑ ↑

frontback

21 4

After enqueue(1)

↑ ↑

94 Chapter 3 Lists, Stacks, and Queues

frontback

21 3 4

After enqueue(3)

↑ ↑

frontback

21 3 4

After dequeue, Which Returns 2

↑ ↑

front back

21 3 4

After dequeue, Which Returns 4

↑ ↑

back
front

21 3 4

After dequeue, Which Returns 1

↑

frontback

21 3 4

After dequeue, Which Returns 3
and Makes the Queue Empty

↑ ↑

The extra code required to implement the wraparound is minimal (although it probably
doubles the running time). If incrementing either back or front causes it to go past the array,
the value is reset to the first position in the array.

Some programmers use different ways of representing the front and back of a queue.
For instance, some do not use an entry to keep track of the size, because they rely on the
base case that when the queue is empty, back = front-1. The size is computed implic-
itly by comparing back and front. This is a very tricky way to go, because there are some
special cases, so be very careful if you need to modify code written this way. If the cur-
rentSize is not maintained as an explicit data field, then the queue is full when there are
theArray.length-1 elements, since only theArray.length different sizes can be differenti-
ated, and one of these is 0. Pick any style you like and make sure that all your routines

3.7 The Queue ADT 95

are consistent. Since there are a few options for implementation, it is probably worth a
comment or two in the code, if you don’t use the currentSize field.

In applications where you are sure that the number of enqueues is not larger than the
capacity of the queue, the wraparound is not necessary. As with stacks, dequeues are rarely
performed unless the calling routines are certain that the queue is not empty. Thus error
checks are frequently skipped for this operation, except in critical code. This is generally
not justifiable, because the time savings that you are likely to achieve are minimal.

3.7.3 Applications of Queues
There are many algorithms that use queues to give efficient running times. Several of these
are found in graph theory, and we will discuss them in Chapter 9. For now, we will give
some simple examples of queue usage.

When jobs are submitted to a printer, they are arranged in order of arrival. Thus,
essentially, jobs sent to a line printer are placed on a queue.2

Virtually every real-life line is (supposed to be) a queue. For instance, lines at ticket
counters are queues, because service is first-come first-served.

Another example concerns computer networks. There are many network setups of
personal computers in which the disk is attached to one machine, known as the file server.
Users on other machines are given access to files on a first-come first-served basis, so the
data structure is a queue.

Further examples include the following:

� Calls to large companies are generally placed on a queue when all operators are busy.
� In large universities, where resources are limited, students must sign a waiting list

if all terminals are occupied. The student who has been at a terminal the longest is
forced off first, and the student who has been waiting the longest is the next user to be
allowed on.

A whole branch of mathematics, known as queuing theory, deals with computing,
probabilistically, how long users expect to wait on a line, how long the line gets, and other
such questions. The answer depends on how frequently users arrive to the line and how
long it takes to process a user once the user is served. Both of these parameters are given as
probability distribution functions. In simple cases, an answer can be computed analytically.
An example of an easy case would be a phone line with one operator. If the operator is busy,
callers are placed on a waiting line (up to some maximum limit). This problem is important
for businesses, because studies have shown that people are quick to hang up the phone.

If there are k operators, then this problem is much more difficult to solve. Problems
that are difficult to solve analytically are often solved by a simulation. In our case, we
would need to use a queue to perform the simulation. If k is large, we also need other data
structures to do this efficiently. We shall see how to do this simulation in Chapter 6. We

2 We say essentially because jobs can be killed. This amounts to a deletion from the middle of the queue,
which is a violation of the strict definition.

96 Chapter 3 Lists, Stacks, and Queues

could then run the simulation for several values of k and choose the minimum k that gives
a reasonable waiting time.

Additional uses for queues abound, and as with stacks, it is staggering that such a
simple data structure can be so important.

Summary

This chapter describes the concept of ADTs and illustrates the concept with three of the
most common abstract data types. The primary objective is to separate the implementation
of the abstract data types from their function. The program must know what the operations
do, but it is actually better off not knowing how it is done.

Lists, stacks, and queues are perhaps the three fundamental data structures in all of
computer science, and their use is documented through a host of examples. In particular,
we saw how stacks are used to keep track of method calls and how recursion is actually
implemented. This is important to understand, not just because it makes procedural lan-
guages possible, but because knowing how recursion is implemented removes a good deal
of the mystery that surrounds its use. Although recursion is very powerful, it is not an
entirely free operation; misuse and abuse of recursion can result in programs crashing.

Exercises

3.1 You are given a list, L, and another list, P, containing integers sorted in ascending
order. The operation printLots(L,P) will print the elements in L that are in positions
specified by P. For instance, if P = 1, 3, 4, 6, the elements in positions 1, 3, 4, and 6
in L are printed. Write the procedure printLots(L,P). You may use only the public
Collections API container operations. What is the running time of your procedure?

3.2 Swap two adjacent elements by adjusting only the links (and not the data) using:
a. Singly linked lists.
b. Doubly linked lists.

3.3 Implement the contains routine for MyLinkedList.

3.4 Given two sorted lists, L1 and L2, write a procedure to compute L1 ∩ L2 using only
the basic list operations.

3.5 Given two sorted lists, L1 and L2, write a procedure to compute L1 ∪ L2 using only
the basic list operations.

3.6 The Josephus problem is the following game: N people, numbered 1 to N, are sitting
in a circle. Starting at person 1, a hot potato is passed. After M passes, the person
holding the hot potato is eliminated, the circle closes ranks, and the game continues
with the person who was sitting after the eliminated person picking up the hot
potato. The last remaining person wins. Thus, if M = 0 and N = 5, players are
eliminated in order, and player 5 wins. If M = 1 and N = 5, the order of elimination
is 2, 4, 1, 5.

Exercises 97

a. Write a program to solve the Josephus problem for general values of M and N.
Try to make your program as efficient as possible. Make sure you dispose of
cells.

b. What is the running time of your program?

3.7 What is the running time of the following code?

public static List makeList( int N )
{

ArrayList lst = new ArrayList<>( );

for( int i = 0; i < N; i++ ) { lst.add( i ); lst.trimToSize( ); } } 3.8 The following routine removes the first half of the list passed as a parameter: public static void removeFirstHalf( List lst )
{

int theSize = lst.size( ) / 2;

for( int i = 0; i < theSize; i++ ) lst.remove( 0 ); } a. Why is theSize saved prior to entering the for loop? b. What is the running time of removeFirstHalf if lst is an ArrayList? c. What is the running time of removeFirstHalf if lst is a LinkedList? d. Does using an iterator make removeHalf faster for either type of List? 3.9 Provide an implementation of an addAll method for the MyArrayList class. Method addAll adds all items in the specified collection given by items to the end of the MyArrayList. Also provide the running time of your implementation. The method signature for you to use is slightly different than the one in the Java Collections API, and is as follows: public void addAll( Iterable items )

3.10 Provide an implementation of a removeAll method for the MyLinkedList class.
Method removeAll removes all items in the specified collection given by items
from the MyLinkedList. Also provide the running time of your implementation.
The method signature for you to use is slightly different than the one in the Java
Collections API, and is as follows:

public void removeAll( Iterable items )

98 Chapter 3 Lists, Stacks, and Queues

3.11 Assume that a singly linked list is implemented with a header node, but no tail
node, and that it maintains only a reference to the header node. Write a class that
includes methods to
a. return the size of the linked list
b. print the linked list
c. test if a value x is contained in the linked list
d. add a value x if it is not already contained in the linked list
e. remove a value x if it is contained in the linked list

3.12 Repeat Exercise 3.11, maintaining the singly linked list in sorted order.

3.13 Add support for a ListIterator to the MyArrayList class. The ListIterator inter-
face in java.util has more methods than are shown in Section 3.3.5. Notice that
you will write a listIterator method to return a newly constructed ListIterator,
and further, that the existing iterator method can return a newly constructed
ListIterator. Thus you will change ArrayListIterator so that it implements
ListIterator instead of Iterator. Throw an UnsupportedOperationException for
methods not listed in Section 3.3.5.

3.14 Add support for a ListIterator to the MyLinkedList class, as was done in
Exercise 3.13.

3.15 Add a splice operation to the LinkedList class. The method declaration

public void splice(Iterator itr, MyLinkedList lst )

removes all the items from lst (making lst empty), placing them prior to itr in
MyLinkedList this. lst and this must be different lists. Your routine must run in
constant time.

3.16 An alternative to providing a ListIterator is to provide a method with signature

Iterator reverseIterator( )

that returns an Iterator, initialized to the last item, and for which next and hasNext
are implemented to be consistent with the iterator advancing toward the front of
the list, rather than the back. Then you could print a MyArrayList L in reverse by
using the code

Iterator ritr = L.reverseIterator( );
while( ritr.hasNext( ) )

System.out.println( ritr.next( ) );

Implement an ArrayListReverseIterator class, with this logic, and have reverseIt-
erator return a newly constructed ArrayListReverseIterator.

3.17 Modify the MyArrayList class to provide stringent iterator checking by using the
techniques seen in Section 3.5 for MyLinkedList.

3.18 For MyLinkedList, implement addFirst, addLast, removeFirst, removeLast, getFirst,
and getLast by making calls to the private add, remove, and getNode routines,
respectively.

Exercises 99

3.19 Rewrite the MyLinkedList class without using header and tail nodes and describe
the differences between the class and the class provided in Section 3.5.

3.20 An alternative to the deletion strategy we have given is to use lazy deletion. To
delete an element, we merely mark it deleted (using an extra bit field). The number
of deleted and nondeleted elements in the list is kept as part of the data structure. If
there are as many deleted elements as nondeleted elements, we traverse the entire
list, performing the standard deletion algorithm on all marked nodes.
a. List the advantages and disadvantages of lazy deletion.
b. Write routines to implement the standard linked list operations using lazy

deletion.

3.21 Write a program to check for balancing symbols in the following languages:
a. Pascal (begin/end, (), [], {}).
b. Java (/* */, (), [], {} ).

�c. Explain how to print out an error message that is likely to reflect the probable
cause.

3.22 Write a program to evaluate a postfix expression.

3.23 a. Write a program to convert an infix expression that includes (, ), +, -, *, and /
to postfix.

b. Add the exponentiation operator to your repertoire.
c. Write a program to convert a postfix expression to infix.

3.24 Write routines to implement two stacks using only one array. Your stack routines
should not declare an overflow unless every slot in the array is used.

3.25 �a. Propose a data structure that supports the stack push and pop operations and a
third operation findMin, which returns the smallest element in the data structure,
all in O(1) worst-case time.

�b. Prove that if we add the fourth operation deleteMin which finds and removes the
smallest element, then at least one of the operations must take �(log N) time.
(This requires reading Chapter 7.)

�3.26 Show how to implement three stacks in one array.

3.27 If the recursive routine in Section 2.4 used to compute Fibonacci numbers is run
for N = 50, is stack space likely to run out? Why or why not?

3.28 A deque is a data structure consisting of a list of items, on which the following
operations are possible:

push(x): Insert item x on the front end of the deque.
pop(): Remove the front item from the deque and return it.
inject(x): Insert item x on the rear end of the deque.
eject(): Remove the rear item from the deque and return it.

Write routines to support the deque that take O(1) time per operation.

3.29 Write an algorithm for printing a singly linked list in reverse, using only constant
extra space. This instruction implies that you cannot use recursion, but you may
assume that your algorithm is a list member function.

100 Chapter 3 Lists, Stacks, and Queues

3.30 a. Write an array implementation of self-adjusting lists. In a self-adjusting list, all
insertions are performed at the front. A self-adjusting list adds a find operation,
and when an element is accessed by a find, it is moved to the front of the list
without changing the relative order of the other items.

b. Write a linked list implementation of self-adjusting lists.
�c. Suppose each element has a fixed probability, pi, of being accessed. Show that

the elements with highest access probability are expected to be close to the front.

3.31 Efficiently implement a stack class using a singly linked list, with no header or tail
nodes.

3.32 Efficiently implement a queue class using a singly linked list, with no header or tail
nodes.

3.33 Efficiently implement a queue class using a circular array.

3.34 A linked list contains a cycle if, starting from some node p, following a sufficient
number of next links brings us back to node p. p does not have to be the first node
in the list. Assume that you are given a linked list that contains N nodes. However,
the value of N is unknown.
a. Design an O(N) algorithm to determine if the list contains a cycle. You may use

O(N) extra space.
�b. Repeat part (a), but use only O(1) extra space. (Hint: Use two iterators that are

initially at the start of the list, but advance at different speeds.)

3.35 One way to implement a queue is to use a circular linked list. In a circular linked
list, the last node’s next link links to the first node. Assume the list does not contain
a header and that we can maintain, at most, one iterator corresponding to a node in
the list. For which of the following representations can all basic queue operations
be performed in constant worst-case time? Justify your answers.
a. Maintain an iterator that corresponds to the first item in the list.
b. Maintain an iterator that corresponds to the last item in the list.

3.36 Suppose we have a reference to a node in a singly linked list that is guaranteed not
to be the last node in the list. We do not have references to any other nodes (except
by following links). Describe an O(1) algorithm that logically removes the value
stored in such a node from the linked list, maintaining the integrity of the linked
list. (Hint: Involve the next node.)

3.37 Suppose that a singly linked list is implemented with both a header and a tail node.
Describe constant-time algorithms to
a. Insert item x before position p (given by an iterator).
b. Remove the item stored at position p (given by an iterator).

C H A P T E R 4

Trees

For large amounts of input, the linear access time of linked lists is prohibitive. In this
chapter we look at a simple data structure for which the running time of most opera-
tions is O(log N) on average. We also sketch a conceptually simple modification to this
data structure that guarantees the above time bound in the worst case and discuss a sec-
ond modification that essentially gives an O(log N) running time per operation for a long
sequence of instructions.

The data structure that we are referring to is known as a binary search tree. The binary
search tree is the basis for the implementation of two library collections classes, TreeSet and
TreeMap, which are used in many applications. Trees in general are very useful abstractions
in computer science, so we will discuss their use in other, more general applications. In
this chapter, we will

� See how trees are used to implement the file system of several popular operating
systems.

� See how trees can be used to evaluate arithmetic expressions.
� Show how to use trees to support searching operations in O(log N) average time, and

how to refine these ideas to obtain O(log N) worst-case bounds. We will also see how
to implement these operations when the data are stored on a disk.

� Discuss and use the TreeSet and TreeMap classes.

4.1 Preliminaries
A tree can be defined in several ways. One natural way to define a tree is recursively. A
tree is a collection of nodes. The collection can be empty; otherwise, a tree consists of a
distinguished node r, called the root, and zero or more nonempty (sub)trees T1, T2, . . . , Tk,
each of whose roots are connected by a directed edge from r.

The root of each subtree is said to be a child of r, and r is the parent of each subtree
root. Figure 4.1 shows a typical tree using the recursive definition.

From the recursive definition, we find that a tree is a collection of N nodes, one of
which is the root, and N − 1 edges. That there are N − 1 edges follows from the fact that
each edge connects some node to its parent, and every node except the root has one parent
(see Figure 4.2). 101

102 Chapter 4 Trees

root

. . .
T1 T10

T2 T4
T3

Figure 4.1 Generic tree

A

B C D E F G

H I J K L M N

P Q

Figure 4.2 A tree

In the tree of Figure 4.2, the root is A. Node F has A as a parent and K, L, and M as
children. Each node may have an arbitrary number of children, possibly zero. Nodes with
no children are known as leaves; the leaves in the tree above are B, C, H, I, P, Q, K, L, M, and
N. Nodes with the same parent are siblings; thus K, L, and M are all siblings. Grandparent
and grandchild relations can be defined in a similar manner.

A path from node n1 to nk is defined as a sequence of nodes n1, n2, . . . , nk such that ni
is the parent of ni+1 for 1 ≤ i < k. The length of this path is the number of edges on the path, namely k − 1. There is a path of length zero from every node to itself. Notice that in a tree there is exactly one path from the root to each node. For any node ni, the depth of ni is the length of the unique path from the root to ni. Thus, the root is at depth 0. The height of ni is the length of the longest path from ni to a leaf. Thus all leaves are at height 0. The height of a tree is equal to the height of the root. For the tree in Figure 4.2, E is at depth 1 and height 2; F is at depth 1 and height 1; the height of the tree is 3. The depth of a tree is equal to the depth of the deepest leaf; this is always equal to the height of the tree. If there is a path from n1 to n2, then n1 is an ancestor of n2 and n2 is a descendant of n1. If n1 �= n2, then n1 is a proper ancestor of n2 and n2 is a proper descendant of n1. 4.1.1 Implementation of Trees One way to implement a tree would be to have in each node, besides its data, a link to each child of the node. However, since the number of children per node can vary so greatly and is not known in advance, it might be infeasible to make the children direct links in the data 4.1 Preliminaries 103 class TreeNode { Object element; TreeNode firstChild; TreeNode nextSibling; } Figure 4.3 Node declarations for trees A B C D E F G H I J K L M N P Q Figure 4.4 First child/next sibling representation of the tree shown in Figure 4.2 structure, because there would be too much wasted space. The solution is simple: Keep the children of each node in a linked list of tree nodes. The declaration in Figure 4.3 is typical. Figure 4.4 shows how a tree might be represented in this implementation. Arrows that point downward are firstChild links. Horizontal arrows are nextSibling links. Null links are not drawn, because there are too many. In the tree of Figure 4.4, node E has both a link to a sibling (F) and a link to a child (I), while some nodes have neither. 4.1.2 Tree Traversals with an Application There are many applications for trees. One of the popular uses is the directory structure in many common operating systems, including UNIX and DOS. Figure 4.5 is a typical directory in the UNIX file system. The root of this directory is /usr. (The asterisk next to the name indicates that /usr is itself a directory.) /usr has three children, mark, alex, and bill, which are them- selves directories. Thus, /usr contains three directories and no regular files. The filename /usr/mark/book/ch1.r is obtained by following the leftmost child three times. Each / after the first indicates an edge; the result is the full pathname. This hierarchical file system is very popular, because it allows users to organize their data logically. Furthermore, two files in different directories can share the same name, because they must have different paths from the root and thus have different pathnames. A directory in the UNIX file system is just a file with a list of all its children, so the directories are structured almost exactly in accordance 104 Chapter 4 Trees ch1.r ch2.r ch3.r book* mark* course* junk cop3530* fall* fall* fall*spr* sum* syl.r syl.r syl.r /usr* alex* bill* junk work* course* cop3212* grades prog1.r prog2.r gradesprog1.rprog2.r Figure 4.5 UNIX directory private void listAll( int depth ) { 1 printName( depth ); // Print the name of the object 2 if( isDirectory( ) ) 3 for each file c in this directory (for each child) 4 c.listAll( depth + 1 ); } public void listAll( ) { listAll( 0 ); } Figure 4.6 Pseudocode to list a directory in a hierarchical file system with the type declaration above.1 Indeed, on some versions of UNIX, if the normal com- mand to print a file is applied to a directory, then the names of the files in the directory can be seen in the output (along with other non-ASCII information). Suppose we would like to list the names of all of the files in the directory. Our output format will be that files that are depth di will have their names indented by di tabs. Our algorithm is given in Figure 4.6 as pseudocode.2 The heart of the algorithm is the recursive method listAll. This routine needs to be started with a depth of 0, to signify no indenting for the root. This depth is an internal bookkeeping variable and is hardly a parameter that a calling routine should be expected to know about. Thus the driver routine is used to interface the recursive routine to the outside world. 1 Each directory in the UNIX file system also has one entry that points to itself and another entry that points to the parent of the directory. Thus, technically, the UNIX file system is not a tree, but is treelike. 2 The Java code to implement this is provided in the file FileSystem.java online. It uses Java features that have not been discussed in the text. 4.1 Preliminaries 105 /usr mark book ch1.r ch2.r ch3.r course cop3530 fall syl.r spr syl.r sum syl.r junk alex junk bill work course cop3212 fall grades prog1.r prog2.r fall prog2.r prog1.r grades Figure 4.7 The (preorder) directory listing The logic of the algorithm is simple to follow. The name of the file object is printed out with the appropriate number of tabs. If the entry is a directory, then we process all children recursively, one by one. These children are one level deeper and thus need to be indented an extra space. The output is in Figure 4.7. This traversal strategy is known as a preorder traversal. In a preorder traversal, work at a node is performed before (pre) its children are processed. When this program is run, it is clear that line 1 is executed exactly once per node, since each name is output once. Since line 1 is executed at most once per node, line 2 must also be executed once per node. Furthermore, line 4 can be executed at most once for each child of each node. But the number of children is exactly one less than the number of nodes. Finally, the for loop iterates once per execution of line 4, plus once each time the loop ends. Thus, the total amount of work is constant per node. If there are N file names to be output, then the running time is O(N). 106 Chapter 4 Trees ch1.r(3) ch2.r(2) ch3.r(4) book*(1) mark*(1) course*(1) junk (6) cop3530*(1) fall*(1) spr*(1) sum*(1) syl.r(1) syl.r(5) syl.r(2) /usr*(1) alex*(1) bill*(1) junk (8) work*(1) course*(1) cop3212*(1) fall*(1) fall*(1) grades(3) prog1.r(4) prog2.r(1) grades(9)prog1.r(7)prog2.r(2) Figure 4.8 UNIX directory with file sizes obtained via postorder traversal public int size( ) { 1 int totalSize = sizeOfThisFile( ); 2 if( isDirectory( ) ) 3 for each file c in this directory (for each child) 4 totalSize += c.size( ); 5 return totalSize; } Figure 4.9 Pseudocode to calculate the size of a directory Another common method of traversing a tree is the postorder traversal. In a postorder traversal, the work at a node is performed after (post) its children are evaluated. As an example, Figure 4.8 represents the same directory structure as before, with the numbers in parentheses representing the number of disk blocks taken up by each file. Since the directories are themselves files, they have sizes too. Suppose we would like to calculate the total number of blocks used by all the files in the tree. The most natural way to do this would be to find the number of blocks contained in the subdirectories /usr/mark (30), /usr/alex (9), and /usr/bill (32). The total number of blocks is then the total in the subdirectories (71) plus the one block used by /usr, for a total of 72. The pseudocode method size in Figure 4.9 implements this strategy. If the current object is not a directory, then size merely returns the number of blocks it uses. Otherwise, the number of blocks used by the directory is added to the number of blocks (recursively) found in all the children. To see the difference between the postorder traversal strategy and the preorder traversal strategy, Figure 4.10 shows how the size of each directory or file is produced by the algorithm. 4.2 Binary Trees 107 ch1.r 3 ch2.r 2 ch3.r 4 book 10 syl.r 1 fall 2 syl.r 5 spr 6 syl.r 2 sum 3 cop3530 12 course 13 junk 6 mark 30 junk 8 alex 9 work 1 grades 3 prog1.r 4 prog2.r 1 fall 9 prog2.r 2 prog1.r 7 grades 9 fall 19 cop3212 29 course 30 bill 32 /usr 72 Figure 4.10 Trace of the size function 4.2 Binary Trees A binary tree is a tree in which no node can have more than two children. Figure 4.11 shows that a binary tree consists of a root and two subtrees, TL and TR, both of which could possibly be empty. A property of a binary tree that is sometimes important is that the depth of an average binary tree is considerably smaller than N. An analysis shows that the average depth is O( √ N), and that for a special type of binary tree, namely the binary search tree, the average value of the depth is O(log N). Unfortunately, the depth can be as large as N − 1, as the example in Figure 4.12 shows. 108 Chapter 4 Trees root TL TR Figure 4.11 Generic binary tree A B C D E Figure 4.12 Worst-case binary tree 4.2.1 Implementation Because a binary tree node has at most two children, we can keep direct links to them. The declaration of tree nodes is similar in structure to that for doubly linked lists in that a node is a structure consisting of the element information plus two references (left and right) to other nodes (see Figure 4.13). We could draw the binary trees using the rectangular boxes that are customary for linked lists, but trees are generally drawn as circles connected by lines, because they are class BinaryNode { // Friendly data; accessible by other package routines Object element; // The data in the node BinaryNode left; // Left child BinaryNode right; // Right child } Figure 4.13 Binary tree node class 4.2 Binary Trees 109 actually graphs. We also do not explicitly draw null links when referring to trees, because every binary tree with N nodes would require N + 1 null links. Binary trees have many important uses not associated with searching. One of the principal uses of binary trees is in the area of compiler design, which we will now explore. 4.2.2 An Example: Expression Trees Figure 4.14 shows an example of an expression tree. The leaves of an expression tree are operands, such as constants or variable names, and the other nodes contain operators. This particular tree happens to be binary, because all the operators are binary, and although this is the simplest case, it is possible for nodes to have more than two children. It is also possible for a node to have only one child, as is the case with the unary minus operator. We can evaluate an expression tree, T, by applying the operator at the root to the values obtained by recursively evaluating the left and right subtrees. In our example, the left subtree evaluates to a + (b * c) and the right subtree evaluates to ((d * e) + f) * g. The entire tree therefore represents (a + (b * c)) + (((d * e) + f) * g). We can produce an (overly parenthesized) infix expression by recursively producing a parenthesized left expression, then printing out the operator at the root, and finally recur- sively producing a parenthesized right expression. This general strategy (left, node, right) is known as an inorder traversal; it is easy to remember because of the type of expression it produces. An alternate traversal strategy is to recursively print out the left subtree, the right sub- tree, and then the operator. If we apply this strategy to our tree above, the output is a b c * + d e * f + g * +, which is easily seen to be the postfix representation of Section 3.6.3. This traversal strategy is generally known as a postorder traversal. We have seen this traversal strategy earlier in Section 4.1. A third traversal strategy is to print out the operator first and then recursively print out the left and right subtrees. The resulting expression, + + a * b c * + * d e f g, is the less useful prefix notation and the traversal strategy is a preorder traversal, which we have also seen earlier in Section 4.1. We will return to these traversal strategies later in the chapter. a + b * c + d * e + f * g Figure 4.14 Expression tree for (a + b * c) + ((d * e + f ) * g) 110 Chapter 4 Trees Constructing an Expression Tree We now give an algorithm to convert a postfix expression into an expression tree. Since we already have an algorithm to convert infix to postfix, we can generate expression trees from the two common types of input. The method we describe strongly resembles the postfix evaluation algorithm of Section 3.6.3. We read our expression one symbol at a time. If the symbol is an operand, we create a one-node tree and push it onto a stack. If the symbol is an operator, we pop two trees T1 and T2 from the stack (T1 is popped first) and form a new tree whose root is the operator and whose left and right children are T2 and T1, respectively. This new tree is then pushed onto the stack. As an example, suppose the input is a b + c d e + * * The first two symbols are operands, so we create one-node trees and push them onto a stack.3 a b Next, a + is read, so two trees are popped, a new tree is formed, and it is pushed onto the stack. + a b Next, c, d, and e are read, and for each a one-node tree is created and the corresponding tree is pushed onto the stack. 3 For convenience, we will have the stack grow from left to right in the diagrams. 4.2 Binary Trees 111 + a b c d e Now a + is read, so two trees are merged. + a b c + d e Continuing, a * is read, so we pop two trees and form a new tree with a * as root. + a b * c + d e Finally, the last symbol is read, two trees are merged, and the final tree is left on the stack. 112 Chapter 4 Trees * + a b * c + d e 4.3 The Search Tree ADT—Binary Search Trees An important application of binary trees is their use in searching. Let us assume that each node in the tree stores an item. In our examples, we will assume for simplicity that these are integers, although arbitrarily complex items are easily handled in Java. We will also assume that all the items are distinct and deal with duplicates later. The property that makes a binary tree into a binary search tree is that for every node, X, in the tree, the values of all the items in its left subtree are smaller than the item in X, and the values of all the items in its right subtree are larger than the item in X. Notice that this implies that all the elements in the tree can be ordered in some consistent manner. In Figure 4.15, the tree on the left is a binary search tree, but the tree on the right is not. The tree on the right has a node with item 7 in the left subtree of a node with item 6 (which happens to be the root). We now give brief descriptions of the operations that are usually performed on binary search trees. Note that because of the recursive definition of trees, it is common to write these routines recursively. Because the average depth of a binary search tree turns out to be O(log N), we generally do not need to worry about running out of stack space. The binary search tree requires that all the items can be ordered. To write a generic class, we need to provide an interface type that represents this property. This interface is Comparable, as described in Chapter 1. The interface tells us that two items in the tree can always be compared using a compareTo method. From this, we can determine all other possible relationships. Specifically, we do not use the equals method. Instead, two items are equal if and only if the compareTo method returns 0. An alternative, described in Section 4.3.1, is to allow a function object. Figure 4.16 also shows the BinaryNode class that, like the node class in the linked list class, is a nested class. 4.3 The Search Tree ADT—Binary Search Trees 113 6 2 8 1 4 3 6 2 8 1 4 3 7 Figure 4.15 Two binary trees (only the left tree is a search tree) 1 private static class BinaryNode
2 {
3 // Constructors
4 BinaryNode( AnyType theElement )
5 { this( theElement, null, null ); }
6
7 BinaryNode( AnyType theElement, BinaryNode lt, BinaryNode rt )
8 { element = theElement; left = lt; right = rt; }
9

10 AnyType element; // The data in the node
11 BinaryNode left; // Left child
12 BinaryNode right; // Right child
13 }

Figure 4.16 The BinaryNode class

Figure 4.17 shows the BinarySearchTree class skeleton. The single data field is a refer-
ence to the root node; this reference is null for empty trees. The public methods use the
general technique of calling private recursive methods.

We can now describe some of the private methods.

4.3.1 contains
This operation requires returning true if there is a node in tree T that has item X, or false if
there is no such node. The structure of the tree makes this simple. If T is empty, then we can
just return false. Otherwise, if the item stored at T is X, we can return true. Otherwise, we
make a recursive call on a subtree of T, either left or right, depending on the relationship
of X to the item stored in T. The code in Figure 4.18 is an implementation of this strategy.

Notice the order of the tests. It is crucial that the test for an empty tree be performed
first, since otherwise, we would generate a NullPointerException attempting to access a data
field through a null reference. The remaining tests are arranged with the least likely case

1 public class BinarySearchTree>
2 {
3 private static class BinaryNode
4 { /* Figure 4.16 */ }
5
6 private BinaryNode root;
7
8 public BinarySearchTree( )
9 { root = null; }

10
11 public void makeEmpty( )
12 { root = null; }
13 public boolean isEmpty( )
14 { return root == null; }
15
16 public boolean contains( AnyType x )
17 { return contains( x, root ); }
18 public AnyType findMin( )
19 { if( isEmpty( ) ) throw new UnderflowException( );
20 return findMin( root ).element;
21 }
22 public AnyType findMax( )
23 { if( isEmpty( ) ) throw new UnderflowException( );
24 return findMax( root ).element;
25 }
26 public void insert( AnyType x )
27 { root = insert( x, root ); }
28 public void remove( AnyType x )
29 { root = remove( x, root ); }
30 public void printTree( )
31 { /* Figure 4.56 */ }
32
33 private boolean contains( AnyType x, BinaryNode t )
34 { /* Figure 4.18 */ }
35 private BinaryNode findMin( BinaryNode t )
36 { /* Figure 4.20 */ }
37 private BinaryNode findMax( BinaryNode t )
38 { /* Figure 4.20 */ }
39
40 private BinaryNode insert( AnyType x, BinaryNode t )
41 { /* Figure 4.22 */ }
42 private BinaryNode remove( AnyType x, BinaryNode t )
43 { /* Figure 4.25 */ }
44 private void printTree( BinaryNode t )
45 { /* Figure 4.56 */ }
46 }

Figure 4.17 Binary search tree class skeleton

4.3 The Search Tree ADT—Binary Search Trees 115

1 /**
2 * Internal method to find an item in a subtree.
3 * @param x is item to search for.
4 * @param t the node that roots the subtree.
5 * @return true if the item is found; false otherwise.
6 */
7 private boolean contains( AnyType x, BinaryNode t )
8 {
9 if( t == null )

10 return false;
11
12 int compareResult = x.compareTo( t.element );
13
14 if( compareResult < 0 ) 15 return contains( x, t.left ); 16 else if( compareResult > 0 )
17 return contains( x, t.right );
18 else
19 return true; // Match
20 }

Figure 4.18 contains operation for binary search trees

last. Also note that both recursive calls are actually tail recursions and can be easily removed
with a while loop. The use of tail recursion is justifiable here because the simplicity of
algorithmic expression compensates for the decrease in speed, and the amount of stack
space used is expected to be only O(log N). Figure 4.19 shows the trivial changes required
to use a function object rather than requiring that the items be Comparable. This mimics the
idioms in Section 1.6.

4.3.2 findMin and findMax
These private routines return a reference to the node containing the smallest and largest
elements in the tree, respectively. To perform a findMin, start at the root and go left as long
as there is a left child. The stopping point is the smallest element. The findMax routine is
the same, except that branching is to the right child.

This is so easy that many programmers do not bother using recursion. We will code
the routines both ways by doing findMin recursively and findMax nonrecursively (see
Figure 4.20).

Notice how we carefully handle the degenerate case of an empty tree. Although this is
always important to do, it is especially crucial in recursive programs. Also notice that it is
safe to change t in findMax, since we are only working with a copy of a reference. Always
be extremely careful, however, because a statement such as t.right = t.right.right will
make changes.

116 Chapter 4 Trees

1 public class BinarySearchTree

2 {

3 private BinaryNode root;

4 private Comparator cmp;

5

6 public BinarySearchTree( )

7 { this( null ); }

8

9 public BinarySearchTree( Comparator c )

10 { root = null; cmp = c; }

11

12 private int myCompare( AnyType lhs, AnyType rhs )

13 {

14 if( cmp != null )

15 return cmp.compare( lhs, rhs );

16 else

17 return ((Comparable)lhs).compareTo( rhs );

18 }

19

20 private boolean contains( AnyType x, BinaryNode t )

21 {

22 if( t == null )

23 return false;

24

25 int compareResult = myCompare( x, t.element );

26

27 if( compareResult < 0 ) 28 return contains( x, t.left ); 29 else if( compareResult > 0 )

30 return contains( x, t.right );

31 else

32 return true; // Match

33 }

34

35 // Remainder of class is similar with calls to compareTo replaced by myCompare

36 }

Figure 4.19 Illustrates use of a function object to implement binary search tree

4.3.3 insert
The insertion routine is conceptually simple. To insert X into tree T, proceed down the
tree as you would with a contains. If X is found, do nothing (or “update” something).
Otherwise, insert X at the last spot on the path traversed. Figure 4.21 shows what happens.

4.3 The Search Tree ADT—Binary Search Trees 117

1 /**
2 * Internal method to find the smallest item in a subtree.
3 * @param t the node that roots the subtree.
4 * @return node containing the smallest item.
5 */
6 private BinaryNode findMin( BinaryNode t )
7 {
8 if( t == null )
9 return null;

10 else if( t.left == null )
11 return t;
12 return findMin( t.left );
13 }
14
15 /**
16 * Internal method to find the largest item in a subtree.
17 * @param t the node that roots the subtree.
18 * @return node containing the largest item.
19 */
20 private BinaryNode findMax( BinaryNode t )
21 {
22 if( t != null )
23 while( t.right != null )
24 t = t.right;
25
26 return t;
27 }

Figure 4.20 Recursive implementation of findMin and nonrecursive implementation of
findMax for binary search trees

To insert 5, we traverse the tree as though a contains were occurring. At the node with
item 4, we need to go right, but there is no subtree, so 5 is not in the tree, and this is the
correct spot.

Duplicates can be handled by keeping an extra field in the node record indicating the
frequency of occurrence. This adds some extra space to the entire tree but is better than
putting duplicates in the tree (which tends to make the tree very deep). Of course, this
strategy does not work if the key that guides the compareTo method is only part of a larger
structure. If that is the case, then we can keep all of the structures that have the same key
in an auxiliary data structure, such as a list or another search tree.

Figure 4.22 shows the code for the insertion routine. Since t references the root of the
tree, and the root changes on the first insertion, insert is written as a method that returns
a reference to the root of the new tree. Lines 15 and 17 recursively insert and attach x into
the appropriate subtree.

118 Chapter 4 Trees

6

2 8

1 4

3

6

2 8

1 4

3 5

Figure 4.21 Binary search trees before and after inserting 5

1 /**
2 * Internal method to insert into a subtree.
3 * @param x the item to insert.
4 * @param t the node that roots the subtree.
5 * @return the new root of the subtree.
6 */
7 private BinaryNode insert( AnyType x, BinaryNode t )
8 {
9 if( t == null )

10 return new BinaryNode<>( x, null, null );
11
12 int compareResult = x.compareTo( t.element );
13
14 if( compareResult < 0 ) 15 t.left = insert( x, t.left ); 16 else if( compareResult > 0 )
17 t.right = insert( x, t.right );
18 else
19 ; // Duplicate; do nothing
20 return t;
21 }

Figure 4.22 Insertion into a binary search tree

4.3.4 remove
As is common with many data structures, the hardest operation is deletion. Once we have
found the node to be deleted, we need to consider several possibilities.

If the node is a leaf, it can be deleted immediately. If the node has one child, the node
can be deleted after its parent adjusts a link to bypass the node (we will draw the link
directions explicitly for clarity). See Figure 4.23.

4.3 The Search Tree ADT—Binary Search Trees 119

6

2 8

1 4

3

6

2 8

1 4

3

Figure 4.23 Deletion of a node (4) with one child, before and after

6

2 8

1 5

3

4

6

3 8

1 5

3

4

Figure 4.24 Deletion of a node (2) with two children, before and after

The complicated case deals with a node with two children. The general strategy is to
replace the data of this node with the smallest data of the right subtree (which is easily
found) and recursively delete that node (which is now empty). Because the smallest node
in the right subtree cannot have a left child, the second remove is an easy one. Figure 4.24
shows an initial tree and the result of a deletion. The node to be deleted is the left child of
the root; the key value is 2. It is replaced with the smallest data in its right subtree (3), and
then that node is deleted as before.

The code in Figure 4.25 performs deletion. It is inefficient, because it makes two passes
down the tree to find and delete the smallest node in the right subtree when this is appro-
priate. It is easy to remove this inefficiency by writing a special removeMin method, and we
have left it in only for simplicity.

If the number of deletions is expected to be small, then a popular strategy to use is
lazy deletion: When an element is to be deleted, it is left in the tree and merely marked

120 Chapter 4 Trees

1 /**
2 * Internal method to remove from a subtree.
3 * @param x the item to remove.
4 * @param t the node that roots the subtree.
5 * @return the new root of the subtree.
6 */
7 private BinaryNode remove( AnyType x, BinaryNode t )
8 {
9 if( t == null )

10 return t; // Item not found; do nothing
11
12 int compareResult = x.compareTo( t.element );
13
14 if( compareResult < 0 ) 15 t.left = remove( x, t.left ); 16 else if( compareResult > 0 )
17 t.right = remove( x, t.right );
18 else if( t.left != null && t.right != null ) // Two children
19 {
20 t.element = findMin( t.right ).element;
21 t.right = remove( t.element, t.right );
22 }
23 else
24 t = ( t.left != null ) ? t.left : t.right;
25 return t;
26 }

Figure 4.25 Deletion routine for binary search trees

as being deleted. This is especially popular if duplicate items are present, because then the
field that keeps count of the frequency of appearance can be decremented. If the number
of real nodes in the tree is the same as the number of “deleted” nodes, then the depth of
the tree is only expected to go up by a small constant (why?), so there is a very small time
penalty associated with lazy deletion. Also, if a deleted item is reinserted, the overhead of
allocating a new cell is avoided.

4.3.5 Average-Case Analysis
Intuitively, we expect that all of the operations of the previous section should take O(log N)
time, because in constant time we descend a level in the tree, thus operating on a tree that
is now roughly half as large. Indeed, the running time of all the operations is O(d), where
d is the depth of the node containing the accessed item (in the case of remove this may be
the replacement node in the two-child case).

We prove in this section that the average depth over all nodes in a tree is O(log N) on
the assumption that all insertion sequences are equally likely.

4.3 The Search Tree ADT—Binary Search Trees 121

The sum of the depths of all nodes in a tree is known as the internal path length.
We will now calculate the average internal path length of a binary search tree, where the
average is taken over all possible insertion sequences into binary search trees.

Let D(N) be the internal path length for some tree T of N nodes. D(1) = 0. An N-node
tree consists of an i-node left subtree and an (N − i − 1)-node right subtree, plus a root at
depth zero for 0 ≤ i < N. D(i) is the internal path length of the left subtree with respect to its root. In the main tree, all these nodes are one level deeper. The same holds for the right subtree. Thus, we get the recurrence D(N) = D(i) + D(N − i − 1) + N − 1 If all subtree sizes are equally likely, which is true for binary search trees (since the subtree size depends only on the relative rank of the first element inserted into the tree), but not binary trees, then the average value of both D(i) and D(N − i−1) is (1/N)∑N−1j=0 D(j). This yields D(N) = 2 N ⎡ ⎣N−1∑ j=0 D(j) ⎤ ⎦ + N − 1 This recurrence will be encountered and solved in Chapter 7, obtaining an average value of D(N) = O(N log N). Thus, the expected depth of any node is O(log N). As an example, the randomly generated 500-node tree shown in Figure 4.26 has nodes at expected depth 9.98. It is tempting to say immediately that this result implies that the average running time of all the operations discussed in the previous section is O(log N), but this is not entirely Figure 4.26 A randomly generated binary search tree 122 Chapter 4 Trees Figure 4.27 Binary search tree after �(N2) insert/remove pairs true. The reason for this is that because of deletions, it is not clear that all binary search trees are equally likely. In particular, the deletion algorithm described above favors making the left subtrees deeper than the right, because we are always replacing a deleted node with a node from the right subtree. The exact effect of this strategy is still unknown, but it seems only to be a theoretical novelty. It has been shown that if we alternate insertions and deletions �(N2) times, then the trees will have an expected depth of �( √ N). After a quarter-million random insert/remove pairs, the tree that was somewhat right-heavy in Figure 4.26 looks decidedly unbalanced (average depth equals 12.51). See Figure 4.27. We could try to eliminate the problem by randomly choosing between the smallest element in the right subtree and the largest in the left when replacing the deleted element. This apparently eliminates the bias and should keep the trees balanced, but nobody has actually proved this. In any event, this phenomenon appears to be mostly a theoretical novelty, because the effect does not show up at all for small trees, and stranger still, if o(N2) insert/remove pairs are used, then the tree seems to gain balance! The main point of this discussion is that deciding what “average” means is gener- ally extremely difficult and can require assumptions that may or may not be valid. In the absence of deletions, or when lazy deletion is used, we can conclude that the average running times of the operations above are O(log N). Except for strange cases like the one discussed above, this result is very consistent with observed behavior. If the input comes into a tree presorted, then a series of inserts will take quadratic time and give a very expensive implementation of a linked list, since the tree will consist only of nodes with no left children. One solution to the problem is to insist on an extra structural condition called balance: No node is allowed to get too deep. There are quite a few general algorithms to implement balanced trees. Most are quite a bit more complicated than a standard binary search tree, and all take longer on average for updates. They do, however, provide protection against the embarrassingly simple cases. Below, we will sketch one of the oldest forms of balanced search trees, the AVL tree. 4.4 AVL Trees 123 A second, newer method is to forgo the balance condition and allow the tree to be arbitrarily deep, but after every operation, a restructuring rule is applied that tends to make future operations efficient. These types of data structures are generally classified as self-adjusting. In the case of a binary search tree, we can no longer guarantee an O(log N) bound on any single operation but can show that any sequence of M operations takes total time O(M log N) in the worst case. This is generally sufficient protection against a bad worst case. The data structure we will discuss is known as a splay tree; its analysis is fairly intricate and is discussed in Chapter 11. 4.4 AVL Trees An AVL (Adelson-Velskii and Landis) tree is a binary search tree with a balance condition. The balance condition must be easy to maintain, and it ensures that the depth of the tree is O(log N). The simplest idea is to require that the left and right subtrees have the same height. As Figure 4.28 shows, this idea does not force the tree to be shallow. Another balance condition would insist that every node must have left and right sub- trees of the same height. If the height of an empty subtree is defined to be −1 (as is usual), then only perfectly balanced trees of 2k − 1 nodes would satisfy this criterion. Thus, although this guarantees trees of small depth, the balance condition is too rigid to be useful and needs to be relaxed. An AVL tree is identical to a binary search tree, except that for every node in the tree, the height of the left and right subtrees can differ by at most 1. (The height of an empty tree is defined to be −1.) In Figure 4.29 the tree on the left is an AVL tree, but the tree on the right is not. Height information is kept for each node (in the node structure). It can be shown that the height of an AVL tree is at most roughly 1.44 log(N + 2) − 1.328, but in practice it is only slightly more than log N. As an example, the AVL tree of height 9 with the fewest nodes (143) is shown in Figure 4.30. This tree has as a left subtree an AVL tree of height 7 of minimum size. The right subtree is an AVL tree of height 8 of minimum size. This tells us that the minimum number of nodes, S(h), in an AVL tree of height h is given by S(h) = S(h − 1) + S(h − 2) + 1. For h = 0, S(h) = 1. For h = 1, S(h) = 2. The function Figure 4.28 A bad binary tree. Requiring balance at the root is not enough 124 Chapter 4 Trees 5 2 8 1 4 3 7 7 2 8 1 4 3 5 Figure 4.29 Two binary search trees. Only the left tree is AVL Figure 4.30 Smallest AVL tree of height 9 S(h) is closely related to the Fibonacci numbers, from which the bound claimed above on the height of an AVL tree follows. Thus, all the tree operations can be performed in O(log N) time, except possibly inser- tion (we will assume lazy deletion). When we do an insertion, we need to update all the balancing information for the nodes on the path back to the root, but the reason that inser- tion is potentially difficult is that inserting a node could violate the AVL tree property. (For instance, inserting 6 into the AVL tree in Figure 4.29 would destroy the balance condition 4.4 AVL Trees 125 at the node with key 8.) If this is the case, then the property has to be restored before the insertion step is considered over. It turns out that this can always be done with a simple modification to the tree, known as a rotation. After an insertion, only nodes that are on the path from the insertion point to the root might have their balance altered because only those nodes have their subtrees altered. As we follow the path up to the root and update the balancing information, we may find a node whose new balance violates the AVL condition. We will show how to rebalance the tree at the first (i.e., deepest) such node, and we will prove that this rebalancing guarantees that the entire tree satisfies the AVL property. Let us call the node that must be rebalanced α. Since any node has at most two chil- dren, and a height imbalance requires that α’s two subtrees’ height differ by two, it is easy to see that a violation might occur in four cases: 1. An insertion into the left subtree of the left child of α. 2. An insertion into the right subtree of the left child of α. 3. An insertion into the left subtree of the right child of α. 4. An insertion into the right subtree of the right child of α. Cases 1 and 4 are mirror image symmetries with respect to α, as are cases 2 and 3. Consequently, as a matter of theory, there are two basic cases. From a programming perspective, of course, there are still four cases. The first case, in which the insertion occurs on the “outside” (i.e., left–left or right– right), is fixed by a single rotation of the tree. The second case, in which the insertion occurs on the “inside” (i.e., left–right or right–left) is handled by the slightly more complex double rotation. These are fundamental operations on the tree that we’ll see used several times in balanced-tree algorithms. The remainder of this section describes these rotations, proves that they suffice to maintain balance, and gives a casual implementation of the AVL tree. Chapter 12 describes other balanced-tree methods with an eye toward a more careful implementation. 4.4.1 Single Rotation Figure 4.31 shows the single rotation that fixes case 1. The before picture is on the left, and the after is on the right. Let us analyze carefully what is going on. Node k2 violates the AVL balance property because its left subtree is two levels deeper than its right subtree (the dashed lines in the middle of the diagram mark the levels). The situation depicted is the only possible case 1 scenario that allows k2 to satisfy the AVL property before an insertion but violate it afterwards. Subtree X has grown to an extra level, causing it to be exactly two levels deeper than Z. Y cannot be at the same level as the new X because then k2 would have been out of balance before the insertion, and Y cannot be at the same level as Z because then k1 would be the first node on the path toward the root that was in violation of the AVL balancing condition. To ideally rebalance the tree, we would like to move X up a level and Z down a level. Note that this is actually more than the AVL property would require. To do this, we rearrange 126 Chapter 4 Trees k 2 k 1 Z Y X k 1 k 2 X ZY Figure 4.31 Single rotation to fix case 1 nodes into an equivalent tree as shown in the second part of Figure 4.31. Here is an abstract scenario: Visualize the tree as being flexible, grab the child node k1, close your eyes, and shake it, letting gravity take hold. The result is that k1 will be the new root. The binary search tree property tells us that in the original tree k2 > k1, so k2 becomes the right
child of k1 in the new tree. X and Z remain as the left child of k1 and right child of k2,
respectively. Subtree Y, which holds items that are between k1 and k2 in the original tree,
can be placed as k2’s left child in the new tree and satisfy all the ordering requirements.

As a result of this work, which requires only a few link changes, we have another binary
search tree that is an AVL tree. This happens because X moves up one level, Y stays at the
same level, and Z moves down one level. k2 and k1 not only satisfy the AVL requirements,
but they also have subtrees that are exactly the same height. Furthermore, the new height
of the entire subtree is exactly the same as the height of the original subtree prior to the
insertion that caused X to grow. Thus no further updating of heights on the path to the
root is needed, and consequently no further rotations are needed. Figure 4.32 shows that
after the insertion of 6 into the original AVL tree on the left, node 8 becomes unbalanced.
Thus, we do a single rotation between 7 and 8, obtaining the tree on the right.

As we mentioned earlier, case 4 represents a symmetric case. Figure 4.33 shows how a
single rotation is applied. Let us work through a rather long example. Suppose we start with
an initially empty AVL tree and insert the items 3, 2, 1, and then 4 through 7 in sequential

5

2 8

1 4

3

7

6

5

2 7

1 4

3

6 8

Figure 4.32 AVL property destroyed by insertion of 6, then fixed by a single rotation

4.4 AVL Trees 127

k 2

k 1

ZYX

k 1

k 2
X

Z

Y

Figure 4.33 Single rotation fixes case 4

order. The first problem occurs when it is time to insert 1 because the AVL property is
violated at the root. We perform a single rotation between the root and its left child to fix
the problem. Here are the before and after trees:

3 2

2 31

1 before after

A dashed line joins the two nodes that are the subject of the rotation. Next we insert 4,
which causes no problems, but the insertion of 5 creates a violation at node 3 that is fixed
by a single rotation. Besides the local change caused by the rotation, the programmer must
remember that the rest of the tree has to be informed of this change. Here this means that
2’s right child must be reset to link to 4 instead of 3. Forgetting to do so is easy and would
destroy the tree (4 would be inaccessible).

2

1 3

4

5

2

1 4

3 5

before after

Next we insert 6. This causes a balance problem at the root, since its left subtree is of
height 0 and its right subtree would be height 2. Therefore, we perform a single rotation at
the root between 2 and 4.

128 Chapter 4 Trees

2

1 4

3 5

6

4

2 5

1 3 6

before after

The rotation is performed by making 2 a child of 4 and 4’s original left subtree the new right
subtree of 2. Every item in this subtree must lie between 2 and 4, so this transformation
makes sense. The next item we insert is 7, which causes another rotation:

4

2 5

1 3 6

7

4

2 6

1 3 5 7

before after

4.4.2 Double Rotation
The algorithm described above has one problem: As Figure 4.34 shows, it does not work
for cases 2 or 3. The problem is that subtree Y is too deep, and a single rotation does not
make it any less deep. The double rotation that solves the problem is shown in Figure 4.35.

The fact that subtree Y in Figure 4.34 has had an item inserted into it guarantees that it
is nonempty. Thus, we may assume that it has a root and two subtrees. Consequently, the
tree may be viewed as four subtrees connected by three nodes. As the diagram suggests,

k2

k1
Z

Y
X

k1

k2

Z
Y

X

Figure 4.34 Single rotation fails to fix case 2

4.4 AVL Trees 129

D

CB

k2

k1k1
k2

k3

k3

AA D
B C

Figure 4.35 Left–right double rotation to fix case 2

k1

k3
k2A

B C

k2

k1 k3

AD D
B C

Figure 4.36 Right–left double rotation to fix case 3

exactly one of tree B or C is two levels deeper than D (unless all are empty), but we cannot
be sure which one. It turns out not to matter; in Figure 4.35, both B and C are drawn at
1 12 levels below D.

To rebalance, we see that we cannot leave k3 as the root, and a rotation between k3 and
k1 was shown in Figure 4.34 to not work, so the only alternative is to place k2 as the new
root. This forces k1 to be k2’s left child and k3 to be its right child, and it also completely
determines the resulting locations of the four subtrees. It is easy to see that the resulting
tree satisfies the AVL tree property, and as was the case with the single rotation, it restores
the height to what it was before the insertion, thus guaranteeing that all rebalancing and
height updating is complete. Figure 4.36 shows that the symmetric case 3 can also be fixed
by a double rotation. In both cases the effect is the same as rotating between α’s child and
grandchild, and then between α and its new child.

We will continue our previous example by inserting 10 through 16 in reverse order,
followed by 8 and then 9. Inserting 16 is easy, since it does not destroy the balance property,
but inserting 15 causes a height imbalance at node 7. This is case 3, which is solved by a
right–left double rotation. In our example, the right–left double rotation will involve 7, 16,
and 15. In this case, k1 is the node with item 7, k3 is the node with item 16, and k2 is the
node with item 15. Subtrees A, B, C, and D are empty.

130 Chapter 4 Trees

4

2 6

1 3 5 7

15

4

2 6

1 3 5 15

7 1616

k1

k3

k2

k1

k2

k3
before after

Next we insert 14, which also requires a double rotation. Here the double rotation that
will restore the tree is again a right–left double rotation that will involve 6, 15, and 7. In
this case, k1 is the node with item 6, k2 is the node with item 7, and k3 is the node with
item 15. Subtree A is the tree rooted at the node with item 5; subtree B is the empty subtree
that was originally the left child of the node with item 7, subtree C is the tree rooted at the
node with item 14, and finally, subtree D is the tree rooted at the node with item 16.

4 4

2 26

1 3 5 15

7 5 14 1616

14

7

1 3 6 15
k1

k2

k3

before after

k1

k3

k2

If 13 is now inserted, there is an imbalance at the root. Since 13 is not between 4 and 7,
we know that the single rotation will work.

4

2 7

1 3 6 15

5 14 16

13

7

4 15

2 6 14 16

1 3 5 13

before after

4.4 AVL Trees 131

Insertion of 12 will also require a single rotation:

7

4 15

2 6 14 16

1 3 5 13

12

7

4 15

2 6 13 16

1 3 5 12 14

before after

To insert 11, a single rotation needs to be performed, and the same is true for the
subsequent insertion of 10. We insert 8 without a rotation creating an almost perfectly
balanced tree:

7

4 13

2 6 11 15

1 3 5 10 12 14 16

8

before

Finally, we will insert 9 to show the symmetric case of the double rotation. Notice
that 9 causes the node containing 10 to become unbalanced. Since 9 is between 10 and 8

132 Chapter 4 Trees

(which is 10’s child on the path to 9), a double rotation needs to be performed, yielding
the following tree:

7

4 13

2 6 11 15

1 3 5 9 12 14 16

8 10

after

Let us summarize what happens. The programming details are fairly straightforward
except that there are several cases. To insert a new node with item X into an AVL tree T,
we recursively insert X into the appropriate subtree of T (let us call this TLR). If the height
of TLR does not change, then we are done. Otherwise, if a height imbalance appears in T,
we do the appropriate single or double rotation depending on X and the items in T and
TLR, update the heights (making the connection from the rest of the tree above), and are
done. Since one rotation always suffices, a carefully coded nonrecursive version generally
turns out to be faster than the recursive version, but on modern compilers the difference is
not as significant as in the past. However, nonrecursive versions are quite difficult to code
correctly, whereas a casual recursive implementation is easily readable.

Another efficiency issue concerns storage of the height information. Since all that is
really required is the difference in height, which is guaranteed to be small, we could get
by with two bits (to represent +1, 0, −1) if we really try. Doing so will avoid repetitive
calculation of balance factors but results in some loss of clarity. The resulting code is some-
what more complicated than if the height were stored at each node. If a recursive routine
is written, then speed is probably not the main consideration. In this case, the slight speed
advantage obtained by storing balance factors hardly seems worth the loss of clarity and
relative simplicity. Furthermore, since most machines will align this to at least an 8-bit
boundary anyway, there is not likely to be any difference in the amount of space used. An
eight-bit byte will allow us to store absolute heights of up to 127. Since the tree is balanced,
it is inconceivable that this would be insufficient (see the exercises).

With all this, we are ready to write the AVL routines. We show some of the code here;
the rest is online. First, we need the AvlNode class. This is given in Figure 4.37. We also

4.4 AVL Trees 133

1 private static class AvlNode
2 {
3 // Constructors
4 AvlNode( AnyType theElement )
5 { this( theElement, null, null ); }
6
7 AvlNode( AnyType theElement, AvlNode lt, AvlNode rt )
8 { element = theElement; left = lt; right = rt; height = 0; }
9

10 AnyType element; // The data in the node
11 AvlNode left; // Left child
12 AvlNode right; // Right child
13 int height; // Height
14 }

Figure 4.37 Node declaration for AVL trees

1 /**
2 * Return the height of node t, or -1, if null.
3 */
4 private int height( AvlNode t )
5 {
6 return t == null ? -1 : t.height;
7 }

Figure 4.38 Method to compute height of an AVL node

need a quick method to return the height of a node. This method is necessary to handle
the annoying case of a null reference. This is shown in Figure 4.38. The basic insertion
routine is easy to write (see Figure 4.39): It adds only a single line at the end that invokes
a balancing method. The balancing method applies a single or double rotation if needed,
updates the height, and returns the resulting tree.

For the trees in Figure 4.40, rotateWithLeftChild converts the tree on the left to the
tree on the right, returning a reference to the new root. rotateWithRightChild is symmetric.
The code is shown in Figure 4.41.

Similarly, the double rotation pictured in Figure 4.42 can be implemented by the code
shown in Figure 4.43.

Since deletion in a binary search tree is somewhat more complicated than insertion,
one can assume that deletion in an AVL tree is also more complicated. In a perfect world, one
would hope that the deletion routine in Figure 4.25 could easily be modified by changing
the last line to return after calling the balance method, as was done for insertion. This
would yield the code in Figure 4.44. This change works! A deletion could cause one side
of the tree to become two levels shallower than the other side. The case-by-case analysis
is similar to the imbalances that are caused by insertion, but not exactly the same. For

1 /**
2 * Internal method to insert into a subtree.
3 * @param x the item to insert.
4 * @param t the node that roots the subtree.
5 * @return the new root of the subtree.
6 */
7 private AvlNode insert( AnyType x, AvlNode t )
8 {
9 if( t == null )

10 return new AvlNode<>( x, null, null );
11
12 int compareResult = x.compareTo( t.element );
13
14 if( compareResult < 0 ) 15 t.left = insert( x, t.left ); 16 else if( compareResult > 0 )
17 t.right = insert( x, t.right );
18 else
19 ; // Duplicate; do nothing
20 return balance( t );
21 }
22
23 private static final int ALLOWED_IMBALANCE = 1;
24
25 // Assume t is either balanced or within one of being balanced
26 private AvlNode balance( AvlNode t )
27 {
28 if( t == null )
29 return t;
30
31 if( height( t.left ) – height( t.right ) > ALLOWED_IMBALANCE )
32 if( height( t.left.left ) >= height( t.left.right ) )
33 t = rotateWithLeftChild( t );
34 else
35 t = doubleWithLeftChild( t );
36 else
37 if( height( t.right ) – height( t.left ) > ALLOWED_IMBALANCE )
38 if( height( t.right.right ) >= height( t.right.left ) )
39 t = rotateWithRightChild( t );
40 else
41 t = doubleWithRightChild( t );
42
43 t.height = Math.max( height( t.left ), height( t.right ) ) + 1;
44 return t;
45 }

Figure 4.39 Insertion into an AVL tree

4.4 AVL Trees 135

k 2

Z
k 1

X Y

k 1

k 2

Y

X

Z

Figure 4.40 Single rotation

1 /**
2 * Rotate binary tree node with left child.
3 * For AVL trees, this is a single rotation for case 1.
4 * Update heights, then return new root.
5 */
6 private AvlNode rotateWithLeftChild( AvlNode k2 )
7 {
8 AvlNode k1 = k2.left;
9 k2.left = k1.right;

10 k1.right = k2;
11 k2.height = Math.max( height( k2.left ), height( k2.right ) ) + 1;
12 k1.height = Math.max( height( k1.left ), k2.height ) + 1;
13 return k1;
14 }

Figure 4.41 Routine to perform single rotation

k 3

D
k 1

k 2
A

CB

k 2

k 1 k 3

A B C D

Figure 4.42 Double rotation

instance, case 1 in Figure 4.31, which would now reflect a deletion from tree Z (rather
than an insertion into X), must be augmented with the possiblity that tree Y could be as
deep as tree X. Even so, it is easy to see that the rotation rebalances this case and the
symmetric case 4 in Figure 4.33. Thus the code for balance in Figure 4.39 lines 32 and
38 uses >= instead of > specifically to ensure that single rotations are done in these cases,
rather than double rotations. We leave verification of the remaining cases as an exercise.

136 Chapter 4 Trees

1 /**
2 * Double rotate binary tree node: first left child
3 * with its right child; then node k3 with new left child.
4 * For AVL trees, this is a double rotation for case 2.
5 * Update heights, then return new root.
6 */
7 private AvlNode doubleWithLeftChild( AvlNode k3 )
8 {
9 k3.left = rotateWithRightChild( k3.left );

10 return rotateWithLeftChild( k3 );
11 }

Figure 4.43 Routine to perform double rotation

1 /**
2 * Internal method to remove from a subtree.
3 * @param x the item to remove.
4 * @param t the node that roots the subtree.
5 * @return the new root of the subtree.
6 */
7 private AvlNode remove( AnyType x, AvlNode t )
8 {
9 if( t == null )

10 return t; // Item not found; do nothing
11
12 int compareResult = x.compareTo( t.element );
13
14 if( compareResult < 0 ) 15 t.left = remove( x, t.left ); 16 else if( compareResult > 0 )
17 t.right = remove( x, t.right );
18 else if( t.left != null && t.right != null ) // Two children
19 {
20 t.element = findMin( t.right ).element;
21 t.right = remove( t.element, t.right );
22 }
23 else
24 t = ( t.left != null ) ? t.left : t.right;
25 return balance( t );
26 }

Figure 4.44 Deletion in an AVL tree

4.5 Splay Trees 137

4.5 Splay Trees
We now describe a relatively simple data structure, known as a splay tree, that guarantees
that any M consecutive tree operations starting from an empty tree take at most O(M log N)
time. Although this guarantee does not preclude the possibility that any single operation
might take θ (N) time, and thus the bound is not as strong as an O(log N) worst-case bound
per operation, the net effect is the same: There are no bad input sequences. Generally, when
a sequence of M operations has total worst-case running time of O(Mf(N)), we say that the
amortized running time is O(f(N)). Thus, a splay tree has an O(log N) amortized cost per
operation. Over a long sequence of operations, some may take more, some less.

Splay trees are based on the fact that the O(N) worst-case time per operation for
binary search trees is not bad, as long as it occurs relatively infrequently. Any one
access, even if it takes θ (N), is still likely to be extremely fast. The problem with binary
search trees is that it is possible, and not uncommon, for a whole sequence of bad
accesses to take place. The cumulative running time then becomes noticeable. A search
tree data structure with O(N) worst-case time, but a guarantee of at most O(M log N)
for any M consecutive operations, is certainly satisfactory, because there are no bad
sequences.

If any particular operation is allowed to have an O(N) worst-case time bound, and
we still want an O(log N) amortized time bound, then it is clear that whenever a node is
accessed, it must be moved. Otherwise, once we find a deep node, we could keep perform-
ing accesses on it. If the node does not change location, and each access costs θ (N), then a
sequence of M accesses will cost θ (M · N).

The basic idea of the splay tree is that after a node is accessed, it is pushed to the root
by a series of AVL tree rotations. Notice that if a node is deep, there are many nodes on
the path that are also relatively deep, and by restructuring we can make future accesses
cheaper on all these nodes. Thus, if the node is unduly deep, then we want this restructur-
ing to have the side effect of balancing the tree (to some extent). Besides giving a good time
bound in theory, this method is likely to have practical utility, because in many appli-
cations, when a node is accessed, it is likely to be accessed again in the near future.
Studies have shown that this happens much more often than one would expect. Splay
trees also do not require the maintenance of height or balance information, thus saving
space and simplifying the code to some extent (especially when careful implementations
are written).

4.5.1 A Simple Idea (That Does Not Work)
One way of performing the restructuring described above is to perform single rotations,
bottom up. This means that we rotate every node on the access path with its parent. As an
example, consider what happens after an access (a find) on k1 in the following tree.

138 Chapter 4 Trees

k 3

D
k 2

k 1
A

CB

k 4

E

k 5

F

The access path is dashed. First, we would perform a single rotation between k1 and its
parent, obtaining the following tree.

k 3

D
k 1

k 2
C

BA

k 4

E

k 5

F

Then, we rotate between k1 and k3, obtaining the next tree.

k 3

DC

k 1

k 2

BA

k 4

E

k 5

F

Then two more rotations are performed until we reach the root.

4.5 Splay Trees 139

k 3

DC

k 1

k 2

BA

k 4

k 5

E

F

k 3

DC

k 1

k 2

BA
k 4

E

k 5

F

These rotations have the effect of pushing k1 all the way to the root, so that future
accesses on k1 are easy (for a while). Unfortunately, it has pushed another node (k3) almost
as deep as k1 used to be. An access on that node will then push another node deep, and
so on. Although this strategy makes future accesses of k1 cheaper, it has not significantly
improved the situation for the other nodes on the (original) access path. It turns out that
it is possible to prove that using this strategy, there is a sequence of M operations requiring
�(M · N) time, so this idea is not quite good enough. The simplest way to show this is to
consider the tree formed by inserting keys 1, 2, 3, . . . , N into an initially empty tree (work
this example out). This gives a tree consisting of only left children. This is not necessarily
bad, though, since the time to build this tree is O(N) total. The bad part is that accessing
the node with key 1 takes N − 1 units of time. After the rotations are complete, an access
of the node with key 2 takes N − 2 units of time. The total for accessing all the keys in
order is

∑N−1
i=1 i − �(N2). After they are accessed, the tree reverts to its original state, and

we can repeat the sequence.

4.5.2 Splaying
The splaying strategy is similar to the rotation idea above, except that we are a little more
selective about how rotations are performed. We will still rotate bottom up along the access

140 Chapter 4 Trees

G

D
P

X
A

CB

X

P G

A B C D

Figure 4.45 Zig-zag

X

BA

P

C

G

D

X

A

B
G

C D

P

Figure 4.46 Zig-zig

path. Let X be a (nonroot) node on the access path at which we are rotating. If the parent
of X is the root of the tree, we merely rotate X and the root. This is the last rotation along
the access path. Otherwise, X has both a parent (P) and a grandparent (G), and there are
two cases, plus symmetries, to consider. The first case is the zig-zag case (see Figure 4.45).
Here, X is a right child and P is a left child (or vice versa). If this is the case, we perform a
double rotation, exactly like an AVL double rotation. Otherwise, we have a zig-zig case: X
and P are both left children (or, in the symmetric case, both right children). In that case,
we transform the tree on the left of Figure 4.46 to the tree on the right.

As an example, consider the tree from the last example, with a contains on k1:

k 2

k 1
A

k 4

k 3
E

D

k 5

F

CB

The first splay step is at k1 and is clearly a zig-zag, so we perform a standard AVL double
rotation using k1, k2, and k3. The resulting tree follows.

4.5 Splay Trees 141

k 3

D

k 2

k 1

A CB

k 4

E

k 5

F

The next splay step at k1 is a zig-zig, so we do the zig-zig rotation with k1, k4, and k5,
obtaining the final tree.

k 3

D

k 2

k 1

A

C

B

k 4

k 5

E F

Although it is hard to see from small examples, splaying not only moves the accessed
node to the root but also has the effect of roughly halving the depth of most nodes on the
access path (some shallow nodes are pushed down at most two levels).

To see the difference that splaying makes over simple rotation, consider again the effect
of inserting items 1, 2, 3, . . . , N into an initially empty tree. This takes a total of O(N), as
before, and yields the same tree as simple rotations. Figure 4.47 shows the result of splaying

1

2

3

4

5

6

7 7

6

5

4

1

2

3

7

6

1

4

2 5

3

1

6

4 7

2 5

3

Figure 4.47 Result of splaying at node 1

142 Chapter 4 Trees

at the node with item 1. The difference is that after an access of the node with item 1, which
takes N−1 units, the access on the node with item 2 will only take about N/2 units instead
of N − 2 units; there are no nodes quite as deep as before.

An access on the node with item 2 will bring nodes to within N/4 of the root, and this
is repeated until the depth becomes roughly log N (an example with N = 7 is too small to
see the effect well). Figures 4.48 to 4.56 show the result of accessing items 1 through 9 in

1

32

30

28

26

24

22

20

18

16

14

12

10

8

6

4

2

3

5

7

9

11

13

15

17

19

21

23

25

27

29

31

Figure 4.48 Result of splaying at node 1 a tree of all left children

2

1 32

28

24

20

16

12

8

4

3 6

5 7

10

9 11

14

13 15

18

17 19

22

21 23

26

25 27

30

29 31

Figure 4.49 Result of splaying the previous tree at node 2

4.5 Splay Trees 143

3

2

1

28

20

12

4

8

6

5 7

10

9 11

16

14

13 15

18

17 19

24

22

21 23

26

25 27

32

30

29 31

Figure 4.50 Result of splaying the previous tree at node 3

4

3

2

1

28

12

8

6

5 7

10

9 11

20

16

14

13 15

18

17 19

24

22

21 23

26

25 27

32

30

29 31

Figure 4.51 Result of splaying the previous tree at node 4

5

4

3

2

1

12

6

8

7 10

9 11

28

20

16

14

13 15

18

17 19

24

22

21 23

26

25 27

32

30

29 31

Figure 4.52 Result of splaying the previous tree at node 5

a 32-node tree that originally contains only left children. Thus we do not get the same bad
behavior from splay trees that is prevalent in the simple rotation strategy. (Actually, this
turns out to be a very good case. A rather complicated proof shows that for this example,
the N accesses take a total of O(N) time.)

These figures highlight the fundamental and crucial property of splay trees. When
access paths are long, thus leading to a longer-than-normal search time, the rotations tend
to be good for future operations. When accesses are cheap, the rotations are not as good and
can be bad. The extreme case is the initial tree formed by the insertions. All the insertions
were constant-time operations leading to a bad initial tree. At that point in time, we had
a very bad tree, but we were running ahead of schedule and had the compensation of less
total running time. Then a couple of really horrible accesses left a nearly balanced tree,

144 Chapter 4 Trees

6

5

4

3

2

1

12

8

7 10

9 11

28

20

16

14

13 15

18

17 19

24

22

21 23

26

25 27

32

30

29 31

Figure 4.53 Result of splaying the previous tree at node 6

7

6

5

4

3

2

1

8

12

10

9 11

28

20

16

14

13 15

18

17 19

24

22

21 23

26

25 27

32

30

29 31

Figure 4.54 Result of splaying the previous tree at node 7

8

7

6

5

4

3

2

1

12

10

9 11

28

20

16

14

13 15

18

17 19

24

22

21 23

26

25 27

32

30

29 31

Figure 4.55 Result of splaying the previous tree at node 8

but the cost was that we had to give back some of the time that had been saved. The
main theorem, which we will prove in Chapter 11, is that we never fall behind a pace of
O(log N) per operation: We are always on schedule, even though there are occasionally bad
operations.

We can perform deletion by accessing the node to be deleted. This puts the node at the
root. If it is deleted, we get two subtrees TL and TR (left and right). If we find the largest
element in TL (which is easy), then this element is rotated to the root of TL, and TL will
now have a root with no right child. We can finish the deletion by making TR the right
child.

4.6 Tree Traversals (Revisited) 145

9

8

7

6

5

4

3

2

1

10

12

11 28

20

16

14

13 15

18

17 19

24

22

21 23

26

25 27

32

30

29 31

Figure 4.56 Result of splaying the previous tree at node 9

The analysis of splay trees is difficult, because it must take into account the
ever-changing structure of the tree. On the other hand, splay trees are much simpler to
program than AVL trees, since there are fewer cases to consider and no balance informa-
tion to maintain. Some empirical evidence suggests that this translates into faster code in
practice, although the case for this is far from complete. Finally, we point out that there are
several variations of splay trees that can perform even better in practice. One variation is
completely coded in Chapter 12.

4.6 Tree Traversals (Revisited)
Because of the ordering information in a binary search tree, it is simple to list all the items
in sorted order. The recursive method in Figure 4.57 does the real work.

Convince yourself that this method works. As we have seen before, this kind of routine
when applied to trees is known as an inorder traversal (which makes sense, since it lists
the items in order). The general strategy of an inorder traversal is to process the left subtree
first, then perform processing at the current node, and finally process the right subtree.
The interesting part about this algorithm, aside from its simplicity, is that the total running
time is O(N). This is because there is constant work being performed at every node in the
tree. Each node is visited once, and the work performed at each node is testing against
null, setting up two method calls, and doing a println. Since there is constant work per
node and N nodes, the running time is O(N).

Sometimes we need to process both subtrees first before we can process a node. For
instance, to compute the height of a node, we need to know the height of the subtrees
first. The code in Figure 4.58 computes this. Since it is always a good idea to check the
special cases—and crucial when recursion is involved—notice that the routine will declare
the height of a leaf to be zero, which is correct. This general order of traversal, which we
have also seen before, is known as a postorder traversal. Again, the total running time is
O(N), because constant work is performed at each node.

146 Chapter 4 Trees

1 /**
2 * Print the tree contents in sorted order.
3 */
4 public void printTree( )
5 {
6 if( isEmpty( ) )
7 System.out.println( “Empty tree” );
8 else
9 printTree( root );

10 }
11
12 /**
13 * Internal method to print a subtree in sorted order.
14 * @param t the node that roots the subtree.
15 */
16 private void printTree( BinaryNode t )
17 {
18 if( t != null )
19 {
20 printTree( t.left );
21 System.out.println( t.element );
22 printTree( t.right );
23 }
24 }

Figure 4.57 Routine to print a binary search tree in order

1 /**
2 * Internal method to compute height of a subtree.
3 * @param t the node that roots the subtree.
4 */
5 private int height( BinaryNode t )
6 {
7 if( t == null )
8 return -1;
9 else

10 return 1 + Math.max( height( t.left ), height( t.right ) );
11 }

Figure 4.58 Routine to compute the height of a tree using a postorder traversal

The third popular traversal scheme that we have seen is preorder traversal. Here, the
node is processed before the children. This could be useful, for example, if you wanted to
label each node with its depth.

4.7 B-Trees 147

The common idea in all these routines is that you handle the null case first, and then
the rest. Notice the lack of extraneous variables. These routines pass only the reference to
the node that roots the subtree and do not declare or pass any extra variables. The more
compact the code, the less likely that a silly bug will turn up. A fourth, less often used,
traversal (which we have not seen yet) is level-order traversal. In a level-order traversal,
all nodes at depth d are processed before any node at depth d + 1. Level-order traversal
differs from the other traversals in that it is not done recursively; a queue is used, instead
of the implied stack of recursion.

4.7 B-Trees
Thus far, we have assumed that we can store an entire data structure in the main memory
of a computer. Suppose, however, that we have more data than can fit in main memory,
meaning that we must have the data structure reside on disk. When this happens, the rules
of the game change because the Big-Oh model is no longer meaningful.

The problem is that a Big-Oh analysis assumes that all operations are equal. However,
this is not true, especially when disk I/O is involved. Modern computers execute billions
of instructions per second. That is pretty fast, mainly because the speed depends largely
on electrical properties. On the other hand, a disk is mechanical. Its speed depends largely
on the time it takes to spin the disk and to move a disk head. Many disks spin at 7,200
RPM. Thus in 1 min, it makes 7,200 revolutions; hence, one revolution occurs in 1/120 of
a second, or 8.3 ms. On average, we might expect that we have to spin a disk halfway to
find what we are looking for, but this is compensated by the time to move the disk head, so
we get an access time of 8.3 ms. (This is a very charitable estimate; 9–11 ms access times
are more common.) Consequently, we can do approximately 120 disk accesses per second.
This sounds pretty good, until we compare it with the processor speed. What we have is
billions of instructions equal to 120 disk accesses. Of course, everything here is a rough
calculation, but the relative speeds are pretty clear: Disk accesses are incredibly expensive.
Furthermore, processor speeds are increasing at a much faster rate than disk speeds (it is
disk sizes that are increasing quite quickly). So we are willing to do lots of calculations just
to save a disk access. In almost all cases, it is the number of disk accesses that will dominate
the running time. Thus, if we halve the number of disk accesses, the running time will also
halve.

Here is how the typical search tree performs on disk. Suppose we want to access the
driving records for citizens in the State of Florida. We assume that we have 10 million
items, that each key is 32 bytes (representing a name), and that a record is 256 bytes. We
assume this does not fit in main memory and that we are 1 of 20 users on a system (so
we have 1/20 of the resources). Thus, in 1 sec, we can execute billions of instructions or
perform six disk accesses.

The unbalanced binary search tree is a disaster. In the worst case, it has linear depth
and thus could require 10 million disk accesses. On average, a successful search would
require 1.38 log N disk accesses, and since log 10000000 ≈ 24, an average search would
require 32 disk accesses, or 5 sec. In a typical randomly constructed tree, we would expect

148 Chapter 4 Trees

Figure 4.59 5-ary tree of 31 nodes has only three levels

that a few nodes are three times deeper; these would require about 100 disk accesses, or 16
sec. An AVL tree is somewhat better. The worst case of 1.44 log N is unlikely to occur, and
the typical case is very close to log N. Thus an AVL tree would use about 25 disk accesses
on average, requiring 4 sec.

We want to reduce the number of disk accesses to a very small constant, such as
three or four; and we are willing to write complicated code to do this because machine
instructions are essentially free, as long as we are not ridiculously unreasonable. It should
probably be clear that a binary search tree will not work, since the typical AVL tree is close
to optimal height. We cannot go below log N using a binary search tree. The solution is
intuitively simple: If we have more branching, we have less height. Thus, while a perfect
binary tree of 31 nodes has five levels, a 5-ary tree of 31 nodes has only three levels,
as shown in Figure 4.59. An MMM-ary search tree allows M-way branching. As branching
increases, the depth decreases. Whereas a complete binary tree has height that is roughly
log2 N, a complete M-ary tree has height that is roughly logM N.

We can create an M-ary search tree in much the same way as a binary search tree. In a
binary search tree, we need one key to decide which of two branches to take. In an M-ary
search tree, we need M − 1 keys to decide which branch to take. To make this scheme
efficient in the worst case, we need to ensure that the M-ary search tree is balanced in some
way. Otherwise, like a binary search tree, it could degenerate into a linked list. Actually,
we want an even more restrictive balancing condition. That is, we do not want an M-ary
search tree to degenerate to even a binary search tree, because then we would be stuck
with log N accesses.

One way to implement this is to use a B-tree. The basic B-tree4 is described here. Many
variations and improvements are possible, and an implementation is somewhat complex
because there are quite a few cases. However, it is easy to see that, in principle, a B-tree
guarantees only a few disk accesses.

A B-tree of order M is an M-ary tree with the following properties:5

1. The data items are stored at leaves.

2. The nonleaf nodes store up to M − 1 keys to guide the searching; key i represents the
smallest key in subtree i + 1.

3. The root is either a leaf or has between two and M children.

4 What is described is popularly known as a B+ tree.
5 Rules 3 and 5 must be relaxed for the first L insertions.

4.7 B-Trees 149

4. All nonleaf nodes (except the root) have between �M/2� and M children.
5. All leaves are at the same depth and have between �L/2� and L data items, for some L

(the determination of L is described shortly).

An example of a B-tree of order 5 is shown in Figure 4.60. Notice that all nonleaf nodes
have between three and five children (and thus between two and four keys); the root could
possibly have only two children. Here, we have L = 5. (It happens that L and M are the
same in this example, but this is not necessary.) Since L is 5, each leaf has between three
and five data items. Requiring nodes to be half full guarantees that the B-tree does not
degenerate into a simple binary tree. Although there are various definitions of B-trees that
change this structure, mostly in minor ways, this definition is one of the popular forms.

Each node represents a disk block, so we choose M and L on the basis of the size of the
items that are being stored. As an example, suppose one block holds 8,192 bytes. In our
Florida example, each key uses 32 bytes. In a B-tree of order M, we would have M−1 keys,
for a total of 32M − 32 bytes, plus M branches. Since each branch is essentially a number
of another disk block, we can assume that a branch is 4 bytes. Thus the branches use 4M
bytes. The total memory requirement for a nonleaf node is thus 36M−32. The largest value
of M for which this is no more than 8,192 is 228. Thus we would choose M = 228. Since
each data record is 256 bytes, we would be able to fit 32 records in a block. Thus we would
choose L = 32. We are guaranteed that each leaf has between 16 and 32 data records and
that each internal node (except the root) branches in at least 114 ways. Since there are 10
million records, there are at most 625,000 leaves. Consequently, in the worst case, leaves
would be on level 4. In more concrete terms, the worst-case number of accesses is given
by approximately logM/2 N, give or take 1 (for example, the root and the next level could
be cached in main memory, so that, over the long run, disk accesses would be needed only
for level 3 and deeper).

The remaining issue is how to add and remove items from the B-tree; the ideas involved
are sketched next. Note that many of the themes seen before recur.

We begin by examining insertion. Suppose we want to insert 57 into the B-tree in
Figure 4.60. A search down the tree reveals that it is not already in the tree. We can then
add it to the leaf as a fifth item. Note that we may have to reorganize all the data in the leaf

41 66 87

72 78 83 92 9748 51 548 18 26 35

66
68
69
70

72
73
74
76

78
79
81

83
84
85

87
89
90

92
93
95

97
98
99

41
42
44
46

48
49
50

51
52
53

54
56
58
59

2
4
6

8
10
12
14
16

18
20
22
24

26
28
30
31
32

35
36
37
38
39

Figure 4.60 B-tree of order 5

150 Chapter 4 Trees

41 66 87

72 78 83 92 9748 51 548 18 26 35

66
68
69
70

72
73
74
76

78
79
81

83
84
85

87
89
90

92
93
95

97
98
99

41
42
44
46

48
49
50

51
52
53

54
56
57
58
59

2
4
6

8
10
12
14
16

18
20
22
24

26
28
30
31
32

35
36
37
38
39

Figure 4.61 B-tree after insertion of 57 into the tree in Figure 4.60

41 66 87

72 78 83 92 9748 51 54 578 18 26 35

66
68
69
70

72
73
74
76

78
79
81

83
84
85

87
89
90

92
93
95

97
98
99

41
42
44
46

48
49
50

51
52
53

54
55
56

57
58
59

2
4
6

8
10
12
14
16

18
20
22
24

26
28
30
31
32

35
36
37
38
39

Figure 4.62 Insertion of 55 into the B-tree in Figure 4.61 causes a split into two leaves

to do this. However, the cost of doing this is negligible when compared to that of the disk
access, which in this case also includes a disk write.

Of course, that was relatively painless because the leaf was not already full. Suppose
we now want to insert 55. Figure 4.61 shows a problem: The leaf where 55 wants to go is
already full. The solution is simple, however: Since we now have L+1 items, we split them
into two leaves, both guaranteed to have the minimum number of data records needed. We
form two leaves with three items each. Two disk accesses are required to write these leaves,
and a third disk access is required to update the parent. Note that in the parent, both
keys and branches change, but they do so in a controlled way that is easily calculated.
The resulting B-tree is shown in Figure 4.62. Although splitting nodes is time-consuming
because it requires at least two additional disk writes, it is a relatively rare occurrence. If L
is 32, for example, then when a node is split, two leaves with 16 and 17 items, respectively,
are created. For the leaf with 17 items, we can perform 15 more insertions without another
split. Put another way, for every split, there are roughly L/2 nonsplits.

The node splitting in the previous example worked because the parent did not have its
full complement of children. But what would happen if it did? Suppose, for example, that
we were to insert 40 into the B-tree in Figure 4.62. We would then have to split the leaf
containing the keys 35 through 39, and now 40, into two leaves. But doing this would give

4.7 B-Trees 151

26 41 66

48 51 54

87

57 72 78 83 92 9735 388 18

41
42
44
46

48
49
50

51
52
53

54
55
56

57
58
59

66
68
69
70

72
73
74
76

78
79
81

83
84
85

87
89
90

92
93
95

97
98
99

26
28
30
31
32

35
36
37

38
39
40

2
4
6

8
10
12
14
16

18
20
22
24

Figure 4.63 Insertion of 40 into the B-tree in Figure 4.62 causes a split into two leaves
and then a split of the parent node

the parent six children, and it is allowed only five. Hence, the solution is to split the parent.
The result of this is shown in Figure 4.63. When the parent is split, we must update the
values of the keys and also the parent’s parent, thus incurring an additional two disk writes
(so this insertion costs five disk writes). However, once again, the keys change in a very
controlled manner, although the code is certainly not simple because of a host of cases.

When a nonleaf node is split, as is the case here, its parent gains a child. What if the
parent already has reached its limit of children? In that case, we continue splitting nodes
up the tree until either we find a parent that does not need to be split or we reach the root.
If we split the root, then we have two roots. Obviously, this is unacceptable, but we can
create a new root that has the split roots as its two children. This is why the root is granted
the special two-child minimum exemption. It also is the only way that a B-tree gains height.
Needless to say, splitting all the way up to the root is an exceptionally rare event, because
a tree with four levels indicates that the root has been split three times throughout the
entire sequence of insertions (assuming no deletions have occurred). In fact, splitting of
any nonleaf node is also quite rare.

There are other ways to handle the overflowing of children. One technique is to put
a child up for adoption should a neighbor have room. To insert 29 into the B-tree in
Figure 4.63, for example, we could make room by moving 32 to the next leaf. This tech-
nique requires a modification of the parent because the keys are affected. However, it tends
to keep nodes fuller and thus saves space in the long run.

We can perform deletion by finding the item that needs to be removed and then remov-
ing it. The problem is that if the leaf it was in had the minimum number of data items,
then it is now below the minimum. We can rectify this situation by adopting a neighboring
item, if the neighbor is not itself at its minimum. If it is, then we can combine with the
neighbor to form a full leaf. Unfortunately, this means that the parent has lost a child. If
this loss causes the parent to fall below its minimum, then it follows the same strategy. This
process could percolate all the way up to the root. The root cannot have just one child (and
even if this were allowed, it would be silly). If a root is left with one child as a result of
the adoption process, then we remove the root and make its child the new root of the tree.
This is the only way for a B-tree to lose height. For example, suppose we want to remove
99 from the B-tree in Figure 4.63. Since the leaf has only two items, and its neighbor is
already at its minimum of three, we combine the items into a new leaf of five items. As a

152 Chapter 4 Trees

26 41 66

48 51 54

83

57 72 78 87 9235 388 18

41
42
44
46

48
49
50

51
52
53

54
55
56

57
58
59

66
68
69
70

72
73
74
76

78
79
81

83
84
85

87
89
90

92
93
95
97
98

26
28
30
31
32

35
36
37

38
39
40

2
4
6

8
10
12
14
16

18
20
22
24

Figure 4.64 B-tree after the deletion of 99 from the B-tree in Figure 4.63

result, the parent has only two children. However, it can adopt from a neighbor because
the neighbor has four children. As a result, both have three children. The result is shown
in Figure 4.64.

4.8 Sets and Maps in the Standard Library
The List containers discussed in Chapter 3, namely ArrayList and LinkedList, are ineffi-
cient for searching. Consequently, the Collections API provides two additional containers,
Set and Map, that provide efficient implementations for basic operations such as insertion,
deletion, and searching.

4.8.1 Sets
The Set interface represents a Collection that does not allow duplicates. A special kind of
Set, given by the SortedSet interface, guarantees that the items are maintained in sorted
order. Because a Set IS-A Collection, the idioms used to access items in a List, which are
inherited from Collection, also work for a Set. The print method described in Figure 3.6
will work if passed a Set.

The unique operations required by the Set are the abilities to insert, remove, and per-
form a basic search (efficiently). For a Set, the add method returns true if the add succeeds
and false if it fails because the item being added is already present. The implementation
of Set that maintains items in sorted order is a TreeSet. Basic operations in a TreeSet take
logarithmic worst-case time.

By default, ordering assumes that the items in the TreeSet implement the Comparable
interface. An alternative ordering can be specified by instantiating the TreeSet with a
Comparator. For instance, we can create a TreeSet that stores String objects, ignoring case
distinctions by using the CaseInsensitiveCompare function object coded in Figure 1.18. In
the following code, the Set s has size 1.

Set s = new TreeSet<>( new CaseInsensitiveCompare( ) );
s.add( “Hello” ); s.add( “HeLLo” );
System.out.println( “The size is: ” + s.size( ) );

4.8 Sets and Maps in the Standard Library 153

4.8.2 Maps
A Map is an interface that represents a collection of entries that consists of keys and their
values. Keys must be unique, but several keys can map to the same values. Thus values
need not be unique. In a SortedMap, the keys in the map are maintained in logically sorted
order. An implementation of SortedMap is the TreeMap. The basic operations for a Map include
methods such as isEmpty, clear, size, and most importantly, the following:

boolean containsKey( KeyType key )
ValueType get( KeyType key )
ValueType put( KeyType key, ValueType value )

get returns the value associated with key in the Map, or null if key is not present. If there are
no null values in the Map, the value returned by get can be used to determine if key is in
the Map. However, if there are null values, you have to use containsKey. Method put places
a key/value pair into the Map, returning either null or the old value associated with key.

Iterating through a Map is trickier than a Collection because the Map does not provide an
iterator. Instead, three methods are provided that return the view of a Map as a Collection.
Since the views are themselves Collections, the views can be iterated. The three methods
are:

Set keySet( )
Collection values( )
Set> entrySet( )

Methods keySet and values return simple collections (the keys contain no duplicates, thus
the keys are returned in a Set). The entrySet is returned as a Set of entries (there are no
duplicate entries, since the keys are unique). Each entry is represented by the nested inter-
face Map.Entry. For an object of type Map.Entry, the available methods include accessing
the key, the value, and changing the value:

KeyType getKey( )
ValueType getValue( )
ValueType setValue( ValueType newValue )

4.8.3 Implementation of TreeSet and TreeMap
Java requires that TreeSet and TreeMap support the basic add, remove, and contains oper-
ations in logarithmic worst-case time. Consequently, the underlying implementation is a
balanced binary search tree. Typically, an AVL tree is not used; instead, top-down red-black
trees, which are discussed in Section 12.2, are often used.

An important issue in implementing TreeSet and TreeMap is providing support for the
iterator classes. Of course, internally, the iterator maintains a link to the “current” node

154 Chapter 4 Trees

in the iteration. The hard part is efficiently advancing to the next node. There are several
possible solutions, some of which are listed here:

1. When the iterator is constructed, have each iterator store as its data an array containing
the TreeSet items. This is lame, because we might as well use toArray and have no need
for an iterator.

2. Have the iterator maintain a stack storing nodes on the path to the current node. With
this information, one can deduce the next node in the iteration, which is either the
node in the current node’s right subtree that contains the minimum item, or the nearest
ancestor that contains the current node in its left subtree. This makes the iterator
somewhat large, and makes the iterator code clumsy.

3. Have each node in the search tree store its parent in addition to the children. The
iterator is not as large, but there is now extra memory required in each node, and the
code to iterate is still clumsy.

4. Have each node maintain extra links: one to the next smaller, and one to the next larger
node. This takes space, but the iteration is very simple to do, and it is easy to maintain
these links.

5. Maintain the extra links only for nodes that have null left or right links, by using extra
Boolean variables to allow the routines to tell if a left link is being used as a standard
binary search tree left link or a link to the next smaller node, and similarly for the right
link (Exercise 4.50). This idea is called a threaded tree, and is used in many balanced
binary search tree implementations.

4.8.4 An Example That Uses Several Maps
Many words are similar to other words. For instance, by changing the first letter, the word
wine can become dine, fine, line, mine, nine, pine, or vine. By changing the third letter, wine
can become wide, wife, wipe, or wire, among others. By changing the fourth letter, wine can
become wind, wing, wink, or wins, among others. This gives 15 different words that can
be obtained by changing only one letter in wine. In fact, there are over 20 different words,
some more obscure. We would like to write a program to find all words that can be changed
into at least 15 other words by a single one-character substitution. We assume that we have
a dictionary consisting of approximately 89,000 different words of varying lengths. Most
words are between 6 and 11 characters. The distribution includes 8,205 six-letter words,
11,989 seven-letter words, 13,672 eight-letter words, 13,014 nine-letter words, 11,297
ten-letter words, and 8,617 eleven-letter words. (In reality, the most changeable words are
three-, four- and five-letter words, but the longer words are the time-consuming ones to
check.)

The most straightforward strategy is to use a Map in which the keys are words and the
values are lists containing the words that can be changed from the key with a one-character
substitution. The routine in Figure 4.65 shows how the Map that is eventually produced (we
have yet to write code for that part) can be used to print the required answers. The code
obtains the entry set and uses the enhanced for loop to step through the entry set and view
entries that are pairs consisting of a word and a list of words.

4.8 Sets and Maps in the Standard Library 155

1 public static void printHighChangeables( Map> adjWords,
2 int minWords )
3 {
4 for( Map.Entry> entry : adjWords.entrySet( ) )
5 {
6 List words = entry.getValue( );
7
8 if( words.size( ) >= minWords )
9 {

10 System.out.print( entry.getKey( ) + ” (” );
11 System.out.print( words.size( ) + “):” );
12 for( String w : words )
13 System.out.print( ” ” + w );
14 System.out.println( );
15 }
16 }
17 }

Figure 4.65 Given a map containing words as keys and a list of words that differ in only
one character as values, output words that have minWords or more words obtainable by a
one-character substitution

1 // Returns true if word1 and word2 are the same length
2 // and differ in only one character.
3 private static boolean oneCharOff( String word1, String word2 )
4 {
5 if( word1.length( ) != word2.length( ) )
6 return false;
7
8 int diffs = 0;
9

10 for( int i = 0; i < word1.length( ); i++ ) 11 if( word1.charAt( i ) != word2.charAt( i ) ) 12 if( ++diffs > 1 )
13 return false;
14
15 return diffs == 1;
16 }

Figure 4.66 Routine to check if two words differ in only one character

The main issue is how to construct the Map from an array that contains the 89,000
words. The routine in Figure 4.66 is a straightforward function to test if two words are
identical except for a one-character substitution. We can use the routine to provide the
simplest algorithm for the Map construction, which is a brute-force test of all pairs of words.
This algorithm is shown in Figure 4.67.

156 Chapter 4 Trees

To step through the collection of words, we could use an iterator, but because we are
stepping through it with a nested loop (i.e., several times), we dump the collection into an
array using toArray (lines 9 and 11). Among other things, this avoids repeated calls to cast
from Object to String, which occur behind the scenes if generics are used. Instead, we are
simply indexing a String[].

1 // Computes a map in which the keys are words and values are Lists of words
2 // that differ in only one character from the corresponding key.
3 // Uses a quadratic algorithm (with appropriate Map).
4 public static Map>
5 computeAdjacentWords( List theWords )
6 {
7 Map> adjWords = new TreeMap<>( );
8
9 String [ ] words = new String[ theWords.size( ) ];

10
11 theWords.toArray( words );
12 for( int i = 0; i < words.length; i++ ) 13 for( int j = i + 1; j < words.length; j++ ) 14 if( oneCharOff( words[ i ], words[ j ] ) ) 15 { 16 update( adjWords, words[ i ], words[ j ] ); 17 update( adjWords, words[ j ], words[ i ] ); 18 } 19 20 return adjWords; 21 } 22 23 private static void update( Map> m,
24 KeyType key, String value )
25 {
26 List lst = m.get( key );
27 if( lst == null )
28 {
29 lst = new ArrayList<>( );
30 m.put( key, lst );
31 }
32
33 lst.add( value );
34 }

Figure 4.67 Function to compute a map containing words as keys and a list of words that
differ in only one character as values. This version runs in 75 seconds on an 89,000-word
dictionary

4.8 Sets and Maps in the Standard Library 157

If we find a pair of words that differ in only one character, we can update the Map at
lines 16 and 17. In the private update method, at line 26 we see if there is already a list of
words associated with the key. If we have previously seen key, because lst is not null, then
it is in the Map, and we need only add the new word to the List in the Map, and we do this
by calling add at line 33. If we have never seen key before, then lines 29 and 30 place it in
the Map, with a List of size 0, so the add updates the List to be size 1. All in all, this is a
standard idiom for maintaining a Map, in which the value is a collection.

The problem with this algorithm is that it is slow, and takes 75 seconds on our com-
puter. An obvious improvement is to avoid comparing words of different lengths. We can
do this by grouping words by their length, and then running the previous algorithm on
each of the separate groups.

To do this, we can use a second map! Here the key is an integer representing a word
length, and the value is a collection of all the words of that length. We can use a List to
store each collection, and the same idiom applies. The code is shown in Figure 4.68. Line
9 shows the declaration for the second Map, lines 12 and 13 populate the Map, and then an
extra loop is used to iterate over each group of words. Compared to the first algorithm,
the second algorithm is only marginally more difficult to code and runs in 16 seconds, or
about five times as fast.

Our third algorithm is more complex, and uses additional maps! As before, we group
the words by word length, and then work on each group separately. To see how this algo-
rithm works, suppose we are working on words of length 4. Then first we want to find
word pairs such as wine and nine that are identical except for the first letter. One way to
do this, for each word of length 4, is to remove the first character, leaving a three-character
word representative. Form a Map in which the key is the representative, and the value is a
List of all words that have that representative. For instance, in considering the first char-
acter of the four-letter word group, representative “ine” corresponds to “dine”, “fine”,
“wine”, “nine”, “mine”, “vine”, “pine”, “line”. Representative “oot” corresponds to “boot”,
“foot”, “hoot”, “loot”, “soot”, “zoot”. Each individual List that is a value in this latest Map
forms a clique of words in which any word can be changed to any other word by a one-
character substitution, so after this latest Map is constructed, it is easy to traverse it and add
entries to the original Map that is being computed. We would then proceed to the second
character of the four-letter word group, with a new Map. And then the third character, and
finally the fourth character.

The general outline is:

for each group g, containing words of length len
for each position p (ranging from 0 to len-1)
{

Make an empty Map > repsToWords
for each word w
{

Obtain w’s representative by removing position p
Update repsToWords

}
Use cliques in repsToWords to update adjWords map

}

158 Chapter 4 Trees

Figure 4.69 contains an implementation of this algorithm. The running time improves
to one second. It is interesting to note that although the use of the additional Maps makes
the algorithm faster, and the syntax is relatively clean, the code makes no use of the fact
that the keys of the Map are maintained in sorted order.

As such, it is possible that a data structure that supports the Map operations but does
not guarantee sorted order can perform better, since it is being asked to do less. Chapter 5
explores this possibility and discusses the ideas behind the alternative Map implementation,
known as a HashMap. A HashMap reduces the running time of the implementation from one
second to roughly 0.8 seconds.

1 // Computes a map in which the keys are words and values are Lists of words
2 // that differ in only one character from the corresponding key.
3 // Uses a quadratic algorithm (with appropriate Map), but speeds things by
4 // maintaining an additional map that groups words by their length.
5 public static Map>
6 computeAdjacentWords( List theWords )
7 {
8 Map> adjWords = new TreeMap<>( );
9 Map> wordsByLength = new TreeMap<>( );

10
11 // Group the words by their length
12 for( String w : theWords )
13 update( wordsByLength, w.length( ), w );
14
15 // Work on each group separately
16 for( List groupsWords : wordsByLength.values( ) )
17 {
18 String [ ] words = new String[ groupsWords.size( ) ];
19
20 groupsWords.toArray( words );
21 for( int i = 0; i < words.length; i++ ) 22 for( int j = i + 1; j < words.length; j++ ) 23 if( oneCharOff( words[ i ], words[ j ] ) ) 24 { 25 update( adjWords, words[ i ], words[ j ] ); 26 update( adjWords, words[ j ], words[ i ] ); 27 } 28 } 29 30 return adjWords; 31 } Figure 4.68 Function to compute a map containing words as keys and a list of words that differ in only one character as values. Splits words into groups by word length. This version runs in 16 seconds on an 89,000-word dictionary 1 // Computes a map in which the keys are words and values are Lists of words 2 // that differ in only one character from the corresponding key. 3 // Uses an efficient algorithm that is O(N log N) with a TreeMap. 4 public static Map>
5 computeAdjacentWords( List words )
6 {
7 Map> adjWords = new TreeMap<>( );
8 Map> wordsByLength = new TreeMap<>( );
9

10 // Group the words by their length
11 for( String w : words )
12 update( wordsByLength, w.length( ), w );
13
14 // Work on each group separately
15 for( Map.Entry> entry : wordsByLength.entrySet( ) )
16 {
17 List groupsWords = entry.getValue( );
18 int groupNum = entry.getKey( );
19
20 // Work on each position in each group
21 for( int i = 0; i < groupNum; i++ ) 22 { 23 // Remove one character in specified position, computing 24 // representative. Words with same representative are 25 // adjacent, so first populate a map ... 26 Map> repToWord = new TreeMap<>( );
27
28 for( String str : groupsWords )
29 {
30 String rep = str.substring( 0, i ) + str.substring( i + 1 );
31 update( repToWord, rep, str );
32 }
33
34 // and then look for map values with more than one string
35 for( List wordClique : repToWord.values( ) )
36 if( wordClique.size( ) >= 2 )
37 for( String s1 : wordClique )
38 for( String s2 : wordClique )
39 if( s1 != s2 )
40 update( adjWords, s1, s2 );
41 }
42 }
43
44 return adjWords;
45 }

Figure 4.69 Function to compute a map containing words as keys and a list of words
that differ in only one character as values. Runs in 1 second on an 89,000-word dictionary

160 Chapter 4 Trees

Summary

We have seen uses of trees in operating systems, compiler design, and searching.
Expression trees are a small example of a more general structure known as a parse tree,
which is a central data structure in compiler design. Parse trees are not binary but are rela-
tively simple extensions of expression trees (although the algorithms to build them are not
quite so simple).

Search trees are of great importance in algorithm design. They support almost all the
useful operations, and the logarithmic average cost is very small. Nonrecursive implemen-
tations of search trees are somewhat faster, but the recursive versions are sleeker, more
elegant, and easier to understand and debug. The problem with search trees is that their
performance depends heavily on the input being random. If this is not the case, the run-
ning time increases significantly, to the point where search trees become expensive linked
lists.

We saw several ways to deal with this problem. AVL trees work by insisting that all
nodes’ left and right subtrees differ in heights by at most one. This ensures that the tree
cannot get too deep. The operations that do not change the tree, as insertion does, can
all use the standard binary search tree code. Operations that change the tree must restore
the tree. This can be somewhat complicated, especially in the case of deletion. We showed
how to restore the tree after insertions in O(log N) time.

We also examined the splay tree. Nodes in splay trees can get arbitrarily deep, but after
every access the tree is adjusted in a somewhat mysterious manner. The net effect is that
any sequence of M operations takes O(M log N) time, which is the same as a balanced tree
would take.

B-trees are balanced M-way (as opposed to 2-way or binary) trees, which are well
suited for disks; a special case is the 2–3 tree (M = 3), which is another way to implement
balanced search trees.

In practice, the running time of all the balanced tree schemes, while slightly faster
for searching, is worse (by a constant factor) for insertions and deletions than the simple
binary search tree, but this is generally acceptable in view of the protection being given
against easily obtained worst-case input. Chapter 12 discusses some additional search tree
data structures and provides detailed implementations.

A final note: By inserting elements into a search tree and then performing an inorder
traversal, we obtain the elements in sorted order. This gives an O(N log N) algorithm to
sort, which is a worst-case bound if any sophisticated search tree is used. We shall see
better ways in Chapter 7, but none that have a lower time bound.

Exercises

Questions 4.1 to 4.3 refer to the tree in Figure 4.70.

4.1 For the tree in Figure 4.70:
a. Which node is the root?
b. Which nodes are leaves?

Exercises 161

4.2 For each node in the tree of Figure 4.70:
a. Name the parent node.
b. List the children.
c. List the siblings.
d. Compute the depth.
e. Compute the height.

4.3 What is the depth of the tree in Figure 4.70?

4.4 Show that in a binary tree of N nodes, there are N + 1 null links representing
children.

4.5 Show that the maximum number of nodes in a binary tree of height h is 2h+1 − 1.
4.6 A full node is a node with two children. Prove that the number of full nodes plus

one is equal to the number of leaves in a nonempty binary tree.

4.7 Suppose a binary tree has leaves l1, l2, . . . , lM at depths d1, d2, . . . , dM, respectively.
Prove that

∑M
i=1 2

−di ≤ 1 and determine when the equality is true.
4.8 Give the prefix, infix, and postfix expressions corresponding to the tree in

Figure 4.71.

4.9 a. Show the result of inserting 3, 1, 4, 6, 9, 2, 5, 7 into an initially empty binary
search tree.

b. Show the result of deleting the root.

4.10 Write a program that lists all files in a directory and their sizes. Mimic the routine
in the online code.

4.11 Write an implementation of the TreeSet class, with associated iterators using a
binary search tree. Add to each node a link to the parent node.

4.12 Write an implementation of the TreeMap class by storing a data member of type
TreeSet>.

A

B

D

G H

E

I J

L M

C

F

K

Figure 4.70 Tree for Exercises 4.1 to 4.3

162 Chapter 4 Trees

a

*

b

*

+

c d

–

e

Figure 4.71 Tree for Exercise 4.8

4.13 Write an implementation of the TreeSet class, with associated iterators, using a
binary search tree. Add to each node a link to the next smallest and next largest
node. To make your code simpler, add a header and tail node which are not part of
the binary search tree, but help make the linked list part of the code simpler.

4.14 Suppose you want to perform an experiment to verify the problems that can be
caused by random insert/remove pairs. Here is a strategy that is not perfectly ran-
dom, but close enough. You build a tree with N elements by inserting N elements
chosen at random from the range 1 to M = αN. You then perform N2 pairs of inser-
tions followed by deletions. Assume the existence of a routine, randomInteger(a, b),
which returns a uniform random integer between a and b inclusive.
a. Explain how to generate a random integer between 1 and M that is not already

in the tree (so a random insertion can be performed). In terms of N and α, what
is the running time of this operation?

b. Explain how to generate a random integer between 1 and M that is already in
the tree (so a random deletion can be performed). What is the running time of
this operation?

c. What is a good choice of α? Why?

4.15 Write a program to evaluate empirically the following strategies for removing nodes
with two children:
a. Replace with the largest node, X, in TL and recursively remove X.
b. Alternately replace with the largest node in TL and the smallest node in TR, and

recursively remove the appropriate node.
c. Replace with either the largest node in TL or the smallest node in TR (recursively

removing the appropriate node), making the choice randomly.

Which strategy seems to give the most balance? Which takes the least CPU time to
process the entire sequence?

4.16 Redo the binary search tree class to implement lazy deletion. Note carefully that
this affects all of the routines. Especially challenging are findMin and findMax, which
must now be done recursively.

Exercises 163

��4.17 Prove that the depth of a random binary search tree (depth of the deepest node) is
O(log N), on average.

4.18 �a. Give a precise expression for the minimum number of nodes in an AVL tree of
height h.

b. What is the minimum number of nodes in an AVL tree of height 15?

4.19 Show the result of inserting 2, 1, 4, 5, 9, 3, 6, 7 into an initially empty AVL tree.
�4.20 Keys 1, 2, . . . , 2k − 1 are inserted in order into an initially empty AVL tree. Prove

that the resulting tree is perfectly balanced.

4.21 Write the remaining procedures to implement AVL single and double rotations.

4.22 Design a linear-time algorithm that verifies that the height information in an AVL
tree is correctly maintained and that the balance property is in order.

4.23 Write a nonrecursive method to insert into an AVL tree.

4.24 Show that the deletion algorithm in Figure 4.44 is correct, and explain what
happens if > is used instead of >= at lines 32 and 38 in Figure 4.39.

4.25 a. How many bits are required per node to store the height of a node in an N-node
AVL tree?

b. What is the smallest AVL tree that overflows an 8-bit height counter?

4.26 Write the methods to perform the double rotation without the inefficiency of doing
two single rotations.

4.27 Show the result of accessing the keys 3, 9, 1, 5 in order in the splay tree in
Figure 4.72.

4.28 Show the result of deleting the element with key 6 in the resulting splay tree for the
previous exercise.

4.29 a. Show that if all nodes in a splay tree are accessed in sequential order, the
resulting tree consists of a chain of left children.

4

2 6

1 3 5 8

10

11

12

13

7 9

Figure 4.72 Tree for Exercise 4.27

164 Chapter 4 Trees

��b. Show that if all nodes in a splay tree are accessed in sequential order, then the
total access time is O(N), regardless of the initial tree.

4.30 Write a program to perform random operations on splay trees. Count the total
number of rotations performed over the sequence. How does the running time
compare to AVL trees and unbalanced binary search trees?

4.31 Write efficient methods that take only a reference to the root of a binary tree, T, and
compute:
a. The number of nodes in T.
b. The number of leaves in T.
c. The number of full nodes in T.
What is the running time of your routines?

4.32 Design a recursive linear-time algorithm that tests whether a binary tree satisfies the
search tree order property at every node.

4.33 Write a recursive method that takes a reference to the root node of a tree T and
returns a reference to the root node of the tree that results from removing all leaves
from T.

4.34 Write a method to generate an N-node random binary search tree with distinct keys
1 through N. What is the running time of your routine?

4.35 Write a method to generate the AVL tree of height h with fewest nodes. What is the
running time of your method?

4.36 Write a method to generate a perfectly balanced binary search tree of height h with
keys 1 through 2h+1 − 1. What is the running time of your method?

4.37 Write a method that takes as input a binary search tree, T, and two keys k1 and k2,
which are ordered so that k1 ≤ k2, and prints all elements X in the tree such that
k1 ≤ Key(X) ≤ k2. Do not assume any information about the type of keys except
that they can be ordered (consistently). Your program should run in O(K + log N)
average time, where K is the number of keys printed. Bound the running time of
your algorithm.

4.38 The larger binary trees in this chapter were generated automatically by a program.
This was done by assigning an (x, y) coordinate to each tree node, drawing a circle
around each coordinate (this is hard to see in some pictures), and connecting each
node to its parent. Assume you have a binary search tree stored in memory (perhaps
generated by one of the routines above) and that each node has two extra fields to
store the coordinates.
a. The x coordinate can be computed by assigning the inorder traversal number.

Write a routine to do this for each node in the tree.
b. The y coordinate can be computed by using the negative of the depth of the

node. Write a routine to do this for each node in the tree.
c. In terms of some imaginary unit, what will the dimensions of the picture be?

How can you adjust the units so that the tree is always roughly two-thirds as
high as it is wide?

Exercises 165

d. Prove that using this system no lines cross, and that for any node, X, all elements
in X’s left subtree appear to the left of X and all elements in X’s right subtree
appear to the right of X.

4.39 Write a general-purpose tree-drawing program that will convert a tree into the
following graph-assembler instructions:
a. Circle(X, Y)
b. DrawLine(i, j)
The first instruction draws a circle at (X, Y), and the second instruction connects
the ith circle to the jth circle (circles are numbered in the order drawn). You should
either make this a program and define some sort of input language or make this
a method that can be called from any program. What is the running time of your
routine?

4.40 (This exercise assumes familiarity with the Java Swing Library.) Write a program
that reads graph-assembler instructions and generates Java code that draws into a
canvas. (Note that you have to scale the stored coordinates into pixels.)

4.41 Write a routine to list out the nodes of a binary tree in level-order. List the root, then
nodes at depth 1, followed by nodes at depth 2, and so on. You must do this in
linear time. Prove your time bound.

4.42 �a. Write a routine to perform insertion into a B-tree.
�b. Write a routine to perform deletion from a B-tree. When an item is deleted, is it

necessary to update information in the internal nodes?
�c. Modify your insertion routine so that if an attempt is made to add into a node

that already has M entries, a search is performed for a sibling with less than M
children before the node is split.

4.43 A B∗-tree of order M is a B-tree in which each interior node has between 2M/3 and
M children. Describe a method to perform insertion into a B∗-tree.

4.44 Show how the tree in Figure 4.73 is represented using a child/sibling link
implementation.

4.45 Write a procedure to traverse a tree stored with child/sibling links.

A

B C

O P Q R

G

D E F N

H I J K L M

Figure 4.73 Tree for Exercise 4.44

166 Chapter 4 Trees

A A

B BC C

G G DD E E

F H FH

Figure 4.74 Two isomorphic trees

4.46 Two binary trees are similar if they are both empty or both nonempty and have
similar left and right subtrees. Write a method to decide whether two binary trees
are similar. What is the running time of your method?

4.47 Two trees, T1 and T2, are isomorphic if T1 can be transformed into T2 by swapping
left and right children of (some of the) nodes in T1. For instance, the two trees in
Figure 4.74 are isomorphic because they are the same if the children of A, B, and
G, but not the other nodes, are swapped.
a. Give a polynomial time algorithm to decide if two trees are isomorphic.

�b. What is the running time of your program (there is a linear solution)?

4.48 �a. Show that via AVL single rotations, any binary search tree T1 can be transformed
into another search tree T2 (with the same items).

�b. Give an algorithm to perform this transformation using O(N log N) rotations on
average.

��c. Show that this transformation can be done with O(N) rotations, worst case.

4.49 Suppose we want to add the operation findKth to our repertoire. The operation
findKth(k) returns the kth smallest item in the tree. Assume all items are distinct.
Explain how to modify the binary search tree to support this operation in O(log N)
average time, without sacrificing the time bounds of any other operation.

4.50 Since a binary search tree with N nodes has N + 1 null references, half the space
allocated in a binary search tree for link information is wasted. Suppose that if a
node has a null left child, we make its left child link to its inorder predecessor, and
if a node has a null right child, we make its right child link to its inorder successor.
This is known as a threaded tree, and the extra links are called threads.
a. How can we distinguish threads from real children links?
b. Write routines to perform insertion and deletion into a tree threaded in the

manner described above.
c. What is the advantage of using threaded trees?

4.51 Let f(N) be the average number of full nodes in a binary search tree.
a. Determine the values of f(0) and f(1).
b. Show that for N > 1

f(N) = N − 2
N

+ 1
N

N−1∑
i=0

(f(i) + f(N − i − 1))

References 167

IX: {Series |(} {2}
IX: {Series!geometric|(} {4}
IX: {Euler’s constant} {4}
IX: {Series!geometric|)} {4}
IX: {Series!arithmetic|(} {4}
IX: {Series!arithmetic|)} {5}
IX: {Series!harmonic|(} {5}
IX: {Euler’s constant} {5}
IX: {Series!harmonic|)} {5}
IX: {Series|)} {5}

Figure 4.75 Sample input for Exercise 4.53

Euler’s constant: 4, 5
Series: 2-5

arithmetic: 4-5
geometric: 4
harmonic: 5

Figure 4.76 Sample output for Exercise 4.53

c. Show (by induction) that f(N) = (N − 2)/3 is a solution to the equation in part
(b), with the initial conditions in part (a).

d. Use the results of Exercise 4.6 to determine the average number of leaves in an
N node binary search tree.

4.52 Write a program that reads a Java source code file and outputs a list of all identi-
fiers (that is, variable names but not keywords, not found in comments or string
constants) in alphabetical order. Each identifier should be output with a list of line
numbers on which it occurs.

4.53 Generate an index for a book. The input file consists of a set of index entries. Each
line consists of the string IX:, followed by an index entry name enclosed in braces,
followed by a page number that is enclosed in braces. Each ! in an index entry
name represents a sub-level. A (|represents the start of a range, and a |) represents
the end of the range. Occasionally, this range will be the same page. In that case,
output only a single page number. Otherwise, do not collapse or expand ranges on
your own. As an example, Figure 4.75 shows sample input, and Figure 4.76 shows
the corresponding output.

References

More information on binary search trees, and in particular the mathematical properties of
trees, can be found in the two books by Knuth, [22] and [23].

Several papers deal with the lack of balance caused by biased deletion algorithms in
binary search trees. Hibbard’s paper [19] proposed the original deletion algorithm and

168 Chapter 4 Trees

established that one deletion preserves the randomness of the trees. A complete analysis has
been performed only for trees with three nodes [20] and four nodes [5]. Eppinger’s paper
[14] provided early empirical evidence of nonrandomness, and the papers by Culberson
and Munro [10], [11] provided some analytical evidence (but not a complete proof for the
general case of intermixed insertions and deletions).

AVL trees were proposed by Adelson-Velskii and Landis [1]. Simulation results for AVL
trees, and variants in which the height imbalance is allowed to be at most k for various val-
ues of k, are presented in [21]. Analysis of the average search cost in AVL trees is incomplete,
but some results are contained in [24].

[3] and [8] considered self-adjusting trees like the type in Section 4.5.1. Splay trees are
described in [28].

B-trees first appeared in [6]. The implementation described in the original paper allows
data to be stored in internal nodes as well as leaves. The data structure we have described
is sometimes known as a B+-tree. A survey of the different types of B-trees is presented in
[9]. Empirical results of the various schemes are reported in [17]. Analysis of 2–3 trees and
B-trees can be found in [4], [13], and [32].

Exercise 4.17 is deceptively difficult. A solution can be found in [15]. Exercise 4.29
is from [31]. Information on B*-trees, described in Exercise 4.47, can be found in [12].
Exercise 4.47 is from [2]. A solution to Exercise 4.48 using 2N − 6 rotations is given in
[29]. Using threads, à la Exercise 4.50, was first proposed in [27]. k-d trees, which handle
multidimensional data, were first proposed in [7] and are discussed in Chapter 12.

Other popular balanced search trees are red-black trees [18] and weight-balanced trees
[26]. More balanced-tree schemes can be found in the books [16], [25], and [30].

1. G. M. Adelson-Velskii and E. M. Landis, “An Algorithm for the Organization of
Information,” Soviet. Mat. Doklady, 3 (1962), 1259–1263.

2. A. V. Aho, J. E. Hopcroft, and J. D. Ullman, The Design and Analysis of Computer Algorithms,
Addison-Wesley, Reading, Mass., 1974.

3. B. Allen and J. I. Munro, “Self Organizing Search Trees,” Journal of the ACM, 25 (1978),
526–535.

4. R. A. Baeza-Yates, “Expected Behaviour of B+-trees under Random Insertions,” Acta
Informatica, 26 (1989), 439–471.

5. R. A. Baeza-Yates, “A Trivial Algorithm Whose Analysis Isn’t: A Continuation,” BIT, 29
(1989), 88–113.

6. R. Bayer and E. M. McCreight, “Organization and Maintenance of Large Ordered Indices,”
Acta Informatica, 1 (1972), 173–189.

7. J. L. Bentley, “Multidimensional Binary Search Trees Used for Associative Searching,”
Communications of the ACM, 18 (1975), 509–517.

8. J. R. Bitner, “Heuristics that Dynamically Organize Data Structures,” SIAM Journal on
Computing, 8 (1979), 82–110.

9. D. Comer, “The Ubiquitous B-tree,” Computing Surveys, 11 (1979), 121–137.
10. J. Culberson and J. I. Munro, “Explaining the Behavior of Binary Search Trees under

Prolonged Updates: A Model and Simulations,” Computer Journal, 32 (1989), 68–75.
11. J. Culberson and J. I. Munro, “Analysis of the Standard Deletion Algorithms in Exact Fit

Domain Binary Search Trees,” Algorithmica, 5 (1990), 295–311.

References 169

12. K. Culik, T. Ottman, and D. Wood, “Dense Multiway Trees,” ACM Transactions on Database
Systems, 6 (1981), 486–512.

13. B. Eisenbath, N. Ziviana, G. H. Gonnet, K. Melhorn, and D. Wood, “The Theory of Fringe
Analysis and Its Application to 2–3 Trees and B-trees,” Information and Control, 55 (1982),
125–174.

14. J. L. Eppinger, “An Empirical Study of Insertion and Deletion in Binary Search Trees,”
Communications of the ACM, 26 (1983), 663–669.

15. P. Flajolet and A. Odlyzko, “The Average Height of Binary Trees and Other Simple Trees,”
Journal of Computer and System Sciences, 25 (1982), 171–213.

16. G. H. Gonnet and R. Baeza-Yates, Handbook of Algorithms and Data Structures, 2d ed.,
Addison-Wesley, Reading, Mass., 1991.

17. E. Gudes and S. Tsur, “Experiments with B-tree Reorganization,” Proceedings of ACM
SIGMOD Symposium on Management of Data (1980), 200–206.

18. L. J. Guibas and R. Sedgewick, “A Dichromatic Framework for Balanced Trees,” Proceedings
of the Nineteenth Annual IEEE Symposium on Foundations of Computer Science (1978), 8–21.

19. T. H. Hibbard, “Some Combinatorial Properties of Certain Trees with Applications to
Searching and Sorting,” Journal of the ACM, 9 (1962), 13–28.

20. A. T. Jonassen and D. E. Knuth, “A Trivial Algorithm Whose Analysis Isn’t,” Journal of
Computer and System Sciences, 16 (1978), 301–322.

21. P. L. Karlton, S. H. Fuller, R. E. Scroggs, and E. B. Kaehler, “Performance of Height Balanced
Trees,” Communications of the ACM, 19 (1976), 23–28.

22. D. E. Knuth, The Art of Computer Programming: Vol. 1: Fundamental Algorithms, 3d ed.,
Addison-Wesley, Reading, Mass., 1997.

23. D. E. Knuth, The Art of Computer Programming: Vol. 3: Sorting and Searching, 2d ed.,
Addison-Wesley, Reading, Mass., 1998.

24. K. Melhorn, “A Partial Analysis of Height-Balanced Trees under Random Insertions and
Deletions,” SIAM Journal of Computing, 11 (1982), 748–760.

25. K. Melhorn, Data Structures and Algorithms 1: Sorting and Searching, Springer-Verlag, Berlin,
1984.

26. J. Nievergelt and E. M. Reingold, “Binary Search Trees of Bounded Balance,” SIAM Journal
on Computing, 2 (1973), 33–43.

27. A. J. Perlis and C. Thornton, “Symbol Manipulation in Threaded Lists,” Communications of
the ACM, 3 (1960), 195–204.

28. D. D. Sleator and R. E. Tarjan, “Self-adjusting Binary Search Trees,” Journal of ACM, 32
(1985), 652–686.

29. D. D. Sleator, R. E. Tarjan, and W. P. Thurston, “Rotation Distance, Triangulations, and
Hyperbolic Geometry,” Journal of AMS (1988), 647–682.

30. H. F. Smith, Data Structures—Form and Function, Harcourt Brace Jovanovich, Orlando, Fla.,
1987.

31. R. E. Tarjan, “Sequential Access in Splay Trees Takes Linear Time,” Combinatorica, 5 (1985),
367–378.

32. A. C. Yao, “On Random 2–3 Trees,” Acta Informatica, 9 (1978), 159–170.

This page intentionally left blank

C H A P T E R 5

Hashing

In Chapter 4, we discussed the search tree ADT, which allowed various operations on a set
of elements. In this chapter, we discuss the hash table ADT, which supports only a subset of
the operations allowed by binary search trees.

The implementation of hash tables is frequently called hashing. Hashing is a tech-
nique used for performing insertions, deletions, and searches in constant average time.
Tree operations that require any ordering information among the elements are not sup-
ported efficiently. Thus, operations such as findMin, findMax, and the printing of the entire
table in sorted order in linear time are not supported.

The central data structure in this chapter is the hash table. We will

� See several methods of implementing the hash table.
� Compare these methods analytically.
� Show numerous applications of hashing.
� Compare hash tables with binary search trees.

5.1 General Idea
The ideal hash table data structure is merely an array of some fixed size, containing the
items. As discussed in Chapter 4, generally a search is performed on some part (that is,
data field) of the item. This is called the key. For instance, an item could consist of a string
(that serves as the key) and additional data fields (for instance, a name that is part of a large
employee structure). We will refer to the table size as TableSize, with the understanding that
this is part of a hash data structure and not merely some variable floating around globally.
The common convention is to have the table run from 0 to TableSize − 1; we will see why
shortly.

Each key is mapped into some number in the range 0 to TableSize − 1 and placed
in the appropriate cell. The mapping is called a hash function, which ideally should be
simple to compute and should ensure that any two distinct keys get different cells. Since
there are a finite number of cells and a virtually inexhaustible supply of keys, this is clearly
impossible, and thus we seek a hash function that distributes the keys evenly among the
cells. Figure 5.1 is typical of a perfect situation. In this example, john hashes to 3, phil
hashes to 4, dave hashes to 6, and mary hashes to 7. 171

172 Chapter 5 Hashing

john 25000

phil 31250

dave 27500

mary 28200

0

1

2

3

4

5

6

7

8

9

Figure 5.1 An ideal hash table

This is the basic idea of hashing. The only remaining problems deal with choosing a
function, deciding what to do when two keys hash to the same value (this is known as a
collision), and deciding on the table size.

5.2 Hash Function
If the input keys are integers, then simply returning Key mod TableSize is generally a rea-
sonable strategy, unless Key happens to have some undesirable properties. In this case, the
choice of hash function needs to be carefully considered. For instance, if the table size
is 10 and the keys all end in zero, then the standard hash function is a bad choice. For
reasons we shall see later, and to avoid situations like the one above, it is often a good idea
to ensure that the table size is prime. When the input keys are random integers, then this
function is not only very simple to compute but also distributes the keys evenly.

Usually, the keys are strings; in this case, the hash function needs to be chosen carefully.
One option is to add up the ASCII (or Unicode) values of the characters in the string.

The routine in Figure 5.2 implements this strategy.
The hash function depicted in Figure 5.2 is simple to implement and computes an

answer quickly. However, if the table size is large, the function does not distribute the keys
well. For instance, suppose that TableSize = 10,007 (10,007 is a prime number). Suppose
all the keys are eight or fewer characters long. Since an ASCII character has an integer value
that is always at most 127, the hash function typically can only assume values between 0
and 1,016, which is 127 ∗ 8. This is clearly not an equitable distribution!

Another hash function is shown in Figure 5.3. This hash function assumes that Key has
at least three characters. The value 27 represents the number of letters in the English alpha-
bet, plus the blank, and 729 is 272. This function examines only the first three characters,

5.2 Hash Function 173

1 public static int hash( String key, int tableSize )
2 {
3 int hashVal = 0;
4
5 for( int i = 0; i < key.length( ); i++ ) 6 hashVal += key.charAt( i ); 7 8 return hashVal % tableSize; 9 } Figure 5.2 A simple hash function 1 public static int hash( String key, int tableSize ) 2 { 3 return ( key.charAt( 0 ) + 27 * key.charAt( 1 ) + 4 729 * key.charAt( 2 ) ) % tableSize; 5 } Figure 5.3 Another possible hash function—not too good but if these are random and the table size is 10,007, as before, then we would expect a reasonably equitable distribution. Unfortunately, English is not random. Although there are 263 = 17,576 possible combinations of three characters (ignoring blanks), a check of a reasonably large online dictionary reveals that the number of different combinations is actually only 2,851. Even if none of these combinations collide, only 28 percent of the table can actually be hashed to. Thus this function, although easily computable, is also not appropriate if the hash table is reasonably large. Figure 5.4 shows a third attempt at a hash function. This hash function involves all characters in the key and can generally be expected to distribute well (it computes∑KeySize−1 i=0 Key[KeySize − i − 1] · 37i and brings the result into proper range). The code computes a polynomial function (of 37) by use of Horner’s rule. For instance, another way of computing hk = k0 + 37k1 + 372k2 is by the formula hk = ((k2) ∗ 37 + k1) ∗ 37 + k0. Horner’s rule extends this to an nth degree polynomial. The hash function takes advantage of the fact that overflow is allowed. This may introduce a negative number; thus the extra test at the end. The hash function described in Figure 5.4 is not necessarily the best with respect to table distribution but does have the merit of extreme simplicity and is reasonably fast. If the keys are very long, the hash function will take too long to compute. A common practice in this case is not to use all the characters. The length and properties of the keys would then influence the choice. For instance, the keys could be a complete street address. The hash function might include a couple of characters from the street address and perhaps a couple of characters from the city name and ZIP code. Some programmers implement their hash function by using only the characters in the odd spaces, with the idea that the time saved computing the hash function will make up for a slightly less evenly distributed function. 174 Chapter 5 Hashing 1 /** 2 * A hash routine for String objects. 3 * @param key the String to hash. 4 * @param tableSize the size of the hash table. 5 * @return the hash value. 6 */ 7 public static int hash( String key, int tableSize ) 8 { 9 int hashVal = 0; 10 11 for( int i = 0; i < key.length( ); i++ ) 12 hashVal = 37 * hashVal + key.charAt( i ); 13 14 hashVal %= tableSize; 15 if( hashVal < 0 ) 16 hashVal += tableSize; 17 18 return hashVal; 19 } Figure 5.4 A good hash function The main programming detail left is collision resolution. If, when an element is inserted, it hashes to the same value as an already inserted element, then we have a col- lision and need to resolve it. There are several methods for dealing with this. We will discuss two of the simplest: separate chaining and open addressing; then we will look at some more recently discovered alternatives. 5.3 Separate Chaining The first strategy, commonly known as separate chaining, is to keep a list of all elements that hash to the same value. We can use the standard library list implementations. If space is tight, it might be preferable to avoid their use (since those lists are doubly linked and waste space). We assume, for this section, that the keys are the first 10 perfect squares and that the hashing function is simply hash(x) = x mod 10. (The table size is not prime but is used here for simplicity.) Figure 5.5 should make this clear. To perform a search, we use the hash function to determine which list to traverse. We then search the appropriate list. To perform an insert, we check the appropriate list to see whether the element is already in place (if duplicates are expected, an extra field is usually kept, and this field would be incremented in the event of a match). If the element turns out to be new, it is inserted at the front of the list, since it is convenient and also because frequently it happens that recently inserted elements are the most likely to be accessed in the near future. The class skeleton required to implement separate chaining is shown in Figure 5.6. The hash table stores an array of linked lists, which are allocated in the constructor. 5.3 Separate Chaining 175 0 81 1 64 4 25 36 16 49 9 0 1 2 3 4 5 6 7 8 9 Figure 5.5 A separate chaining hash table 1 public class SeparateChainingHashTable
2 {
3 public SeparateChainingHashTable( )
4 { /* Figure 5.9 */ }
5 public SeparateChainingHashTable( int size )
6 { /* Figure 5.9 */ }
7
8 public void insert( AnyType x )
9 { /* Figure 5.10 */ }

10 public void remove( AnyType x )
11 { /* Figure 5.10 */ }
12 public boolean contains( AnyType x )
13 { /* Figure 5.10 */ }
14 public void makeEmpty( )
15 { /* Figure 5.9 */ }
16
17 private static final int DEFAULT_TABLE_SIZE = 101;
18
19 private List [ ] theLists;
20 private int currentSize;
21
22 private void rehash( )
23 { /* Figure 5.22 */ }
24 private int myhash( AnyType x )
25 { /* Figure 5.7 */ }
26
27 private static int nextPrime( int n )
28 { /* See online code */ }
29 private static boolean isPrime( int n )
30 { /* See online code */ }
31 }

Figure 5.6 Class skeleton for separate chaining hash table

176 Chapter 5 Hashing

1 private int myhash( AnyType x )
2 {
3 int hashVal = x.hashCode( );
4
5 hashVal %= theLists.length;
6 if( hashVal < 0 ) 7 hashVal += theLists.length; 8 9 return hashVal; 10 } Figure 5.7 myHash method for hash tables 1 public class Employee 2 { 3 public boolean equals( Object rhs ) 4 { return rhs instanceof Employee && name.equals( ((Employee)rhs).name ); } 5 6 public int hashCode( ) 7 { return name.hashCode( ); } 8 9 private String name; 10 private double salary; 11 private int seniority; 12 13 // Additional fields and methods 14 } Figure 5.8 Example of Employee class that can be in a hash table Just as the binary search tree works only for objects that are Comparable, the hash tables in this chapter work only for objects that follow a certain protocol. In Java such objects must provide an appropriate equals method and a hashCode method that returns an int. The hash table can then scale this int into a suitable array index via myHash, as shown in Figure 5.7. Figure 5.8 illustrates an Employee class that can be stored in a hash table. The Employee class provides an equals method and a hashCode method based on the Employee’s name. The hashCode for the Employee class works by using the hashCode defined in the Standard String class. That hashCode is basically the code in Figure 5.4 with lines 14–16 removed. Figure 5.9 shows the constructors and makeEmpty. The code to implement contains, insert, and remove is shown in Figure 5.10. 5.3 Separate Chaining 177 1 /** 2 * Construct the hash table. 3 */ 4 public SeparateChainingHashTable( ) 5 { 6 this( DEFAULT_TABLE_SIZE ); 7 } 8 9 /** 10 * Construct the hash table. 11 * @param size approximate table size. 12 */ 13 public SeparateChainingHashTable( int size ) 14 { 15 theLists = new LinkedList[ nextPrime( size ) ]; 16 for( int i = 0; i < theLists.length; i++ ) 17 theLists[ i ] = new LinkedList<>( );
18 }
19
20 /**
21 * Make the hash table logically empty.
22 */
23 public void makeEmpty( )
24 {
25 for( int i = 0; i < theLists.length; i++ ) 26 theLists[ i ].clear( ); 27 currentSize = 0; 28 } Figure 5.9 Constructors and makeEmpty for separate chaining hash table In the insertion routine, if the item to be inserted is already present, then we do noth- ing; otherwise, we place it in the list. The element can be placed anywhere in the list; using add is most convenient in our case. Any scheme could be used besides linked lists to resolve the collisions; a binary search tree or even another hash table would work, but we expect that if the table is large and the hash function is good, all the lists should be short, so basic separate chaining makes no attempt to try anything complicated. We define the load factor, λ, of a hash table to be the ratio of the number of elements in the hash table to the table size. In the example above, λ = 1.0. The average length of a list is λ. The effort required to perform a search is the constant time required to evaluate the hash function plus the time to traverse the list. In an unsuccessful search, the number of nodes to examine is λ on average. A successful search requires that about 1+(λ/2) links be traversed. To see this, notice that the list that is being searched contains the one node that stores the match plus zero or more other nodes. The expected number of “other nodes” 178 Chapter 5 Hashing 1 /** 2 * Find an item in the hash table. 3 * @param x the item to search for. 4 * @return true if x is not found. 5 */ 6 public boolean contains( AnyType x ) 7 { 8 List whichList = theLists[ myhash( x ) ];
9 return whichList.contains( x );

10 }
11
12 /**
13 * Insert into the hash table. If the item is
14 * already present, then do nothing.
15 * @param x the item to insert.
16 */
17 public void insert( AnyType x )
18 {
19 List whichList = theLists[ myhash( x ) ];
20 if( !whichList.contains( x ) )
21 {
22 whichList.add( x );
23
24 // Rehash; see Section 5.5
25 if( ++currentSize > theLists.length )
26 rehash( );
27 }
28 }
29
30 /**
31 * Remove from the hash table.
32 * @param x the item to remove.
33 */
34 public void remove( AnyType x )
35 {
36 List whichList = theLists[ myhash( x ) ];
37 if( whichList.contains( x ) )
38 {
39 whichList.remove( x );
40 currentSize–;
41 }
42 }

Figure 5.10 contains, insert, and remove routines for separate chaining hash table

5.4 Hash Tables Without Linked Lists 179

in a table of N elements and M lists is (N − 1)/M = λ − 1/M, which is essentially λ, since
M is presumed to be large. On average, half the “other nodes” are searched, so combined
with the matching node, we obtain an average search cost of 1 + λ/2 nodes. This analysis
shows that the table size is not really important, but the load factor is. The general rule
for separate chaining hashing is to make the table size about as large as the number of
elements expected (in other words, let λ ≈ 1). In the code in Figure 5.10, if the load
factor exceeds 1, we expand the table size by calling rehash at line 26. rehash is discussed
in Section 5.5. It is also a good idea, as mentioned before, to keep the table size prime to
ensure a good distribution.

5.4 Hash Tables Without Linked Lists
Separate chaining hashing has the disadvantage of using linked lists. This could slow the
algorithm down a bit because of the time required to allocate new cells (especially in other
languages), and also essentially requires the implementation of a second data structure.
An alternative to resolving collisions with linked lists is to try alternative cells until an
empty cell is found. More formally, cells h0(x), h1(x), h2(x), . . . are tried in succession,
where hi(x) = (hash(x)+f(i)) mod TableSize, with f(0) = 0. The function, f , is the collision
resolution strategy. Because all the data go inside the table, a bigger table is needed in such
a scheme than for separate chaining hashing. Generally, the load factor should be below
λ = 0.5 for a hash table that doesn’t use separate chaining. We call such tables probing
hash tables. We now look at three common collision resolution strategies.

5.4.1 Linear Probing
In linear probing, f is a linear function of i, typically f(i) = i. This amounts to trying cells
sequentially (with wraparound) in search of an empty cell. Figure 5.11 shows the result of
inserting keys {89, 18, 49, 58, 69} into a hash table using the same hash function as before
and the collision resolution strategy, f(i) = i.

The first collision occurs when 49 is inserted; it is put in the next available spot, namely,
spot 0, which is open. The key 58 collides with 18, 89, and then 49 before an empty cell
is found three away. The collision for 69 is handled in a similar manner. As long as the
table is big enough, a free cell can always be found, but the time to do so can get quite
large. Worse, even if the table is relatively empty, blocks of occupied cells start forming.
This effect, known as primary clustering, means that any key that hashes into the cluster
will require several attempts to resolve the collision, and then it will add to the cluster.

Although we will not perform the calculations here, it can be shown that the expected
number of probes using linear probing is roughly 12 (1 + 1/(1 − λ)2) for insertions and
unsuccessful searches, and 12 (1 + 1/(1 − λ)) for successful searches. The calculations
are somewhat involved. It is easy to see from the code that insertions and unsuccessful
searches require the same number of probes. A moment’s thought suggests that, on average,
successful searches should take less time than unsuccessful searches.

The corresponding formulas, if clustering is not a problem, are fairly easy to derive. We
will assume a very large table and that each probe is independent of the previous probes.

180 Chapter 5 Hashing

Empty Table After 89 After 18 After 49 After 58 After 69

0 49 49 49

1 58 58

2 69

3

4

5

6

7

8 18 18 18 18

9 89 89 89 89 89

Figure 5.11 Hash table with linear probing, after each insertion

These assumptions are satisfied by a random collision resolution strategy and are reason-
able unless λ is very close to 1. First, we derive the expected number of probes in an
unsuccessful search. This is just the expected number of probes until we find an empty
cell. Since the fraction of empty cells is 1 − λ, the number of cells we expect to probe is
1/(1 − λ). The number of probes for a successful search is equal to the number of probes
required when the particular element was inserted. When an element is inserted, it is done
as a result of an unsuccessful search. Thus, we can use the cost of an unsuccessful search
to compute the average cost of a successful search.

The caveat is that λ changes from 0 to its current value, so that earlier insertions are
cheaper and should bring the average down. For instance, in the table in Figure 5.11,
λ = 0.5, but the cost of accessing 18 is determined when 18 is inserted. At that point,
λ = 0.2. Since 18 was inserted into a relatively empty table, accessing it should be easier
than accessing a recently inserted element such as 69. We can estimate the average by using
an integral to calculate the mean value of the insertion time, obtaining

I(λ) = 1
λ

∫ λ
0

1

1 − xdx =
1

λ
ln

1

1 − λ
These formulas are clearly better than the corresponding formulas for linear probing.
Clustering is not only a theoretical problem but actually occurs in real implementations.
Figure 5.12 compares the performance of linear probing (dashed curves) with what would
be expected from more random collision resolution. Successful searches are indicated by
an S, and unsuccessful searches and insertions are marked with U and I, respectively.

If λ = 0.75, then the formula above indicates that 8.5 probes are expected for an
insertion in linear probing. If λ = 0.9, then 50 probes are expected, which is unreasonable.
This compares with 4 and 10 probes for the respective load factors if clustering were not
a problem. We see from these formulas that linear probing can be a bad idea if the table is
expected to be more than half full. If λ = 0.5, however, only 2.5 probes are required on
average for insertion, and only 1.5 probes are required, on average, for a successful search.

5.4 Hash Tables Without Linked Lists 181

0.0

3.0

6.0

9.0

12.0

15.0

.10 .15 .20 .25 .30 .35 .40 .45 .50 .55 .60 .65 .70 .75 .80 .85 .90 .95

U,I
U,I

S

S

Figure 5.12 Number of probes plotted against load factor for linear probing (dashed) and
random strategy (S is successful search, U is unsuccessful search, and I is insertion)

Empty Table After 89 After 18 After 49 After 58 After 69

0 49 49 49

1

2 58 58

3 69

4

5

6

7

8 18 18 18 18

9 89 89 89 89 89

Figure 5.13 Hash table with quadratic probing, after each insertion

5.4.2 Quadratic Probing
Quadratic probing is a collision resolution method that eliminates the primary clustering
problem of linear probing. Quadratic probing is what you would expect—the collision
function is quadratic. The popular choice is f(i) = i2. Figure 5.13 shows the resulting hash
table with this collision function on the same input used in the linear probing example.

When 49 collides with 89, the next position attempted is one cell away. This cell is
empty, so 49 is placed there. Next 58 collides at position 8. Then the cell one away is tried,

182 Chapter 5 Hashing

but another collision occurs. A vacant cell is found at the next cell tried, which is 22 = 4
away. The key 58 is thus placed in cell 2. The same thing happens for 69.

For linear probing it is a bad idea to let the hash table get nearly full, because per-
formance degrades. For quadratic probing, the situation is even more drastic: There is no
guarantee of finding an empty cell once the table gets more than half full, or even before
the table gets half full if the table size is not prime. This is because at most half of the table
can be used as alternative locations to resolve collisions.

Indeed, we prove now that if the table is half empty and the table size is prime, then
we are always guaranteed to be able to insert a new element.

Theorem 5.1.
If quadratic probing is used, and the table size is prime, then a new element can always
be inserted if the table is at least half empty.

Proof.
Let the table size, TableSize, be an (odd) prime greater than 3. We show that the first
�TableSize/2� alternative locations (including the initial location h0(x)) are all distinct.
Two of these locations are h(x)+i2 (mod TableSize) and h(x)+j2 (mod TableSize), where
0 ≤ i, j ≤
TableSize/2�. Suppose, for the sake of contradiction, that these locations
are the same, but i �= j. Then

h(x) + i2 = h(x) + j2 (mod TableSize)
i2 = j2 (mod TableSize)

i2 − j2 = 0 (mod TableSize)
(i − j)(i + j) = 0 (mod TableSize)

Since TableSize is prime, it follows that either (i − j) or (i + j) is equal to 0 (mod
TableSize). Since i and j are distinct, the first option is not possible. Since 0 ≤ i, j ≤

TableSize/2�, the second option is also impossible. Thus, the first �TableSize/2� alter-
native locations are distinct. If at most
TableSize/2� positions are taken, then an empty
spot can always be found.

If the table is even one more than half full, the insertion could fail (although this is
extremely unlikely). Therefore, it is important to keep this in mind. It is also crucial that
the table size be prime.1 If the table size is not prime, the number of alternative locations
can be severely reduced. As an example, if the table size were 16, then the only alternative
locations would be at distances 1, 4, or 9 away.

Standard deletion cannot be performed in a probing hash table, because the cell might
have caused a collision to go past it. For instance, if we remove 89, then virtually all the
remaining contains operations will fail. Thus, probing hash tables require lazy deletion,
although in this case there really is no laziness implied.

1 If the table size is a prime of the form 4k + 3, and the quadratic collision resolution strategy F(i) = ±i2 is
used, then the entire table can be probed. The cost is a slightly more complicated routine.

5.4 Hash Tables Without Linked Lists 183

The class skeleton required to implement probing hash tables is shown in Figure 5.14.
Instead of an array of lists, we have an array of hash table entry cells, which are also shown
in Figure 5.14. Each entry in the array of HashEntry references is either

1. null.

2. Not null, and the entry is active (isActive is true).

3. Not null, and the entry is marked deleted (isActive is false).

Constructing the table (Figure 5.15) consists of allocating space and then setting each
HashEntry reference to null.

contains(x), shown in Figure 5.16 (on page 186), invokes private methods isActive
and findPos. The private method findPos performs the collision resolution. We ensure in
the insert routine that the hash table is at least twice as large as the number of elements in
the table, so quadratic resolution will always work. In the implementation in Figure 5.16,
elements that are marked as deleted count as being in the table. This can cause problems,
because the table can get too full prematurely. We shall discuss this item presently.

Lines 25 through 28 represent the fast way of doing quadratic resolution. From the
definition of the quadratic resolution function, f(i) = f(i − 1) + 2i − 1, so the next cell to
try is a distance from the previous cell tried and this distance increases by 2 on successive
probes. If the new location is past the array, it can be put back in range by subtracting
TableSize. This is faster than the obvious method, because it avoids the multiplication and
division that seem to be required. An important warning: The order of testing at lines 22
and 23 is important. Don’t switch it!

The final routine is insertion. As with separate chaining hashing, we do nothing if x is
already present. It is a simple modification to do something else. Otherwise, we place it at
the spot suggested by the findPos routine. The code is shown in Figure 5.17 (on page 187).
If the load factor exceeds 0.5, the table is full and we enlarge the hash table. This is called
rehashing, and is discussed in Section 5.5.

Although quadratic probing eliminates primary clustering, elements that hash to the
same position will probe the same alternative cells. This is known as secondary clustering.
Secondary clustering is a slight theoretical blemish. Simulation results suggest that it gen-
erally causes less than an extra half probe per search. The following technique eliminates
this, but does so at the cost of computing an extra hash function.

5.4.3 Double Hashing
The last collision resolution method we will examine is double hashing. For double hash-
ing, one popular choice is f(i) = i ·hash2(x). This formula says that we apply a second hash
function to x and probe at a distance hash2(x), 2hash2(x), . . . , and so on. A poor choice of
hash2(x) would be disastrous. For instance, the obvious choice hash2(x) = x mod 9 would
not help if 99 were inserted into the input in the previous examples. Thus, the function
must never evaluate to zero. It is also important to make sure all cells can be probed (this
is not possible in the example below, because the table size is not prime). A function such
as hash2(x) = R − (x mod R), with R a prime smaller than TableSize, will work well. If we
choose R = 7, then Figure 5.18 shows the results of inserting the same keys as before.

184 Chapter 5 Hashing

1 public class QuadraticProbingHashTable
2 {
3 public QuadraticProbingHashTable( )
4 { /* Figure 5.15 */ }
5 public QuadraticProbingHashTable( int size )
6 { /* Figure 5.15 */ }
7 public void makeEmpty( )
8 { /* Figure 5.15 */ }
9

10 public boolean contains( AnyType x )
11 { /* Figure 5.16 */ }
12 public void insert( AnyType x )
13 { /* Figure 5.17 */ }
14 public void remove( AnyType x )
15 { /* Figure 5.17 */ }
16
17 private static class HashEntry
18 {
19 public AnyType element; // the element
20 public boolean isActive; // false if marked deleted
21
22 public HashEntry( AnyType e )
23 { this( e, true ); }
24
25 public HashEntry( AnyType e, boolean i )
26 { element = e; isActive = i; }
27 }
28
29 private static final int DEFAULT_TABLE_SIZE = 11;
30
31 private HashEntry [ ] array; // The array of elements
32 private int currentSize; // The number of occupied cells
33
34 private void allocateArray( int arraySize )
35 { /* Figure 5.15 */ }
36 private boolean isActive( int currentPos )
37 { /* Figure 5.16 */ }
38 private int findPos( AnyType x )
39 { /* Figure 5.16 */ }
40 private void rehash( )
41 { /* Figure 5.22 */ }
42
43 private int myhash( AnyType x )
44 { /* See online code */ }
45 private static int nextPrime( int n )
46 { /* See online code */ }
47 private static boolean isPrime( int n )
48 { /* See online code */ }
49 }

Figure 5.14 Class skeleton for hash tables using probing strategies, including the nested
HashEntry class

5.4 Hash Tables Without Linked Lists 185

1 /**
2 * Construct the hash table.
3 */
4 public QuadraticProbingHashTable( )
5 {
6 this( DEFAULT_TABLE_SIZE );
7 }
8
9 /**

10 * Construct the hash table.
11 * @param size the approximate initial size.
12 */
13 public QuadraticProbingHashTable( int size )
14 {
15 allocateArray( size );
16 makeEmpty( );
17 }
18
19 /**
20 * Make the hash table logically empty.
21 */
22 public void makeEmpty( )
23 {
24 currentSize = 0;
25 for( int i = 0; i < array.length; i++ ) 26 array[ i ] = null; 27 } 28 29 /** 30 * Internal method to allocate array. 31 * @param arraySize the size of the array. 32 */ 33 private void allocateArray( int arraySize ) 34 { 35 array = new HashEntry[ nextPrime( arraySize ) ]; 36 } Figure 5.15 Routines to initialize hash table The first collision occurs when 49 is inserted. hash2(49) = 7−0 = 7, so 49 is inserted in position 6. hash2(58) = 7 − 2 = 5, so 58 is inserted at location 3. Finally, 69 collides and is inserted at a distance hash2(69) = 7 − 6 = 1 away. If we tried to insert 60 in position 0, we would have a collision. Since hash2(60) = 7 − 4 = 3, we would then try positions 3, 6, 9, and then 2 until an empty spot is found. It is generally possible to find some bad case, but there are not too many here. 186 Chapter 5 Hashing 1 /** 2 * Find an item in the hash table. 3 * @param x the item to search for. 4 * @return the matching item. 5 */ 6 public boolean contains( AnyType x ) 7 { 8 int currentPos = findPos( x ); 9 return isActive( currentPos ); 10 } 11 12 /** 13 * Method that performs quadratic probing resolution in half-empty table. 14 * @param x the item to search for. 15 * @return the position where the search terminates. 16 */ 17 private int findPos( AnyType x ) 18 { 19 int offset = 1; 20 int currentPos = myhash( x ); 21 22 while( array[ currentPos ] != null && 23 !array[ currentPos ].element.equals( x ) ) 24 { 25 currentPos += offset; // Compute ith probe 26 offset += 2; 27 if( currentPos >= array.length )
28 currentPos -= array.length;
29 }
30
31 return currentPos;
32 }
33
34 /**
35 * Return true if currentPos exists and is active.
36 * @param currentPos the result of a call to findPos.
37 * @return true if currentPos is active.
38 */
39 private boolean isActive( int currentPos )
40 {
41 return array[ currentPos ] != null && array[ currentPos ].isActive;
42 }

Figure 5.16 contains routine (and private helpers) for hashing with quadratic probing

5.4 Hash Tables Without Linked Lists 187

1 /**
2 * Insert into the hash table. If the item is
3 * already present, do nothing.
4 * @param x the item to insert.
5 */
6 public void insert( AnyType x )
7 {
8 // Insert x as active
9 int currentPos = findPos( x );

10 if( isActive( currentPos ) )
11 return;
12
13 array[ currentPos ] = new HashEntry<>( x, true );
14
15 // Rehash; see Section 5.5
16 if( ++currentSize > array.length / 2 )
17 rehash( );
18 }
19
20 /**
21 * Remove from the hash table.
22 * @param x the item to remove.
23 */
24 public void remove( AnyType x )
25 {
26 int currentPos = findPos( x );
27 if( isActive( currentPos ) )
28 array[ currentPos ].isActive = false;
29 }

Figure 5.17 insert routine for hash tables with quadratic probing

As we have said before, the size of our sample hash table is not prime. We have done
this for convenience in computing the hash function, but it is worth seeing why it is impor-
tant to make sure the table size is prime when double hashing is used. If we attempt to
insert 23 into the table, it would collide with 58. Since hash2(23) = 7 − 2 = 5, and the
table size is 10, we essentially have only one alternative location, and it is already taken.
Thus, if the table size is not prime, it is possible to run out of alternative locations pre-
maturely. However, if double hashing is correctly implemented, simulations imply that the
expected number of probes is almost the same as for a random collision resolution strat-
egy. This makes double hashing theoretically interesting. Quadratic probing, however, does
not require the use of a second hash function and is thus likely to be simpler and faster in
practice, especially for keys like strings whose hash functions are expensive to compute.

188 Chapter 5 Hashing

Empty Table After 89 After 18 After 49 After 58 After 69

0 69

1

2

3 58 58

4

5

6 49 49 49

7

8 18 18 18 18

9 89 89 89 89 89

Figure 5.18 Hash table with double hashing, after each insertion

5.5 Rehashing
If the table gets too full, the running time for the operations will start taking too long
and insertions might fail for open addressing hashing with quadratic resolution. This can
happen if there are too many removals intermixed with insertions. A solution, then, is
to build another table that is about twice as big (with an associated new hash function)
and scan down the entire original hash table, computing the new hash value for each
(nondeleted) element and inserting it in the new table.

As an example, suppose the elements 13, 15, 24, and 6 are inserted into a linear
probing hash table of size 7. The hash function is h(x) = x mod 7. Suppose linear probing
is used to resolve collisions. The resulting hash table appears in Figure 5.19.

If 23 is inserted into the table, the resulting table in Figure 5.20 will be over 70 percent
full. Because the table is so full, a new table is created. The size of this table is 17, because
this is the first prime that is twice as large as the old table size. The new hash function is
then h(x) = x mod 17. The old table is scanned, and elements 6, 15, 23, 24, and 13 are
inserted into the new table. The resulting table appears in Figure 5.21.

This entire operation is called rehashing. This is obviously a very expensive operation;
the running time is O(N), since there are N elements to rehash and the table size is roughly
2N, but it is actually not all that bad, because it happens very infrequently. In particular,
there must have been N/2 insertions prior to the last rehash, so it essentially adds a con-
stant cost to each insertion.2 If this data structure is part of the program, the effect is not
noticeable. On the other hand, if the hashing is performed as part of an interactive system,
then the unfortunate user whose insertion caused a rehash could see a slowdown.

Rehashing can be implemented in several ways with quadratic probing. One alternative
is to rehash as soon as the table is half full. The other extreme is to rehash only when an

2 This is why the new table is made twice as large as the old table.

5.6 Hash Tables in the Standard Library 189

6

15

24

13

0

1

2

3

4

5

6

Figure 5.19 Hash table with linear probing with input 13, 15, 6, 24

6

15

23

24

13

0

1

2

3

4

5

6

Figure 5.20 Hash table with linear probing after 23 is inserted

insertion fails. A third, middle-of-the-road strategy is to rehash when the table reaches a
certain load factor. Since performance does degrade as the load factor increases, the third
strategy, implemented with a good cutoff, could be best.

Rehashing for separate chaining hash tables is similar. Figure 5.22 shows that rehashing
is simple to implement, and provides an implementation for separate chaining rehashing
also.

5.6 Hash Tables in the Standard Library
The Standard Library includes hash table implementations of Set and Map, namely HashSet
and HashMap. The items in the HashSet (or the keys in the HashMap) must provide an equals
and hashCode method, as described earlier in Section 5.3. The HashSet and HashMap are
currently implemented using separate chaining hashing.

These classes can be used if it is not important for the entries to be viewable in sorted
order. For instance, in the word-changing example in Section 4.8, there were three maps:

190 Chapter 5 Hashing

6

23

24

13

15

0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Figure 5.21 Linear probing hash table after rehashing

1. A map in which the key is a word length, and the value is a collection of all words of
that word length.

2. A map in which the key is a representative, and the value is a collection of all words
with that representative.

3. A map in which the key is a word, and the value is a collection of all words that differ
in only one character from that word.

Because the order in which word lengths are processed does not matter, the first map
can be a HashMap. Because the representatives are not even needed after the second map is
built, the second map can be a HashMap. The third map can also be a HashMap, unless we
want printHighChangeables to alphabetically list the subset of words that can be changed
into a large number of other words.

The performance of a HashMap can often be superior to a TreeMap, but it is hard to know
for sure without writing the code both ways. Thus, in cases where either a HashMap or
TreeMap is acceptable, it is preferable to declare variables using the interface type Map and
then change the instantiation from a TreeMap to a HashMap, and perform timing tests.

5.6 Hash Tables in the Standard Library 191

1 /**
2 * Rehashing for quadratic probing hash table.
3 */
4 private void rehash( )
5 {
6 HashEntry [ ] oldArray = array;
7
8 // Create a new double-sized, empty table
9 allocateArray( nextPrime( 2 * oldArray.length ) );

10 currentSize = 0;
11
12 // Copy table over
13 for( int i = 0; i < oldArray.length; i++ ) 14 if( oldArray[ i ] != null && oldArray[ i ].isActive ) 15 insert( oldArray[ i ].element ); 16 } 17 18 /** 19 * Rehashing for separate chaining hash table. 20 */ 21 private void rehash( ) 22 { 23 List [ ] oldLists = theLists;
24
25 // Create new double-sized, empty table
26 theLists = new List[ nextPrime( 2 * theLists.length ) ];
27 for( int j = 0; j < theLists.length; j++ ) 28 theLists[ j ] = new LinkedList<>( );
29
30 // Copy table over
31 currentSize = 0;
32 for( int i = 0; i < oldLists.length; i++ ) 33 for( AnyType item : oldLists[ i ] ) 34 insert( item ); 35 } Figure 5.22 Rehashing for both separate chaining and probing hash tables In Java, library types that can be reasonably inserted into a HashSet or as keys into a HashMap already have equals and hashCode defined. In particular the String class has a hashCode that is essentially the code in Figure 5.4 with lines 14–16 removed, and 37 replaced with 31. Because the expensive part of the hash table operations is computing the hashCode, the hashCode method in the String class contains an important optimization: Each String object stores internally the value of its hashCode. Initially it is 0, but if hashCode is invoked, the value is remembered. Thus if hashCode is computed on the same String 192 Chapter 5 Hashing 1 public final class String 2 { 3 public int hashCode( ) 4 { 5 if( hash != 0 ) 6 return hash; 7 8 for( int i = 0; i < length( ); i++ ) 9 hash = hash * 31 + (int) charAt( i ); 10 return hash; 11 } 12 13 private int hash = 0; 14 } Figure 5.23 Excerpt of String class hashCode object a second time, we can avoid the expensive recomputation. This technique is called caching the hash code, and represents another classic time-space tradeoff. Figure 5.23 shows an implementation of the String class that caches the hash code. Caching the hash code works only because Strings are immutable: If the String were allowed to change, it would invalidate the hashCode, and the hashCode would have to be reset back to 0. Although two String objects with the same state must have their hash codes computed independently, there are many situations in which the same String object keeps having its hash code queried. One situation where caching the hash code helps occurs during rehashing, because all the Strings involved in the rehashing have already had their hash codes cached. On the other hand, caching the hash code does not help in the representative map for the word changing example. Each of the representatives is a different String computed by removing a character from a larger String, and thus each individual String has to have its hash code computed separately. However, in the third map, caching the hash code does help, because the keys are only Strings that were stored in the original array of Strings. 5.7 Hash Tables with Worst-Case O(1) Access The hash tables that we have examined so far all have the property that with reasonable load factors, and appropriate hash functions, we can expect O(1) cost on average for inser- tions, removes, and searching. But what is the expected worst case for a search assuming a reasonably well-behaved hash function? For separate chaining, assuming a load factor of 1, this is one version of the classic balls and bins problem: Given N balls placed randomly (uniformly) in N bins, what is the expected number of balls in the most occupied bin? The answer is well known to be Θ(log N/ log log N), meaning that on average, we expect some queries to take nearly 5.7 Hash Tables with Worst-Case O(1) Access 193 logarithmic time. Similar types of bounds are observed (or provable) for the length of the longest expected probe sequence in a probing hash table. We would like to obtain O(1) worst-case cost. In some applications, such as hardware implementations of lookup tables for routers and memory caches, it is especially important that the search have a definite (i.e., constant) amount of completion time. Let us assume that N is known in advance, so no rehashing is needed. If we are allowed to rearrange items as they are inserted, then O(1) worst-case cost is achievable for searches. In the remainder of this section we describe the earliest solution to this problem, namely perfect hashing, and then two more recent approaches that appear to offer promising alternatives to the classic hashing schemes that have been prevalent for many years. 5.7.1 Perfect Hashing Suppose, for purposes of simplification, that all N items are known in advance. If a separate chaining implementation could guarantee that each list had at most a constant number of items, we would be done. We know that as we make more lists, the lists will on average be shorter, so theoretically if we have enough lists, then with a reasonably high probability we might expect to have no collisions at all! But there are two fundamental problems with this approach: First, the number of lists might be unreasonably large; second, even with lots of lists, we might still get unlucky. The second problem is relatively easy to address in principle. Suppose we choose the number of lists to be M (i.e., TableSize is M), which is sufficiently large to guarantee that with probability at least 12 , there will be no collisions. Then if a collision is detected, we simply clear out the table and try again using a different hash function that is independent of the first. If we still get a collision, we try a third hash function, and so on. The expected number of trials will be at most 2 (since the success probability is 12 ), and this is all folded into the insertion cost. Section 5.8 discusses the crucial issue of how to produce additional hash functions. So we are left with determining how large M, the number of lists, needs to be. Unfortunately, M needs to be quite large; specifically M = �(N2). However, if M = N2, we can show that the table is collision free with probability at least 12 , and this result can be used to make a workable modification to our basic approach. Theorem 5.2. If N balls are placed into M = N2 bins, the probability that no bin has more than one ball is less than 12 . Proof. If a pair (i, j) of balls are placed in the same bin, we call that a collision. Let Ci,j be the expected number of collisions produced by any two balls (i, j). Clearly the probability that any two specified balls collide is 1/M, and thus Ci,j is 1/M, since the number of collisions that involve the pair (i, j) is either 0 or 1. Thus the expected number of collisions in the entire table is ∑ (i,j), i
2 {
3 int hash( AnyType x, int which );
4 int getNumberOfFunctions( );
5 void generateNewFunctions( );
6 }

Figure 5.36 Generic HashFamily interface for cuckoo hashing

hash functions. Thus our implementation differs from the classic notion of two separately
addressable hash tables. We can implement the classic version by making relatively minor
changes to the code; however, this version provided in this section seems to perform better
in tests using simple hash functions.

In Figure 5.37, we specify that the maximum load for the table is 0.4; if the load
factor of the table is about to exceed this limit, an automatic table expansion is performed.
We also define ALLOWED_REHASHES, which specifies how many rehashes we will perform if
evictions take too long. In theory, ALLOWED_REHASHES can be infinite, since we expect only
a small constant number of rehashes are needed; in practice, depending on several factors
such as the number of hash functions, the quality of the hash functions, and the load factor,
the rehashes could significantly slow things down, and it might be worthwhile to expand
the table, even though this will cost space. The data representation for the cuckoo hash
table is straightforward: We store a simple array, the current size, and the collections of
hash functions, represented in a HashFamily instance. We also maintain the number of hash
functions, even though that is always obtainable from the HashFamily instance.

Figure 5.38 shows the constructor and doClear methods, and these are straightfor-
ward. Figure 5.39 shows a pair of private methods. The first, myHash, is used to select the
appropriate hash function and then scale it into a valid array index. The second, findPos,
consults all the hash functions to return the index containing item x, or −1 if x is not
found. findPos is then used by contains and remove in Figures 5.40 and 5.41, respectively,
and we can see that those methods are easy to implement.

The difficult routine is insertion. In Figure 5.42, we can see that the basic plan is to
check to see if the item is already present, returning if so. Otherwise, we check to see if the
table is fully loaded, and if so, we expand it. Finally we call a helper routine to do all the
dirty work.

The helper routine for insertion is shown in Figure 5.43. We declare a variable rehashes
to keep track of how many attempts have been made to rehash in this insertion. Our
insertion routine is mutually recursive: If needed, insert eventually calls rehash, which
eventually calls back into insert. Thus rehashes is declared in an outer scope for code
simplicity.

Our basic logic is different from the classic scheme. We have already tested that the
item to insert is not already present. At lines 15–25, we check to see if any of the valid

1 public class CuckooHashTable
2 {
3 public CuckooHashTable( HashFamily hf )
4 { /* Figure 5.38 */ }
5 public CuckooHashTable( HashFamily hf, int size );
6 { /* Figure 5.38 */ }
7
8 public void makeEmpty( )
9 { doClear( ); }

10
11 public boolean contains( AnyType x )
12 { /* Figure 5.40 */ }
13
14 private int myhash( AnyType x, int which )
15 { /* Figure 5.39 */ }
16
17 private int findPos( AnyType x )
18 { /* Figure 5.39 */ }
19
20 public boolean remove( AnyType x )
21 { /* Figure 5.41 */ }
22
23 public boolean insert( AnyType x )
24 { /* Figure 5.42 */ }
25
26 private void expand( )
27 { /* Figure 5.44 */ }
28
29 private void rehash( )
30 { /* Figure 5.44 */ }
31
32 private void doClear( )
33 { /* Figure 5.38 */ }
34
35 private void allocateArray( int arraySize )
36 { array = (AnyType[]) new Object[ arraySize ]; }
37
38 private static final double MAX_LOAD = 0.4;
39 private static final int ALLOWED_REHASHES = 1;
40 private static final int DEFAULT_TABLE_SIZE = 101;
41
42 private final HashFamily hashFunctions;
43 private final int numHashFunctions;
44 private AnyType [ ] array;
45 private int currentSize;
46 }

Figure 5.37 Class skeleton for cuckoo hashing

202 Chapter 5 Hashing

1 /**
2 * Construct the hash table.
3 * @param hf the hash family
4 */
5 public CuckooHashTable( HashFamily hf )
6 {
7 this( hf, DEFAULT_TABLE_SIZE );
8 }
9

10 /**
11 * Construct the hash table.
12 * @param hf the hash family
13 * @param size the approximate initial size.
14 */
15 public CuckooHashTable( HashFamily hf, int size )
16 {
17 allocateArray( nextPrime( size ) );
18 doClear( );
19 hashFunctions = hf;
20 numHashFunctions = hf.getNumberOfFunctions( );
21 }
22
23 private void doClear( )
24 {
25 currentSize = 0;
26 for( int i = 0; i < array.length; i++ ) 27 array[ i ] = null; 28 } Figure 5.38 Routines to initialize the cuckoo hash table positions are empty; if so, we place our item in the first available position and we are done. Otherwise, we evict one of the existing items. However, there are some tricky issues: � Evicting the first item did not perform well in experiments. � Evicting the last item did not perform well in experiments. � Evicting the items in sequence (i.e., the first eviction uses hash function 0, the next uses hash function 1, etc.) did not perform well in experiments. � Evicting the item purely randomly did not perform well in experiments: In particular, with only two hash functions, it tended to create cycles. To alleviate the last problem, we maintain the last position that was evicted and if our random item was the last evicted item, we select a new random item. This will loop forever if used with two hash functions, and both hash functions happen to probe to the same 5.7 Hash Tables with Worst-Case O(1) Access 203 1 /** 2 * Compute the hash code for x using specified hash function 3 * @param x the item 4 * @param which the hash function 5 * @return the hash code 6 */ 7 private int myhash( AnyType x, int which ) 8 { 9 int hashVal = hashFunctions.hash( x, which ); 10 11 hashVal %= array.length; 12 if( hashVal < 0 ) 13 hashVal += array.length; 14 15 return hashVal; 16 } 17 18 /** 19 * Method that searches all hash function places. 20 * @param x the item to search for. 21 * @return the position where the search terminates, or -1 if not found. 22 */ 23 private int findPos( AnyType x ) 24 { 25 for( int i = 0; i < numHashFunctions; i++ ) 26 { 27 int pos = myhash( x, i ); 28 if( array[ pos ] != null && array[ pos ].equals( x ) ) 29 return pos; 30 } 31 32 return -1; 33 } Figure 5.39 Routines to find the location of an item in the cuckoo hash table and to compute the hash code for a given table location, and that location was a prior eviction, so we limit the loop to five iterations (deliberately using an odd number). The code for expand and rehash is shown in Figure 5.44. expand creates a larger array but keeps the same hash functions. The zero-parameter rehash leaves the array size unchanged but creates a new array that is populated with newly chosen hash functions. Finally, Figure 5.45 shows the StringHashFamily class that provides a set of simple hash functions for strings. These hash functions replace the constant 37 in Figure 5.4 with randomly chosen numbers (not necessarily prime). 204 Chapter 5 Hashing 1 /** 2 * Find an item in the hash table. 3 * @param x the item to search for. 4 * @return true if item is found. 5 */ 6 public boolean contains( AnyType x ) 7 { 8 return findPos( x ) != -1; 9 } Figure 5.40 Routine to search a cuckoo hash table 1 /** 2 * Remove from the hash table. 3 * @param x the item to remove. 4 * @return true if item was found and removed 5 */ 6 public boolean remove( AnyType x ) 7 { 8 int pos = findPos( x ); 9 10 if( pos != -1 ) 11 { 12 array[ pos ] = null; 13 currentSize--; 14 } 15 16 return pos != -1; 17 } Figure 5.41 Routine to remove from a cuckoo hash table The benefits of cuckoo hashing include the worst-case constant lookup and deletion times, the avoidance of lazy deletion and extra data, and the potential for parallelism. However, cuckoo hashing is extremely sensitive to the choice of hash functions; the inven- tors of the cuckoo hash table reported that many of the standard hash functions that they attempted performed poorly in tests. Furthermore, although the insertion time is expected to be constant time as long as the load factor is below 12 , the bound that has been shown for the expected insertion cost for classic cuckoo hashing with two separate tables (both with load factor λ) is roughly 1/(1 − (4 λ2)1/3), which deteriorates rapidly as the load fac- tor gets close to 12 (the formula itself makes no sense when λ equals or exceeds 1 2 ). Using lower load factors or more than two hash functions seems like a reasonable alternative. 5.7 Hash Tables with Worst-Case O(1) Access 205 1 /** 2 * Insert into the hash table. If the item is 3 * already present, return false. 4 * @param x the item to insert. 5 */ 6 public boolean insert( AnyType x ) 7 { 8 if( contains( x ) ) 9 return false; 10 11 if( currentSize >= array.length * MAX_LOAD )
12 expand( );
13
14 return insertHelper1( x );
15 }

Figure 5.42 Public insert routine for cuckoo hashing

5.7.3 Hopscotch Hashing
Hopscotch hashing is a new algorithm that tries to improve on the classic linear probing
algorithm. Recall that in linear probing, cells are tried in sequential order, starting from the
hash location. Because of primary and secondary clustering, this sequence can be long on
average as the table gets loaded, and thus many improvements such as quadratic probing,
double hashing, and so forth, have been proposed to reduce the number of collisions.
However, on some modern architectures, the locality produced by probing adjacent cells
is a more significant factor than the extra probes, and linear probing can still be practical
or even a best choice.

The idea of hopscotch hashing is to bound the maximal length of the probe sequence
by a predetermined constant that is optimized to the underlying computer’s architecture.
Doing so would give constant-time lookups in the worst case, and like cuckoo hashing, the
lookup could be parallelized to simultaneously check the bounded set of possible locations.

If an insertion would place a new item too far from its hash location, then we effi-
ciently go backward toward the hash location, evicting potential items. If we are careful,
the evictions can be done quickly and guarantee that those evicted are not placed too far
from their hash locations. The algorithm is deterministic in that given a hash function,
either the items can be evicted or they can’t. The latter case implies that the table is likely
too crowded, and a rehash is in order; but this would happen only at extremely high load
factors, exceeding 0.9. For a table with a load factor of 12 , the failure probability is almost
zero (Exercise 5.23).

Let MAX_DIST be the chosen bound on the maximum probe sequence. This means
that item x must be found somewhere in the MAX_DIST positions listed in hash(x),
hash(x) + 1, . . . , hash(x) + (MAX_DIST − 1). In order to efficiently process evictions,
we maintain information that tells for each position x, whether the item in the alternate
position is occupied by an element that hashes to position x.

1 private int rehashes = 0;
2 private Random r = new Random( );
3
4 private boolean insertHelper1( AnyType x )
5 {
6 final int COUNT_LIMIT = 100;
7
8 while( true )
9 {

10 int lastPos = -1;
11 int pos;
12
13 for( int count = 0; count < COUNT_LIMIT; count++ ) 14 { 15 for( int i = 0; i < numHashFunctions; i++ ) 16 { 17 pos = myhash( x, i ); 18 19 if( array[ pos ] == null ) 20 { 21 array[ pos ] = x; 22 currentSize++; 23 return true; 24 } 25 } 26 27 // none of the spots are available. Evict out a random one 28 int i = 0; 29 do 30 { 31 pos = myhash( x, r.nextInt( numHashFunctions ) ) ; 32 } while( pos == lastPos && i++ < 5 ); 33 34 AnyType tmp = array[ lastPos = pos ]; 35 array[ pos ] = x; 36 x = tmp; 37 } 38 39 if( ++rehashes > ALLOWED_REHASHES )
40 {
41 expand( ); // Make the table bigger
42 rehashes = 0; // Reset the # of rehashes
43 }
44 else
45 rehash( ); // Same table size, new hash functions
46 }
47 }

Figure 5.43 Insertion routine for cuckoo hashing uses a different algorithm that chooses
the item to evict randomly, attempting not to re-evict the last item. The table will attempt
to select new hash functions (rehash) if there are too many evictions and will expand if
there are too many rehashes

5.7 Hash Tables with Worst-Case O(1) Access 207

1 private void expand( )
2 {
3 rehash( (int) ( array.length / MAX_LOAD ) );
4 }
5
6 private void rehash( )
7 {
8 hashFunctions.generateNewFunctions( );
9 rehash( array.length );

10 }
11
12 private void rehash( int newLength )
13 {
14 AnyType [ ] oldArray = array;
15 allocateArray( nextPrime( newLength ) );
16 currentSize = 0;
17
18 // Copy table over
19 for( AnyType str : oldArray )
20 if( str != null )
21 insert( str );
22 }

Figure 5.44 Rehashing and expanding code for cuckoo hash tables

As an example, Figure 5.46 shows a fairly crowded hopscotch hash table, using
MAX_DIST = 4. The bit array for position 6 shows that only position 6 has an item
(C) with hash value 6: Only the first bit of Hop[6] is set. Hop[7] has the first two bits
set, indicating that positions 7 and 8 (A and D) are occupied with items whose hash value
is 7. And Hop[8] has only the third bit set, indicating that the item in position 10 (E) has
hash value 8. If MAX_DIST is no more than 32, the Hop array is essentially an array of
32-bit integers, so the additional space requirement is not substantial. If Hop[pos] contains
all 1’s for some pos, then an attempt to insert an item whose hash value is pos will clearly
fail, since there would now be MAX_DIST + 1 items trying to reside within MAX_DIST
positions of pos—an impossibility.

Continuing the example, suppose we now insert item H with hash value 9. Our normal
linear probing would try to place it in position 13, but that is too far from the hash value
of 9. So instead, we look to evict an item and relocate it to position 13. The only candidates
to go into position 13 would be items with hash value of 10, 11, 12, or 13. If we examine
Hop[10], we see that there are no candidates with hash value 10. But Hop[11] produces a
candidate, G, with value 11 that can be placed into position 13. Since position 11 is now
close enough to the hash value of H, we can now insert H. These steps, along with the
changes to the Hop information, are shown in Figure 5.47.

Finally, we will attempt to insert I whose hash value is 6. Linear probing suggests
position 14, but of course that is too far away. Thus we look for in Hop[11], and it tells

208 Chapter 5 Hashing

1 public class StringHashFamily implements HashFamily
2 {
3 private final int [ ] MULTIPLIERS;
4 private final java.util.Random r = new java.util.Random( );
5
6 public StringHashFamily( int d )
7 {
8 MULTIPLIERS = new int[ d ];
9 generateNewFunctions( );

10 }
11
12 public int getNumberOfFunctions( )
13 {
14 return MULTIPLIERS.length;
15 }
16
17 public void generateNewFunctions( )
18 {
19 for( int i = 0; i < MULTIPLIERS.length; i++ ) 20 MULTIPLIERS[ i ] = r.nextInt( ); 21 } 22 23 public int hash( String x, int which ) 24 { 25 final int multiplier = MULTIPLIERS[ which ]; 26 int hashVal = 0; 27 28 for( int i = 0; i < x.length( ); i++ ) 29 hashVal = multiplier * hashVal + x.charAt( i ); 30 31 return hashVal; 32 } 33 } Figure 5.45 Casual string hashing for cuckoo hashing; these hash functions do not prov- ably satisfy the requirements needed for cuckoo hashing but offer decent performance if the table is not highly loaded and the alternate insertion routine in Figure 5.43 is used us that G can move down, freeing up position 13. Now that 13 is vacant, we can look in Hop[10] to find another element to evict. But Hop[10] has all zeros in the first three positions, so there are no items with hash value 10 that can be moved. So we examine Hop[11]. There we find all zeros in the first two positions. So we try Hop[12], where we need the first position to be 1, which it is. Thus F can move down. These two steps are shown in Figure 5.48. Notice, that if this were not the case—for instance if hash(F) were 9 instead of 12—we would be stuck and have to rehash. 5.7 Hash Tables with Worst-Case O(1) Access 209 Item Hop . . . 6 C 1000 7 A 1100 8 D 0010 9 B 1000 10 E 0000 11 G 1000 12 F 1000 13 0000 14 0000 . . . A: 7 B: 9 C: 6 D: 7 E: 8 F: 12 G: 11 Figure 5.46 Hopscotch hashing table. The hops tell which of the positions in the block are occupied with cells containing this hash value. Thus Hop[8] = 0010 indicates that only position 10 currently contains items whose hash value is 8, while positions 8, 9, and 11 do not Item Hop . . . 6 C 1000 7 A 1100 8 D 0010 9 B 1000 10 E 0000 11 G 1000 12 F 1000 13 0000 14 0000 . . . → Item Hop . . . 6 C 1000 7 A 1100 8 D 0010 9 B 1000 10 E 0000 11 0010 12 F 1000 13 G 0000 14 0000 . . . → Item Hop . . . 6 C 1000 7 A 1100 8 D 0010 9 B 1010 10 E 0000 11 H 0010 12 F 1000 13 G 0000 14 0000 . . . A: 7 B: 9 C: 6 D: 7 E: 8 F: 12 G: 11 H: 9 Figure 5.47 Hopscotch hashing table. Attempting to insert H. Linear probing suggests location 13, but that is too far, so we evict G from position 11 to find a closer position However, that is not a problem with our algorithm; instead there would simply be no way to place all of C, I, A, D, E, B, H, and F (if F’s hash value were 9); these items would all have hash values between 6 and 9, and would thus need to be placed in the seven spots between 6 and 12. But that would be eight items in seven spots—an impossibility. However, since this is not the case for our example, and we have evicted an item from position 12, we can now continue, and Figure 5.49 shows the remaining eviction from position 9, and subsequent placement of I. 210 Chapter 5 Hashing Item Hop . . . 6 C 1000 7 A 1100 8 D 0010 9 B 1010 10 E 0000 11 H 0010 12 F 1000 13 G 0000 14 0000 . . . → Item Hop . . . 6 C 1000 7 A 1100 8 D 0010 9 B 1010 10 E 0000 11 H 0001 12 F 1000 13 0000 14 G 0000 . . . → Item Hop . . . 6 C 1000 7 A 1100 8 D 0010 9 B 1010 10 E 0000 11 H 0001 12 0100 13 F 0000 14 G 0000 . . . A: 7 B: 9 C: 6 D: 7 E: 8 F: 12 G: 11 H: 9 I: 6 Figure 5.48 Hopscotch hashing table. Attempting to insert I. Linear probing suggests location 14, but that is too far; consulting Hop[11], we see that G can move down, leaving position 13 open. Consulting Hop[10] gives no suggestions. Hop[11] does not help either (why?), so Hop[12] suggests moving F Item Hop . . . 6 C 1000 7 A 1100 8 D 0010 9 B 1010 10 E 0000 11 H 0001 12 0100 13 F 0000 14 G 0000 . . . → Item Hop . . . 6 C 1000 7 A 1100 8 D 0010 9 0011 10 E 0000 11 H 0001 12 B 0100 13 F 0000 14 G 0000 . . . → Item Hop . . . 6 C 1001 7 A 1100 8 D 0010 9 I 0011 10 E 0000 11 H 0001 12 B 0100 13 F 0000 14 G 0000 . . . A: 7 B: 9 C: 6 D: 7 E: 8 F: 12 G: 11 H: 9 I: 6 Figure 5.49 Hopscotch hashing table. Insertion of I continues: Next B is evicted, and finally we have a spot that is close enough to the hash value and can insert I Hopscotch hashing is a relatively new algorithm, but the initial experimental results are very promising, especially for applications that make use of multiple processors and require significant parallelism and concurrency. It remains to be seen if either cuckoo hashing or hopscotch hashing emerge as a practical alternative to the classic separate chaining and linear/quadratic probing schemes. 5.8 Universal Hashing 211 5.8 Universal Hashing Although hash tables are very efficient and have average cost per operation, assuming appropriate load factors, their analysis and performance depend on the hash function having two fundamental properties: 1. The hash function must be computable in constant time (i.e., independent of the number of items in the hash table). 2. The hash function must distribute its items uniformly among the array slots. In particular, if the hash function is poor, then all bets are off, and the cost per operation can be linear. In this section, we discuss universal hash functions, which allow us to choose the hash function randomly in such a way that condition 2 above is satisfied. As in Section 5.7, we use M to represent Tablesize. Although a strong motivation for the use of universal hash functions is to provide theoretical justification for the assumptions used in the classic hash table analyses, these functions can also be used in applications that require a high level of robustness, in which worst-case (or even substantially degraded) performance, perhaps based on inputs generated by a saboteur or hacker, simply cannot be tolerated. As in Section 5.7, we use M to represent TableSize. Definition 5.1. A family H of hash functions is universal, if for any x �= y, the number of hash functions h in H for which h(x) = h(y) is at most |H|/M. Notice that this definition holds for each pair of items, rather than being averaged over all pairs of items. The definition above means that if we choose a hash function randomly from a universal family H, then the probability of a collision between any two distinct items is at most 1/M, and when adding into a table with N items, the probability of a collision at the initial point is at most N/M, or the load factor. The use of a universal hash function for separate chaining or hopscotch hashing would be sufficient to meet the assumptions used in the analysis of those data structures. However, it is not sufficient for cuckoo hashing, which requires a stronger notion of independence. In cuckoo hashing, we first see if there is a vacant location; if there is not, and we do an eviction, a different item is now involved in looking for a vacant location. This repeats until we find the vacant location, or decide to rehash [generally within O(log N) steps]. In order for the analysis to work, each step must have a collision probability of N/M independently, with a different item x being subject to the hash function. We can formalize this independence requirement in the following definition. 212 Chapter 5 Hashing Definition 5.2. A family H of hash functions is k-universal, if for any x1 �= y1, x2 �= y2, . . . , xk �= yk, the number of hash functions h in H for which h(x1) = h(y1), h(x2) = h(y2), . . ., and h(xk) = h(yk) is at most |H|/Mk. With this definition, we see that the analysis of cuckoo hashing requires an O(log N)- universal hash function (after that many evictions, we give up and rehash). In this section we look only at universal hash functions. To design a simple universal hash function, we will assume first that we are mapping very large integers into smaller integers ranging from 0 to M − 1. Let p be a prime larger than the largest input key. Our universal family H will consist of the following set of functions, where a and b are chosen randomly: H = {Ha,b(x) = ((ax + b) mod p) mod M, where 1 ≤ a ≤ p − 1, 0 ≤ b ≤ p − 1} For example, in this family, three of the possible random choices of (a, b) yield three different hash functions: H3,7(x) = ((3x + 7) mod p) mod M H4,1(x) = ((4x + 1) mod p) mod M H8,0(x) = ((8x) mod p) mod M Observe that there are p(p − 1) possible hash functions that can be chosen. Theorem 5.4. The hash family H = {Ha,b(x) = ((ax + b) mod p) mod M, where 1 ≤ a ≤ p − 1, 0 ≤ b ≤ p − 1} is universal. Proof. Let x and y be distinct values, with x > y, such that Ha,b(x) = Ha,b(y).

Clearly if (ax + b) mod p is equal to (ay + b) mod p, then we will have a collision.
However, this cannot happen: Subtracting equations yields a(x − y) ≡ 0 (mod p),
which would mean that p divides a or p divides x − y, since p is prime. But neither can
happen, since both a and x − y are between 1 and p − 1.

So let r = (ax + b) mod p and let s = (ay + b) mod p, and by the above argument,
r �= s. Thus there are p possible values for r, and for each r, there are p − 1 possible
values for s, for a total of p(p − 1) possible (r, s) pairs. Notice that the number of (a, b)
pairs and the number of (r, s) pairs is identical; thus each (r, s) pair will correspond
to exactly one (a, b) pair if we can solve for (a, b) in terms of r and s. But that is easy:
As before, subtracting equations yields a(x − y) ≡ (r − s) (mod p), which means that
by multiplying both sides by the unique multiplicative inverse of (x − y) (which must
exist, since x − y is not zero and p is prime), we obtain a, in terms of r and s. Then b
follows.

Finally, this means that the probability that x and y collide is equal to the proba-
bility that r ≡ s (mod M), and the above analysis allows us to assume that r and s are
chosen randomly, rather than a and b. Immediate intuition would place this probability
at 1/M, but that would only be true if p were an exact multiple of M, and all possible

5.8 Universal Hashing 213

(r, s) pairs were equally likely. Since p is prime, and r �= s, that is not exactly true, so a
more careful analysis is needed.

For a given r, the number of values of s that can collide mod M is at most �p/M�−1
(the −1 is because r �= s). It is easy to see that this is at most (p − 1)/M. Thus the
probability that r and s will generate a collision is at most 1/M (we divide by p − 1,
because as mentioned earlier in the proof, there are only p − 1 choices for s given r).
This implies that the hash family is universal.

Implementation of this hash function would seem to require two mod operations:
one mod p and the second mod M. Figure 5.50 shows a simple implementation in Java,
assuming that M is significantly less than the 231 − 1 limit of a Java integer. Because the
computations must now be exactly as specified, and thus overflow is no longer acceptable,
we promote to 64-bit long computations.

However, we are allowed to choose any prime p, as long as it is larger than M. Hence, it
makes sense to choose a prime that is most favorable for computations. One such prime is
p = 231 − 1. Prime numbers of this form are known as Mersenne primes; other Mersenne
primes include 25 − 1, 261 − 1 and 289 − 1. Just as a multiplication by a Mersenne prime
such as 31 can be implemented by a bit shift and a subtract, a mod operation involving a
Mersenne prime can also be implemented by a bit shift and an addition:

Suppose r ≡ y (mod p). If we divide y by (p + 1), then y = q′(p + 1) + r′, where q′
and r′ are the quotient and remainder, respectively. Thus, r ≡ q′(p + 1) + r′ (mod p).
And since (p + 1) ≡ 1 (mod p), we obtain r ≡ q′ + r′ (mod p).
Figure 5.51 implements this idea, which is known as the Carter-Wegman trick. On

line 8, the bit shift computes the quotient and the bitwise and computes the remainder

1 public static int universalHash( int x, int A, int B, int P, int M )
2 {
3 return (int) ( ( ( (long) A * x ) + B ) % P ) % M;
4 }

Figure 5.50 Simple implementation of universal hashing

1 public static final int DIGS = 31;
2 public static final int mersennep = (1<> DIGS ) + ( hashVal & mersennep ) );
9 if( hashVal >= mersennep )

10 hashVal -= mersennep;
11
12 return (int) hashVal % M;
13 }

Figure 5.51 Simple implementation of universal hashing

214 Chapter 5 Hashing

when dividing by (p + 1); these bitwise operations work because (p + 1) is an exact power
of two. Since the remainder could be almost as large as p, the resulting sum might be larger
than p, so we scale it back down at lines 9 and 10.

Universal hash functions exist for strings also. First, choose any prime p, larger than M
(and larger than the largest character code). Then use our standard string hashing function,
choosing the multiplier randomly between 1 and p−1 and returning an intermediate hash
value between 0 and p − 1, inclusive. Finally, apply a universal hash function to generate
the final hash value between 0 and M − 1.

5.9 Extendible Hashing
Our last topic in this chapter deals with the case where the amount of data is too large to
fit in main memory. As we saw in Chapter 4, the main consideration then is the number of
disk accesses required to retrieve data.

As before, we assume that at any point we have N records to store; the value of N
changes over time. Furthermore, at most M records fit in one disk block. We will use
M = 4 in this section.

If either probing hashing or separate chaining hashing is used, the major problem
is that collisions could cause several blocks to be examined during a search, even for a
well-distributed hash table. Furthermore, when the table gets too full, an extremely
expensive rehashing step must be performed, which requires O(N) disk accesses.

A clever alternative, known as extendible hashing, allows a search to be performed in
two disk accesses. Insertions also require few disk accesses.

We recall from Chapter 4 that a B-tree has depth O(logM/2 N). As M increases, the depth
of a B-tree decreases. We could in theory choose M to be so large that the depth of the B-tree
would be 1. Then any search after the first would take one disk access, since, presumably,
the root node could be stored in main memory. The problem with this strategy is that the
branching factor is so high that it would take considerable processing to determine which
leaf the data were in. If the time to perform this step could be reduced, then we would
have a practical scheme. This is exactly the strategy used by extendible hashing.

Let us suppose, for the moment, that our data consist of several six-bit integers.
Figure 5.52 shows an extendible hashing scheme for these data. The root of the “tree”
contains four links determined by the leading two bits of the data. Each leaf has up to
M = 4 elements. It happens that in each leaf the first two bits are identical; this is indi-
cated by the number in parentheses. To be more formal, D will represent the number of
bits used by the root, which is sometimes known as the directory. The number of entries
in the directory is thus 2D. dL is the number of leading bits that all the elements of some
leaf L have in common. dL will depend on the particular leaf, and dL ≤ D.

Suppose that we want to insert the key 100100. This would go into the third leaf, but
as the third leaf is already full, there is no room. We thus split this leaf into two leaves,
which are now determined by the first three bits. This requires increasing the directory size
to 3. These changes are reflected in Figure 5.53.

5.9 Extendible Hashing 215

(2)

000100

001000

001010

001011

(2)

010100

011000

(2)

100000

101000

101100

101110

(2)

111000

111001

00 01 10 11

Figure 5.52 Extendible hashing: original data

(2)

000100

001000

001010

001011

(2)

010100

011000

(3)

100000

100100

(3)

101000

101100

101110

(2)

111000

111001

000 001 010 011 100 101 110 111

Figure 5.53 Extendible hashing: after insertion of 100100 and directory split

Notice that all the leaves not involved in the split are now pointed to by two adjacent
directory entries. Thus, although an entire directory is rewritten, none of the other leaves
is actually accessed.

If the key 000000 is now inserted, then the first leaf is split, generating two leaves with
dL = 3. Since D = 3, the only change required in the directory is the updating of the 000
and 001 links. See Figure 5.54.

216 Chapter 5 Hashing

(3)

000000

000100

(3)

001000

001010

001011

(2)

010100

011000

(3)

100000

100100

(3)

101000

101100

101110

(2)

111000

111001

000 001 010 011 100 101 110 111

Figure 5.54 Extendible hashing: after insertion of 000000 and leaf split

This very simple strategy provides quick access times for insert and search operations
on large databases. There are a few important details we have not considered.

First, it is possible that several directory splits will be required if the elements in a leaf
agree in more than D + 1 leading bits. For instance, starting at the original example, with
D = 2, if 111010, 111011, and finally 111100 are inserted, the directory size must be
increased to 4 to distinguish between the five keys. This is an easy detail to take care of,
but must not be forgotten. Second, there is the possibility of duplicate keys; if there are
more than M duplicates, then this algorithm does not work at all. In this case, some other
arrangements need to be made.

These possibilities suggest that it is important for the bits to be fairly random. This can
be accomplished by hashing the keys into a reasonably long integer—hence the name.

We close by mentioning some of the performance properties of extendible hashing,
which are derived after a very difficult analysis. These results are based on the reasonable
assumption that the bit patterns are uniformly distributed.

The expected number of leaves is (N/M) log2 e. Thus the average leaf is ln 2 = 0.69
full. This is the same as for B-trees, which is not entirely surprising, since for both data
structures new nodes are created when the (M + 1)th entry is added.

The more surprising result is that the expected size of the directory (in other words,
2D) is O(N1+1/M/M). If M is very small, then the directory can get unduly large. In this
case, we can have the leaves contain links to the records instead of the actual records,
thus increasing the value of M. This adds a second disk access to each search operation in
order to maintain a smaller directory. If the directory is too large to fit in main memory, the
second disk access would be needed anyway.

Summary 217

Summary

Hash tables can be used to implement the insert and search operations in constant average
time. It is especially important to pay attention to details such as load factor when using
hash tables, since otherwise the time bounds are not valid. It is also important to choose
the hash function carefully when the key is not a short string or integer.

For separate chaining hashing, the load factor should be close to 1, although perfor-
mance does not significantly degrade unless the load factor becomes very large. For probing
hashing, the load factor should not exceed 0.5, unless this is completely unavoidable. If
linear probing is used, performance degenerates rapidly as the load factor approaches 1.
Rehashing can be implemented to allow the table to grow (and shrink), thus maintaining
a reasonable load factor. This is important if space is tight and it is not possible just to
declare a huge hash table.

Other alternatives such as cuckoo hashing and hopscotch hashing can also yield good
results. Because all these algorithms are constant time, it is difficult to make strong state-
ments about which hash table implementation is the “best”; recent simulation results
provide conflicting guidance and suggest that the performance can depend strongly
on the types of items being manipulated, the underlying computer hardware, and the
programming language.

Binary search trees can also be used to implement insert and contains operations.
Although the resulting average time bounds are O(log N), binary search trees also support
routines that require order and are thus more powerful. Using a hash table, it is not possible
to find the minimum element. It is not possible to search efficiently for a string unless the
exact string is known. A binary search tree could quickly find all items in a certain range;
this is not supported by hash tables. Furthermore, the O(log N) bound is not necessarily
that much more than O(1), especially since no multiplications or divisions are required by
search trees.

On the other hand, the worst case for hashing generally results from an implementation
error, whereas sorted input can make binary trees perform poorly. Balanced search trees are
quite expensive to implement, so if no ordering information is required and there is any
suspicion that the input might be sorted, then hashing is the data structure of choice.

Hashing applications are abundant. Compilers use hash tables to keep track of declared
variables in source code. The data structure is known as a symbol table. Hash tables are
the ideal application for this problem. Identifiers are typically short, so the hash function
can be computed quickly, and alphabetizing the variables is often unnecessary.

A hash table is useful for any graph theory problem where the nodes have real names
instead of numbers. Here, as the input is read, vertices are assigned integers from 1 onward
by order of appearance. Again, the input is likely to have large groups of alphabetized
entries. For example, the vertices could be computers. Then if one particular installation
lists its computers as ibm1, ibm2, ibm3, . . . , there could be a dramatic effect on efficiency if
a search tree is used.

A third common use of hash tables is in programs that play games. As the program
searches through different lines of play, it keeps track of positions it has seen by comput-
ing a hash function based on the position (and storing its move for that position). If the
same position reoccurs, usually by a simple transposition of moves, the program can avoid

218 Chapter 5 Hashing

expensive recomputation. This general feature of all game-playing programs is known as
the transposition table.

Yet another use of hashing is in online spelling checkers. If misspelling detection (as
opposed to correction) is important, an entire dictionary can be prehashed and words can
be checked in constant time. Hash tables are well suited for this, because it is not important
to alphabetize words; printing out misspellings in the order they occurred in the document
is certainly acceptable.

Hash tables are often used to implement caches, both in software (for instance, the
cache in your Internet browser) and in hardware (for instance, the memory caches in
modern computers). They are also used in hardware implementations of routers.

We close this chapter by returning to the word puzzle problem of Chapter 1. If the
second algorithm described in Chapter 1 is used, and we assume that the maximum word
size is some small constant, then the time to read in the dictionary containing W words
and put it in a hash table is O(W). This time is likely to be dominated by the disk I/O and
not the hashing routines. The rest of the algorithm would test for the presence of a word
for each ordered quadruple (row, column, orientation, number of characters). As each lookup
would be O(1), and there are only a constant number of orientations (8) and characters
per word, the running time of this phase would be O(R · C). The total running time would
be O(R · C + W), which is a distinct improvement over the original O(R · C · W). We could
make further optimizations, which would decrease the running time in practice; these are
described in the exercises.

Exercises

5.1 Given input {4371, 1323, 6173, 4199, 4344, 9679, 1989} and a hash function
h(x) = x mod 10, show the resulting:
a. Separate chaining hash table.
b. Hash table using linear probing.
c. Hash table using quadratic probing.
d. Hash table with second hash function h2(x) = 7 − (x mod 7).

5.2 Show the result of rehashing the hash tables in Exercise 5.1.

5.3 Write a program to compute the number of collisions required in a long random
sequence of insertions using linear probing, quadratic probing, and double hashing.

5.4 A large number of deletions in a separate chaining hash table can cause the table
to be fairly empty, which wastes space. In this case, we can rehash to a table half
as large. Assume that we rehash to a larger table when there are twice as many
elements as the table size. How empty should the table be before we rehash to a
smaller table?

5.5 Reimplement separate chaining hash tables using singly linked lists instead of using
java.util.LinkedList.

5.6 The isEmpty routine for quadratic probing has not been written. Can you implement
it by returning the expression currentSize==0?

Exercises 219

5.7 In the quadratic probing hash table, suppose that instead of inserting a new item
into the location suggested by findPos, we insert it into the first inactive cell on the
search path (thus, it is possible to reclaim a cell that is marked “deleted,” potentially
saving space).
a. Rewrite the insertion algorithm to use this observation. Do this by having find-

Pos maintain, with an additional variable, the location of the first inactive cell it
encounters.

b. Explain the circumstances under which the revised algorithm is faster than the
original algorithm. Can it be slower?

5.8 Suppose instead of quadratic probing, we use “cubic probing”; here the ith probe
is at hash(x) + i3. Does cubic probing improve on quadratic probing?

5.9 The hash function in Figure 5.4 makes repeated calls to key.length( ) in the for
loop. Is it worth computing this once prior to entering the loop?

5.10 What are the advantages and disadvantages of the various collision resolution
strategies?

5.11 Suppose that to mitigate the effects of secondary clustering we use as the collision
resolution function f(i) = i · r(hash(x)), where hash(x) is the 32-bit hash value
(not yet scaled to a suitable array index), and r(y) = |48271y( mod (231 − 1))|
mod TableSize. (Section 10.4.1 describes a method of performing this calculation
without overflows, but it is unlikely that overflow matters in this case.) Explain
why this strategy tends to avoid secondary clustering, and compare this strategy
with both double hashing and quadratic probing.

5.12 Rehashing requires recomputing the hash function for all items in the hash table.
Since computing the hash function is expensive, suppose objects provide a hash
member function of their own, and each object stores the result in an additional
data member the first time the hash function is computed for it. Show how such a
scheme would apply for the Employee class in Figure 5.8, and explain under what
circumstances the remembered hash value remains valid in each Employee.

5.13 Write a program to implement the following strategy for multiplying two sparse
polynomials P1, P2 of size M and N, respectively. Each polynomial is represented as
a linked list of objects consisting of a coefficient and an exponent (Exercise 3.12).
We multiply each term in P1 by a term in P2 for a total of MN operations. One
method is to sort these terms and combine like terms, but this requires sorting
MN records, which could be expensive, especially in small-memory environments.
Alternatively, we could merge terms as they are computed and then sort the result.
a. Write a program to implement the alternative strategy.
b. If the output polynomial has about O(M + N) terms, what is the running time

of both methods?

�5.14 Describe a procedure that avoids initializing a hash table (at the expense of
memory).

220 Chapter 5 Hashing

5.15 Suppose we want to find the first occurrence of a string P1P2 · · · Pk in a long input
string A1A2 · · · AN. We can solve this problem by hashing the pattern string, obtain-
ing a hash value HP, and comparing this value with the hash value formed from
A1A2 · · · Ak, A2A3 · · · Ak+1, A3A4 · · · Ak+2, and so on until AN−k+1AN−k+2 · · · AN.
If we have a match of hash values, we compare the strings character by character
to verify the match. We return the position (in A) if the strings actually do match,
and we continue in the unlikely event that the match is false.

�a. Show that if the hash value of AiAi+1 · · · Ai+k−1 is known, then the hash value
of Ai+1Ai+2 · · · Ai+k can be computed in constant time.

b. Show that the running time is O(k + N) plus the time spent refuting false
matches.

�c. Show that the expected number of false matches is negligible.
d. Write a program to implement this algorithm.

��e. Describe an algorithm that runs in O(k + N) worst-case time.
��f. Describe an algorithm that runs in O(N/k) average time.

5.16 Java 7 adds syntax that allows a switch statement to work with the String type
(instead of the primitive integer types). Explain how hash tables can be used by the
compiler to implement this language addition.

5.17 An (old style) BASIC program consists of a series of statements numbered in ascend-
ing order. Control is passed by use of a goto or gosub and a statement number. Write
a program that reads in a legal BASIC program and renumbers the statements so that
the first starts at number F and each statement has a number D higher than the pre-
vious statement. You may assume an upper limit of N statements, but the statement
numbers in the input might be as large as a 32-bit integer. Your program must run
in linear time.

5.18 a. Implement the word puzzle program using the algorithm described at the end
of the chapter.

b. We can get a big speed increase by storing, in addition to each word W, all of
W’s prefixes. (If one of W’s prefixes is another word in the dictionary, it is stored
as a real word.) Although this may seem to increase the size of the hash table
drastically, it does not, because many words have the same prefixes. When a scan
is performed in a particular direction, if the word that is looked up is not even
in the hash table as a prefix, then the scan in that direction can be terminated
early. Use this idea to write an improved program to solve the word puzzle.

c. If we are willing to sacrifice the sanctity of the hash table ADT, we can speed up
the program in part (b) by noting that if, for example, we have just computed
the hash function for “excel,” we do not need to compute the hash function for
“excels” from scratch. Adjust your hash function so that it can take advantage of
its previous calculation.

d. In Chapter 2, we suggested using binary search. Incorporate the idea of using
prefixes into your binary search algorithm. The modification should be simple.
Which algorithm is faster?

Exercises 221

1 class Map
2 {
3 public Map( )
4
5 public void put( KeyType key, ValueType val )
6 public ValueType get( KeyType key )
7 public boolean isEmpty( )
8 public void makeEmpty( )
9

10 private QuadraticProbingHashTable> items;
11
12 private static class Entry
13 {
14 KeyType key;
15 ValueType value;
16 // Appropriate Constructors, etc.
17 }
18 }

Figure 5.55 Map skeleton for Exercise 5.20

5.19 Under certain assumptions, the expected cost of an insertion into a hash table with
secondary clustering is given by 1/(1−λ)−λ−ln(1−λ). Unfortunately, this formula
is not accurate for quadratic probing. However, assuming that it is, determine the
following:
a. The expected cost of an unsuccessful search.
b. The expected cost of a successful search.

5.20 Implement a generic Map that supports the put and get operations. The implemen-
tation will store a hash table of pairs (key, definition). Figure 5.55 provides the Map
specification (minus some details).

5.21 Implement a spelling checker by using a hash table. Assume that the dictionary
comes from two sources: an existing large dictionary and a second file containing
a personal dictionary. Output all misspelled words and the line numbers in which
they occur. Also, for each misspelled word, list any words in the dictionary that are
obtainable by applying any of the following rules:
a. Add one character.
b. Remove one character.
c. Exchange adjacent characters.

5.22 Prove Markov’s Inequality: If X is any random variable and a > 0, then
Pr( |X| ≥ a) ≤ E( |X| )/a. Show how this inequality can be applied to Theorems 5.2
and 5.3.

5.23 If a hopscotch table with parameter MAX_DIST has load factor 0.5, what is the
approximate probability that an insertion requires a rehash?

222 Chapter 5 Hashing

5.24 Implement a hopscotch hash table and compare its performance with linear
probing, separate chaining, and cuckoo hashing.

5.25 Implement the classic cuckoo hash table in which two separate tables are main-
tained. The simplest way to do this is to use a single array and modify the hash
function to access either the top half or the bottom half.

5.26 Extend the classic cuckoo hash table to use d hash functions.

5.27 Show the result of inserting the keys 10111101, 00000010, 10011011, 10111110,
01111111, 01010001, 10010110, 00001011, 11001111, 10011110, 11011011,
00101011, 01100001, 11110000, 01101111 into an initially empty extendible
hashing data structure with M = 4.

5.28 Write a program to implement extendible hashing. If the table is small enough to
fit in main memory, how does its performance compare with separate chaining and
open addressing hashing?

References

Despite the apparent simplicity of hashing, much of the analysis is quite difficult, and there
are still many unresolved questions. There are also many interesting theoretical issues.

Hashing dates to at least 1953, when H. P. Luhn wrote an internal IBM memorandum
that used separate chaining hashing. Early papers on hashing are [11] and [32]. A wealth
of information on the subject, including an analysis of hashing with linear probing under
the assumption of totally random and independent hashing, can be found in [25]. More
recent results have shown that linear probing requires only 5-independent hash functions
[31]. An excellent survey on early classic hash tables methods is [28]; [29] contains sug-
gestions, and pitfalls, for choosing hash functions. Precise analytic and simulation results
for separate chaining, linear probing, quadratic probing, and double hashing can be found
in [19]. However, due to changes (improvements) in computer architecture and compilers,
simulation results tend to quickly become dated.

An analysis of double hashing can be found in [20] and [27]. Yet another collision
resolution scheme is coalesced hashing, described in [33]. Yao [37] has shown the uniform
hashing, in which no clustering exists, is optimal with respect to cost of a successful search,
assuming that items cannot move once placed.

Universal hash functions were first described in [5] and [35]; the latter paper intro-
duces the “Carter-Wegman trick” of using Mersenne prime numbers to avoid expensive
mod operations. Perfect hashing is described in [16], and a dynamic version of perfect
hashing was described in [8]. [12] is a survey of some classic dynamic hashing schemes.

The �(log N/ log log N) bound on the length of the longest list in separate chaining
was shown (in precise form) in [18]. The “power of two choices,” showing that when the
shorter of two randomly selected lists in chosen, then the bound on the length of the
longest list is lowered to only �(log log N), was first described in [2]. An early example
of the power of two choices is [4]. The classic work on cuckoo hashing is [30]; since the
initial paper, a host of new results have appeared that analyze the amount of independence

References 223

needed in the hash functions, and describe alternative implementations [7], [34], [15],
[10], [23], [24], [1], [6], [9] and [17]. Hopscotch hashing appeared in [21].

Extendible hashing appears in [13], with analysis in [14] and [36].
Exercise 5.15 (a–d) is from [22]. Part (e) is from [26], and part (f) is from [3].

1. Y. Arbitman, M. Naor, and G. Segev, “De-Amortized Cuckoo Hashing: Provable Worst-Case
Performance and Experimental Results,” Proceedings of the 36th International Colloquium on
Automata, Languages and Programming (2009), 107–118.

2. Y. Azar, A. Broder, A. Karlin, and E. Upfal, “Balanced Allocations,” SIAM Journal of
Computing, 29 (1999), 180–200.

3. R. S. Boyer and J. S. Moore, “A Fast String Searching Algorithm,” Communications of the
ACM, 20 (1977), 762–772.

4. A. Broder and M. Mitzenmacher, “Using Multiple Hash Functions to Improve IP Lookups,”
Proceedings of the Twentieth IEEE INFOCOM (2001), 1454–1463.

5. J. L. Carter and M. N. Wegman, “Universal Classes of Hash Functions,” Journal of Computer
and System Sciences, 18 (1979), 143–154.

6. J. Cohen and D. Kane, “Bounds on the Independence Required for Cuckoo Hashing,”
preprint.

7. L. Devroye and P. Morin, “Cuckoo Hashing: Further Analysis,” Information Processing
Letters, 86 (2003), 215–219.

8. M. Dietzfelbinger, A. R. Karlin, K. Melhorn, F. Meyer auf der Heide, H. Rohnert, and R. E.
Tarjan, “Dynamic Perfect Hashing: Upper and Lower Bounds,” SIAM Journal on Computing,
23 (1994), 738–761.

9. M. Dietzfelbinger and U. Schellbach, “On Risks of Using Cuckoo Hashing with Simple
Universal Hash Classes,” Proceedings of the Twentieth Annual ACM-SIAM Symposium on
Discrete Algorithms (2009), 795–804.

10. M. Dietzfelbinger and C. Weidling, “Balanced Allocation and Dictionaries with Tightly
Packed Constant Size Bins,” Theoretical Computer Science, 380 (2007), 47–68.

11. I. Dumey, “Indexing for Rapid Random-Access Memory,” Computers and Automation, 5
(1956), 6–9.

12. R. J. Enbody and H. C. Du, “Dynamic Hashing Schemes,” Computing Surveys, 20 (1988),
85–113.

13. R. Fagin, J. Nievergelt, N. Pippenger, and H. R. Strong, “Extendible Hashing—A Fast
Access Method for Dynamic Files,” ACM Transactions on Database Systems, 4 (1979),
315–344.

14. P. Flajolet, “On the Performance Evaluation of Extendible Hashing and Trie Searching,”
Acta Informatica, 20 (1983), 345–369.

15. D. Fotakis, R. Pagh, P. Sanders, and P. Spirakis, “Space Efficient Hash Tables with Worst
Case Constant Access Time,” Theory of Computing Systems, 38 (2005), 229–248.

16. M. L. Fredman, J. Komlos, and E. Szemeredi, “Storing a Sparse Table with O(1) Worst Case
Access Time,” Journal of the ACM, 31 (1984), 538–544.

17. A. Frieze, P. Melsted, and M. Mitzenmacher, “An Analysis of Random-Walk Cuckoo
Hashing,” Proceedings of the Twelfth International Workshop on Approximation Algorithms in
Combinatorial Optimization (APPROX) (2009), 350–364.

224 Chapter 5 Hashing

18. G. Gonnet, “Expected Length of the Longest Probe sequence in Hash Code Searching,”
Journal of the Association for Computing Machinery, 28 (1981), 289–304.

19. G. H. Gonnet and R. Baeza-Yates, Handbook of Algorithms and Data Structures, 2nd ed.,
Addison-Wesley, Reading, Mass., 1991.

20. L. J. Guibas and E. Szemeredi, “The Analysis of Double Hashing,” Journal of Computer and
System Sciences, 16 (1978), 226–274.

21. M. Herlihy, N. Shavit, and M. Tzafrir, “Hopscotch Hashing,” Proceedings of the Twenty-
Second International Symposium on Distributed Computing (2008), 350–364.

22. R. M. Karp and M. O. Rabin, “Efficient Randomized Pattern-Matching Algorithms,” Aiken
Computer Laboratory Report TR-31-81, Harvard University, Cambridge, Mass., 1981.

23. A. Kirsch and M. Mitzenmacher, “The Power of One Move: Hashing Schemes
for Hardware,” Proceedings of the 27th IEEE International Conference on Computer
Communications (INFOCOM) (2008), 106–110.

24. A. Kirsch, M. Mitzenmacher, and U. Wieder, “More Robust Hashing: Cuckoo Hashing
with a Stash,” Proceedings of the Sixteenth Annual European Symposium on Algorithms (2008),
611–622.

25. D. E. Knuth, The Art of Computer Programming, Vol. 3: Sorting and Searching, 2nd ed.,
Addison-Wesley, Reading, Mass., 1998.

26. D. E. Knuth, J. H. Morris, and V. R. Pratt, “Fast Pattern Matching in Strings,” SIAM Journal
on Computing, 6 (1977), 323–350.

27. G. Lueker and M. Molodowitch, “More Analysis of Double Hashing,” Proceedings of the
Twentieth ACM Symposium on Theory of Computing (1988), 354–359.

28. W. D. Maurer and T. G. Lewis, “Hash Table Methods,” Computing Surveys, 7 (1975), 5–20.
29. B. J. McKenzie, R. Harries, and T. Bell, “Selecting a Hashing Algorithm,” Software—Practice

and Experience, 20 (1990), 209–224.
30. R. Pagh and F. F. Rodler, “Cuckoo Hashing,” Journal of Algorithms, 51 (2004), 122–144.
31. M. Pătraşcu and M. Thorup, “On the k-Independence Required by Linear Probing and

Minwise Independence,” Proceedings of the 37th International Colloquium on Automata,
Languages, and Programming (2010), 715–726.

32. W. W. Peterson, “Addressing for Random Access Storage,” IBM Journal of Research and
Development, 1 (1957), 130–146.

33. J. S. Vitter, “Implementations for Coalesced Hashing,” Communications of the ACM, 25
(1982), 911–926.

34. B. Vöcking, “How Asymmetry Helps Load Balancing,” Journal of the ACM, 50 (2003),
568–589.

35. M. N. Wegman and J. Carter, “New Hash Functions and Their Use in Authentication and
Set Equality,” Journal of Computer and System Sciences, 22 (1981), 265–279.

36. A. C. Yao, “A Note on the Analysis of Extendible Hashing,” Information Processing Letters,
11 (1980), 84–86.

37. A. C. Yao, “Uniform Hashing Is Optimal,” Journal of the ACM, 32 (1985), 687–693.

C H A P T E R 6

Priority Queues (Heaps)

Although jobs sent to a printer are generally placed on a queue, this might not always be
the best thing to do. For instance, one job might be particularly important, so it might
be desirable to allow that job to be run as soon as the printer is available. Conversely, if,
when the printer becomes available, there are several 1-page jobs and one 100-page job, it
might be reasonable to make the long job go last, even if it is not the last job submitted.
(Unfortunately, most systems do not do this, which can be particularly annoying at times.)

Similarly, in a multiuser environment, the operating system scheduler must decide
which of several processes to run. Generally a process is allowed to run only for a fixed
period of time. One algorithm uses a queue. Jobs are initially placed at the end of the
queue. The scheduler will repeatedly take the first job on the queue, run it until either it
finishes or its time limit is up, and place it at the end of the queue if it does not finish.
This strategy is generally not appropriate, because very short jobs will seem to take a long
time because of the wait involved to run. Generally, it is important that short jobs finish
as fast as possible, so these jobs should have precedence over jobs that have already been
running. Furthermore, some jobs that are not short are still very important and should also
have precedence.

This particular application seems to require a special kind of queue, known as a
priority queue. In this chapter, we will discuss

� Efficient implementation of the priority queue ADT.
� Uses of priority queues.
� Advanced implementations of priority queues.

The data structures we will see are among the most elegant in computer science.

6.1 Model
A priority queue is a data structure that allows at least the following two operations: insert,
which does the obvious thing; and deleteMin, which finds, returns, and removes the mini-
mum element in the priority queue. The insert operation is the equivalent of enqueue, and
deleteMin is the priority queue equivalent of the queue’s dequeue operation.

As with most data structures, it is sometimes possible to add other operations, but
these are extensions and not part of the basic model depicted in Figure 6.1.

Priority queues have many applications besides operating systems. In Chapter 7,
we will see how priority queues are used for external sorting. Priority queues are also 225

226 Chapter 6 Priority Queues (Heaps)

insert
Priority Queue

deleteMin

Figure 6.1 Basic model of a priority queue

important in the implementation of greedy algorithms, which operate by repeatedly find-
ing a minimum; we will see specific examples in Chapters 9 and 10. In this chapter we will
see a use of priority queues in discrete event simulation.

6.2 Simple Implementations
There are several obvious ways to implement a priority queue. We could use a simple
linked list, performing insertions at the front in O(1) and traversing the list, which requires
O(N) time, to delete the minimum. Alternatively, we could insist that the list be kept always
sorted; this makes insertions expensive (O(N)) and deleteMins cheap (O(1)). The former is
probably the better idea of the two, based on the fact that there are never more deleteMins
than insertions.

Another way of implementing priority queues would be to use a binary search tree.
This gives an O(log N) average running time for both operations. This is true in spite of the
fact that although the insertions are random, the deletions are not. Recall that the only ele-
ment we ever delete is the minimum. Repeatedly removing a node that is in the left subtree
would seem to hurt the balance of the tree by making the right subtree heavy. However,
the right subtree is random. In the worst case, where the deleteMins have depleted the
left subtree, the right subtree would have at most twice as many elements as it should.
This adds only a small constant to its expected depth. Notice that the bound can be made
into a worst-case bound by using a balanced tree; this protects one against bad insertion
sequences.

Using a search tree could be overkill because it supports a host of operations that are
not required. The basic data structure we will use will not require links and will support
both operations in O(log N) worst-case time. Insertion will actually take constant time on
average, and our implementation will allow building a priority queue of N items in linear
time, if no deletions intervene. We will then discuss how to implement priority queues to
support efficient merging. This additional operation seems to complicate matters a bit and
apparently requires the use of a linked structure.

6.3 Binary Heap
The implementation we will use is known as a binary heap. Its use is so common for
priority queue implementations that, in the context of priority queues, when the word heap
is used without a qualifier, it is generally assumed to be referring to this implementation

6.3 Binary Heap 227

of the data structure. In this section, we will refer to binary heaps merely as heaps. Like
binary search trees, heaps have two properties, namely, a structure property and a heap-
order property. As with AVL trees, an operation on a heap can destroy one of the properties,
so a heap operation must not terminate until all heap properties are in order. This turns
out to be simple to do.

6.3.1 Structure Property
A heap is a binary tree that is completely filled, with the possible exception of the bottom
level, which is filled from left to right. Such a tree is known as a complete binary tree.
Figure 6.2 shows an example.

It is easy to show that a complete binary tree of height h has between 2h and 2h+1 − 1
nodes. This implies that the height of a complete binary tree is
log N�, which is clearly
O(log N).

An important observation is that because a complete binary tree is so regular, it can be
represented in an array and no links are necessary. The array in Figure 6.3 corresponds to
the heap in Figure 6.2.

For any element in array position i, the left child is in position 2i, the right child is in
the cell after the left child (2i + 1), and the parent is in position
i/2�. Thus not only are
links not required, but the operations required to traverse the tree are extremely simple

A

B C

F GED

H JI

Figure 6.2 A complete binary tree

A B C D E F G H I J

0 1 2 3 4 5 6 7 8 9 10 11 12 13

Figure 6.3 Array implementation of complete binary tree

228 Chapter 6 Priority Queues (Heaps)

1 public class BinaryHeap>
2 {
3 public BinaryHeap( )
4 { /* See online code */ }
5 public BinaryHeap( int capacity )
6 { /* See online code */ }
7 public BinaryHeap( AnyType [ ] items )
8 { /* Figure 6.14 */ }
9

10 public void insert( AnyType x )
11 { /* Figure 6.8 */ }
12 public AnyType findMin( )
13 { /* See online code */ }
14 public AnyType deleteMin( )
15 { /* Figure 6.12 */ }
16 public boolean isEmpty( )
17 { /* See online code */ }
18 public void makeEmpty( )
19 { /* See online code */ }
20
21 private static final int DEFAULT_CAPACITY = 10;
22
23 private int currentSize; // Number of elements in heap
24 private AnyType [ ] array; // The heap array
25
26 private void percolateDown( int hole )
27 { /* Figure 6.12 */ }
28 private void buildHeap( )
29 { /* Figure 6.14 */ }
30 private void enlargeArray( int newSize )
31 { /* See online code */ }
32 }

Figure 6.4 Class skeleton for priority queue

and likely to be very fast on most computers. The only problem with this implementation
is that an estimate of the maximum heap size is required in advance, but typically this is
not a problem (and we can resize if necessary). In Figure 6.3, the limit on the heap size is
13 elements. The array has a position 0; more on this later.

A heap data structure will, then, consist of an array (of Comparable objects) and an
integer representing the current heap size. Figure 6.4 shows a priority queue skeleton.

Throughout this chapter, we shall draw the heaps as trees, with the implication that an
actual implementation will use simple arrays.

6.3 Binary Heap 229

13

21 16

24 31 19 68

65 26 32

13

21 16

6 31 19 68

65 26 32

Figure 6.5 Two complete trees (only the left tree is a heap)

6.3.2 Heap-Order Property
The property that allows operations to be performed quickly is the heap-order property.
Since we want to be able to find the minimum quickly, it makes sense that the smallest
element should be at the root. If we consider that any subtree should also be a heap, then
any node should be smaller than all of its descendants.

Applying this logic, we arrive at the heap-order property. In a heap, for every node X,
the key in the parent of X is smaller than (or equal to) the key in X, with the exception
of the root (which has no parent).1 In Figure 6.5 the tree on the left is a heap, but the tree
on the right is not (the dashed line shows the violation of heap order).

By the heap-order property, the minimum element can always be found at the root.
Thus, we get the extra operation, findMin, in constant time.

6.3.3 Basic Heap Operations
It is easy (both conceptually and practically) to perform the two required operations. All
the work involves ensuring that the heap-order property is maintained.

insert
To insert an element X into the heap, we create a hole in the next available location, since
otherwise the tree will not be complete. If X can be placed in the hole without violating
heap order, then we do so and are done. Otherwise we slide the element that is in the hole’s
parent node into the hole, thus bubbling the hole up toward the root. We continue this
process until X can be placed in the hole. Figure 6.6 shows that to insert 14, we create a
hole in the next available heap location. Inserting 14 in the hole would violate the heap-
order property, so 31 is slid down into the hole. This strategy is continued in Figure 6.7
until the correct location for 14 is found.

1 Analogously, we can declare a (max) heap, which enables us to efficiently find and remove the maximum
element, by changing the heap-order property. Thus, a priority queue can be used to find either a minimum
or a maximum, but this needs to be decided ahead of time.

230 Chapter 6 Priority Queues (Heaps)

13

21 16

24 31 19 68

65 26 32

13

21 16

24 19 68

65 26 32 31

Figure 6.6 Attempt to insert 14: creating the hole and bubbling the hole up

1313

16 14

24 19 68

65 26 32

2121

16

24 19 68

65 26 32 3131

Figure 6.7 The remaining two steps to insert 14 in previous heap

This general strategy is known as a percolate up; the new element is percolated up
the heap until the correct location is found. Insertion is easily implemented with the code
shown in Figure 6.8.

We could have implemented the percolation in the insert routine by performing
repeated swaps until the correct order was established, but a swap requires three assign-
ment statements. If an element is percolated up d levels, the number of assignments
performed by the swaps would be 3d. Our method uses d + 1 assignments.

If the element to be inserted is the new minimum, it will be pushed all the way to the
top. At some point, hole will be 1 and we will want to break out of the loop. We could do
this with an explicit test, or we can put a reference to the inserted item in position 0 in order
to make the loop terminate. We elect to place x into position 0 in our implementation.

The time to do the insertion could be as much as O(log N), if the element to be inserted
is the new minimum and is percolated all the way to the root. On average, the percolation
terminates early; it has been shown that 2.607 comparisons are required on average to
perform an insert, so the average insert moves an element up 1.607 levels.

6.3 Binary Heap 231

1 /**
2 * Insert into the priority queue, maintaining heap order.
3 * Duplicates are allowed.
4 * @param x the item to insert.
5 */
6 public void insert( AnyType x )
7 {
8 if( currentSize == array.length – 1 )
9 enlargeArray( array.length * 2 + 1 );

10
11 // Percolate up
12 int hole = ++currentSize;
13 for( array[ 0 ] = x; x.compareTo( array[ hole / 2 ] ) < 0; hole /= 2 ) 14 array[ hole ] = array[ hole / 2 ]; 15 array[ hole ] = x; 16 } Figure 6.8 Procedure to insert into a binary heap 13 16 1414 19 1919 68 65 26 32 2121 16 19 68 65 26 32 3131 Figure 6.9 Creation of the hole at the root deleteMin deleteMins are handled in a similar manner as insertions. Finding the minimum is easy; the hard part is removing it. When the minimum is removed, a hole is created at the root. Since the heap now becomes one smaller, it follows that the last element X in the heap must move somewhere in the heap. If X can be placed in the hole, then we are done. This is unlikely, so we slide the smaller of the hole’s children into the hole, thus pushing the hole down one level. We repeat this step until X can be placed in the hole. Thus, our action is to place X in its correct spot along a path from the root containing minimum children. In Figure 6.9 the left figure shows a heap prior to the deleteMin. After 13 is removed, we must now try to place 31 in the heap. The value 31 cannot be placed in the hole, because this would violate heap order. Thus, we place the smaller child (14) in the hole, sliding the hole down one level (see Figure 6.10). We repeat this again, and since 31 is larger than 19, 232 Chapter 6 Priority Queues (Heaps) 1414 16 19 1919 68 65 26 32 2121 16 19 68 65 26 32 3131 Figure 6.10 Next two steps in deleteMin 1414 1619 19 19 68 65 32 212126 26 16 19 68 65 3231 31 Figure 6.11 Last two steps in deleteMin we place 19 into the hole and create a new hole one level deeper. We then place 26 in the hole and create a new hole on the bottom level since once again, 31 is too large. Finally, we are able to place 31 in the hole (Figure 6.11). This general strategy is known as a percolate down. We use the same technique as in the insert routine to avoid the use of swaps in this routine. A frequent implementation error in heaps occurs when there are an even number of elements in the heap, and the one node that has only one child is encountered. You must make sure not to assume that there are always two children, so this usually involves an extra test. In the code depicted in Figure 6.12, we’ve done this test at line 29. One extremely tricky solution is always to ensure that your algorithm thinks every node has two children. Do this by placing a sentinel, of value higher than any in the heap, at the spot after the heap ends, at the start of each percolate down when the heap size is even. You should think very carefully before attempting this, and you must put in a prominent comment if you do use this technique. Although this eliminates the need to test for the presence of a right child, you cannot eliminate the requirement that you test when you reach the bottom, because this would require a sentinel for every leaf. The worst-case running time for this operation is O(log N). On average, the element that is placed at the root is percolated almost to the bottom of the heap (which is the level it came from), so the average running time is O(log N). 6.3 Binary Heap 233 1 /** 2 * Remove the smallest item from the priority queue. 3 * @return the smallest item, or throw UnderflowException, if empty. 4 */ 5 public AnyType deleteMin( ) 6 { 7 if( isEmpty( ) ) 8 throw new UnderflowException( ); 9 10 AnyType minItem = findMin( ); 11 array[ 1 ] = array[ currentSize-- ]; 12 percolateDown( 1 ); 13 14 return minItem; 15 } 16 17 /** 18 * Internal method to percolate down in the heap. 19 * @param hole the index at which the percolate begins. 20 */ 21 private void percolateDown( int hole ) 22 { 23 int child; 24 AnyType tmp = array[ hole ]; 25 26 for( ; hole * 2 <= currentSize; hole = child ) 27 { 28 child = hole * 2; 29 if( child != currentSize && 30 array[ child + 1 ].compareTo( array[ child ] ) < 0 ) 31 child++; 32 if( array[ child ].compareTo( tmp ) < 0 ) 33 array[ hole ] = array[ child ]; 34 else 35 break; 36 } 37 array[ hole ] = tmp; 38 } Figure 6.12 Method to perform deleteMin in a binary heap 234 Chapter 6 Priority Queues (Heaps) Figure 6.13 A very large complete binary tree 6.3.4 Other Heap Operations Notice that although finding the minimum can be performed in constant time, a heap designed to find the minimum element (also known as a (min)heap) is of no help whatsoever in finding the maximum element. In fact, a heap has very little ordering infor- mation, so there is no way to find any particular element without a linear scan through the entire heap. To see this, consider the large heap structure (the elements are not shown) in Figure 6.13, where we see that the only information known about the maximum element is that it is at one of the leaves. Half the elements, though, are contained in leaves, so this is practically useless information. For this reason, if it is important to know where elements are, some other data structure, such as a hash table, must be used in addition to the heap. (Recall that the model does not allow looking inside the heap.) If we assume that the position of every element is known by some other method, then several other operations become cheap. The first three operations below all run in logarithmic worst-case time. decreaseKey The decreaseKey(p, ) operation lowers the value of the item at position p by a positive amount . Since this might violate the heap order, it must be fixed by a percolate up. This operation could be useful to system administrators: They can make their programs run with highest priority. increaseKey The increaseKey(p, ) operation increases the value of the item at position p by a positive amount . This is done with a percolate down. Many schedulers automatically drop the priority of a process that is consuming excessive CPU time. 6.3 Binary Heap 235 delete The delete(p) operation removes the node at position p from the heap. This is done by first performing decreaseKey(p,∞) and then performing deleteMin(). When a process is termi- nated by a user (instead of finishing normally), it must be removed from the priority queue. buildHeap The binary heap is sometimes constructed from an initial collection of items. This con- structor takes as input N items and places them into a heap. Obviously, this can be done with N successive inserts. Since each insert will take O(1) average and O(log N) worst- case time, the total running time of this algorithm would be O(N) average but O(N log N) worst-case. Since this is a special instruction and there are no other operations interven- ing, and we already know that the instruction can be performed in linear average time, it is reasonable to expect that with reasonable care a linear time bound can be guaranteed. The general algorithm is to place the N items into the tree in any order, maintaining the structure property. Then, if percolateDown(i) percolates down from node i, the buildHeap routine in Figure 6.14 can be used by the constructor to create a heap-ordered tree. The first tree in Figure 6.15 is the unordered tree. The seven remaining trees in Figures 6.15 through 6.18 show the result of each of the seven percolateDowns. Each dashed line corresponds to two comparisons: one to find the smaller child and one to compare the smaller child with the node. Notice that there are only 10 dashed lines in the entire algorithm (there could have been an 11th—where?) corresponding to 20 comparisons. To bound the running time of buildHeap, we must bound the number of dashed lines. This can be done by computing the sum of the heights of all the nodes in the heap, which is the maximum number of dashed lines. What we would like to show is that this sum is O(N). Theorem 6.1. For the perfect binary tree of height h containing 2h+1−1 nodes, the sum of the heights of the nodes is 2h+1 − 1 − (h + 1). Proof. It is easy to see that this tree consists of 1 node at height h, 2 nodes at height h − 1, 22 nodes at height h − 2, and in general 2i nodes at height h − i. The sum of the heights of all the nodes is then S = h∑ i=0 2i(h − i) = h + 2(h − 1) + 4(h − 2) + 8(h − 3) + 16(h − 4) + · · · + 2h−1(1) (6.1) Multiplying by 2 gives the equation 2S = 2h + 4(h − 1) + 8(h − 2) + 16(h − 3) + · · · + 2h(1) (6.2) We subtract these two equations and obtain Equation (6.3). We find that certain terms almost cancel. For instance, we have 2h − 2(h − 1) = 2, 4(h − 1) − 4(h − 2) = 4, and so on. The last term in Equation (6.2), 2h, does not appear in Equation (6.1); 236 Chapter 6 Priority Queues (Heaps) 1 /** 2 * Construct the binary heap given an array of items. 3 */ 4 public BinaryHeap( AnyType [ ] items ) 5 { 6 currentSize = items.length; 7 array = (AnyType[]) new Comparable[ ( currentSize + 2 ) * 11 / 10 ]; 8 9 int i = 1; 10 for( AnyType item : items ) 11 array[ i++ ] = item; 12 buildHeap( ); 13 } 14 15 /** 16 * Establish heap order property from an arbitrary 17 * arrangement of items. Runs in linear time. 18 */ 19 private void buildHeap( ) 20 { 21 for( int i = currentSize / 2; i > 0; i– )
22 percolateDown( i );
23 }

Figure 6.14 Sketch of buildHeap

150

80 40

30 10 70 110

100 20 90 60 50 120 140 130

150

80 40

30 10 70 110

100 20 90 60 50 120 140 130

Figure 6.15 Left: initial heap; right: after percolateDown(7)

thus, it appears in Equation (6.3). The first term in Equation (6.1), h, does not appear
in Equation (6.2); thus, −h appears in Equation (6.3). We obtain

S = −h + 2 + 4 + 8 + · · · + 2h−1 + 2h = (2h+1 − 1) − (h + 1) (6.3)
which proves the theorem.

6.3 Binary Heap 237

150

80 40

30 10 50 110

100 20 90 60 70 120 140 130

150

80 40

30 10 50 110

100 20 90 60 70 120 140 130

Figure 6.16 Left: after percolateDown(6); right: after percolateDown(5)

150

80 40

20 10 50 110

100 30 90 60 70 120 140 130

150

80 40

20 10 50 110

100 30 90 60 70 120 140 130

Figure 6.17 Left: after percolateDown(4); right: after percolateDown(3)

150

10 40

20 60 50 110

100 30 90 80 70 120 140 130

10

20 40

30 60 50 110

100 150 90 80 70 120 140 130

Figure 6.18 Left: after percolateDown(2); right: after percolateDown(1)

A complete tree is not a perfect binary tree, but the result we have obtained is an upper
bound on the sum of the heights of the nodes in a complete tree. Since a complete tree has
between 2h and 2h+1 nodes, this theorem implies that this sum is O(N), where N is the
number of nodes.

Although the result we have obtained is sufficient to show that buildHeap is linear, the
bound on the sum of the heights is not as strong as possible. For a complete tree with
N = 2h nodes, the bound we have obtained is roughly 2N. The sum of the heights can
be shown by induction to be N − b(N), where b(N) is the number of 1s in the binary
representation of N.

238 Chapter 6 Priority Queues (Heaps)

6.4 Applications of Priority Queues
We have already mentioned how priority queues are used in operating systems design.
In Chapter 9, we will see how priority queues are used to implement several graph algo-
rithms efficiently. Here we will show how to use priority queues to obtain solutions to two
problems.

6.4.1 The Selection Problem
The first problem we will examine is the selection problem from Chapter 1. Recall that the
input is a list of N elements, which can be totally ordered, and an integer k. The selection
problem is to find the kth largest element.

Two algorithms were given in Chapter 1, but neither is very efficient. The first algo-
rithm, which we shall call algorithm 1A, is to read the elements into an array and sort them,
returning the appropriate element. Assuming a simple sorting algorithm, the running time
is O(N2). The alternative algorithm, 1B, is to read k elements into an array and sort them.
The smallest of these is in the kth position. We process the remaining elements one by one.
As an element arrives, it is compared with the kth element in the array. If it is larger, then
the kth element is removed, and the new element is placed in the correct place among the
remaining k − 1 elements. When the algorithm ends, the element in the kth position is the
answer. The running time is O(N ·k) (why?). If k = �N/2�, then both algorithms are O(N2).
Notice that for any k, we can solve the symmetric problem of finding the (N − k + 1)th
smallest element, so k = �N/2� is really the hardest case for these algorithms. This
also happens to be the most interesting case, since this value of k is known as the
median.

We give two algorithms here, both of which run in O(N log N) in the extreme case of
k = �N/2�, which is a distinct improvement.

Algorithm 6A
For simplicity, we assume that we are interested in finding the kth smallest element. The
algorithm is simple. We read the N elements into an array. We then apply the buildHeap
algorithm to this array. Finally, we perform k deleteMin operations. The last element
extracted from the heap is our answer. It should be clear that by changing the heap-order
property, we could solve the original problem of finding the kth largest element.

The correctness of the algorithm should be clear. The worst-case timing is O(N) to
construct the heap, if buildHeap is used, and O(log N) for each deleteMin. Since there are k
deleteMins, we obtain a total running time of O(N + k log N). If k = O(N/log N), then the
running time is dominated by the buildHeap operation and is O(N). For larger values of k,
the running time is O(k log N). If k = �N/2�, then the running time is �(N log N).

Notice that if we run this program for k = N and record the values as they leave the
heap, we will have essentially sorted the input file in O(N log N) time. In Chapter 7, we
will refine this idea to obtain a fast sorting algorithm known as heapsort.

6.4 Applications of Priority Queues 239

Algorithm 6B
For the second algorithm, we return to the original problem and find the kth largest ele-
ment. We use the idea from algorithm 1B. At any point in time we will maintain a set S
of the k largest elements. After the first k elements are read, when a new element is read
it is compared with the kth largest element, which we denote by Sk. Notice that Sk is the
smallest element in S. If the new element is larger, then it replaces Sk in S. S will then have
a new smallest element, which may or may not be the newly added element. At the end of
the input, we find the smallest element in S and return it as the answer.

This is essentially the same algorithm described in Chapter 1. Here, however, we will
use a heap to implement S. The first k elements are placed into the heap in total time O(k)
with a call to buildHeap. The time to process each of the remaining elements is O(1), to test
if the element goes into S, plus O(log k), to delete Sk and insert the new element if this is
necessary. Thus, the total time is O(k + (N − k) log k) = O(N log k). This algorithm also
gives a bound of �(N log N) for finding the median.

In Chapter 7, we will see how to solve this problem in O(N) average time. In
Chapter 10, we will see an elegant, albeit impractical, algorithm to solve this problem
in O(N) worst-case time.

6.4.2 Event Simulation
In Section 3.7.3, we described an important queuing problem. Recall that we have a sys-
tem, such as a bank, where customers arrive and wait in a line until one of k tellers is
available. Customer arrival is governed by a probability distribution function, as is the ser-
vice time (the amount of time to be served once a teller is available). We are interested in
statistics such as how long on average a customer has to wait or how long the line might be.

With certain probability distributions and values of k, these answers can be computed
exactly. However, as k gets larger, the analysis becomes considerably more difficult, so it is
appealing to use a computer to simulate the operation of the bank. In this way, the bank
officers can determine how many tellers are needed to ensure reasonably smooth service.

A simulation consists of processing events. The two events here are (a) a customer
arriving and (b) a customer departing, thus freeing up a teller.

We can use the probability functions to generate an input stream consisting of ordered
pairs of arrival time and service time for each customer, sorted by arrival time. We do not
need to use the exact time of day. Rather, we can use a quantum unit, which we will refer
to as a tick.

One way to do this simulation is to start a simulation clock at zero ticks. We then
advance the clock one tick at a time, checking to see if there is an event. If there is, then we
process the event(s) and compile statistics. When there are no customers left in the input
stream and all the tellers are free, then the simulation is over.

The problem with this simulation strategy is that its running time does not depend
on the number of customers or events (there are two events per customer), but instead
depends on the number of ticks, which is not really part of the input. To see why this is
important, suppose we changed the clock units to milliticks and multiplied all the times in
the input by 1,000. The result would be that the simulation would take 1,000 times longer!

240 Chapter 6 Priority Queues (Heaps)

The key to avoiding this problem is to advance the clock to the next event time at each
stage. This is conceptually easy to do. At any point, the next event that can occur is either
(a) the next customer in the input file arrives or (b) one of the customers at a teller leaves.
Since all the times when the events will happen are available, we just need to find the event
that happens nearest in the future and process that event.

If the event is a departure, processing includes gathering statistics for the departing
customer and checking the line (queue) to see whether there is another customer waiting. If
so, we add that customer, process whatever statistics are required, compute the time when
that customer will leave, and add that departure to the set of events waiting to happen.

If the event is an arrival, we check for an available teller. If there is none, we place the
arrival on the line (queue); otherwise we give the customer a teller, compute the customer’s
departure time, and add the departure to the set of events waiting to happen.

The waiting line for customers can be implemented as a queue. Since we need to find
the event nearest in the future, it is appropriate that the set of departures waiting to happen
be organized in a priority queue. The next event is thus the next arrival or next departure
(whichever is sooner); both are easily available.

It is then straightforward, although possibly time-consuming, to write the simulation
routines. If there are C customers (and thus 2C events) and k tellers, then the running time
of the simulation would be O(C log(k + 1)) because computing and processing each event
takes O(log H), where H = k + 1 is the size of the heap.2

6.5 d-Heaps
Binary heaps are so simple that they are almost always used when priority queues are
needed. A simple generalization is a d-heap, which is exactly like a binary heap except that
all nodes have d children (thus, a binary heap is a 2-heap).

Figure 6.19 shows a 3-heap. Notice that a d-heap is much shallower than a binary heap,
improving the running time of inserts to O(logd N). However, for large d, the deleteMin
operation is more expensive, because even though the tree is shallower, the minimum of d
children must be found, which takes d − 1 comparisons using a standard algorithm. This
raises the time for this operation to O(d logd N). If d is a constant, both running times are, of
course, O(log N). Although an array can still be used, the multiplications and divisions to
find children and parents are now by d, which, unless d is a power of 2, seriously increases
the running time, because we can no longer implement division by a bit shift. d-heaps are
interesting in theory, because there are many algorithms where the number of insertions is
much greater than the number of deleteMins (and thus a theoretical speedup is possible).
They are also of interest when the priority queue is too large to fit entirely in main memory.
In this case, a d-heap can be advantageous in much the same way as B-trees. Finally, there
is evidence suggesting that 4-heaps may outperform binary heaps in practice.

The most glaring weakness of the heap implementation, aside from the inability to per-
form finds, is that combining two heaps into one is a hard operation. This extra operation

2 We use O(C log(k + 1)) instead of O(C log k) to avoid confusion for the k = 1 case.

6.6 Leftist Heaps 241

1

10

11 9

13 15 174 7 6 8 9

532

Figure 6.19 A d-heap

is known as a merge. There are quite a few ways of implementing heaps so that the running
time of a merge is O(log N). We will now discuss three data structures, of various complex-
ity, that support the merge operation efficiently. We will defer any complicated analysis until
Chapter 11.

6.6 Leftist Heaps
It seems difficult to design a data structure that efficiently supports merging (that is, pro-
cesses a merge in o(N) time) and uses only an array, as in a binary heap. The reason for
this is that merging would seem to require copying one array into another, which would
take �(N) time for equal-sized heaps. For this reason, all the advanced data structures that
support efficient merging require the use of a linked data structure. In practice, we can
expect that this will make all the other operations slower.

Like a binary heap, a leftist heap has both a structural property and an ordering prop-
erty. Indeed, a leftist heap, like virtually all heaps used, has the same heap-order property
we have already seen. Furthermore, a leftist heap is also a binary tree. The only difference
between a leftist heap and a binary heap is that leftist heaps are not perfectly balanced but
actually attempt to be very unbalanced.

6.6.1 Leftist Heap Property
We define the null path length, npl(X), of any node X to be the length of the shortest path
from X to a node without two children. Thus, the npl of a node with zero or one child is 0,
while npl(null) = −1. In the tree in Figure 6.20, the null path lengths are indicated inside
the tree nodes.

Notice that the null path length of any node is 1 more than the minimum of the null
path lengths of its children. This applies to nodes with less than two children because the
null path length of null is −1.

The leftist heap property is that for every node X in the heap, the null path length of
the left child is at least as large as that of the right child. This property is satisfied by only
one of the trees in Figure 6.20, namely, the tree on the left. This property actually goes

242 Chapter 6 Priority Queues (Heaps)

1

1 0

0 0

0

1

1* 0

0 1

0 0

Figure 6.20 Null path lengths for two trees; only the left tree is leftist

out of its way to ensure that the tree is unbalanced, because it clearly biases the tree to get
deep toward the left. Indeed, a tree consisting of a long path of left nodes is possible (and
actually preferable to facilitate merging)—hence the name leftist heap.

Because leftist heaps tend to have deep left paths, it follows that the right path ought
to be short. Indeed, the right path down a leftist heap is as short as any in the heap.
Otherwise, there would be a path that goes through some node X and takes the left child.
Then X would violate the leftist property.

Theorem 6.2.
A leftist tree with r nodes on the right path must have at least 2r − 1 nodes.
Proof.
The proof is by induction. If r = 1, there must be at least one tree node. Otherwise,
suppose that the theorem is true for 1, 2, . . . , r. Consider a leftist tree with r + 1 nodes
on the right path. Then the root has a right subtree with r nodes on the right path, and
a left subtree with at least r nodes on the right path (otherwise it would not be leftist).
Applying the inductive hypothesis to these subtrees yields a minimum of 2r − 1 nodes
in each subtree. This plus the root gives at least 2r+1 − 1 nodes in the tree, proving the
theorem.

From this theorem, it follows immediately that a leftist tree of N nodes has a right path
containing at most
log(N + 1)� nodes. The general idea for the leftist heap operations is
to perform all the work on the right path, which is guaranteed to be short. The only tricky
part is that performing inserts and merges on the right path could destroy the leftist heap
property. It turns out to be extremely easy to restore the property.

6.6.2 Leftist Heap Operations
The fundamental operation on leftist heaps is merging. Notice that insertion is merely a
special case of merging, since we may view an insertion as a merge of a one-node heap with
a larger heap. We will first give a simple recursive solution and then show how this might

6.6 Leftist Heaps 243

3

10 8

21 14

23

17

26

6

12 7

18 24

33

37 18

H1 H2

Figure 6.21 Two leftist heaps H1 and H2

6

12

18 24

33

7

8 37

17 18

26

Figure 6.22 Result of merging H2 with H1’s right subheap

be done nonrecursively. Our input is the two leftist heaps, H1 and H2, in Figure 6.21. You
should check that these heaps really are leftist. Notice that the smallest elements are at the
roots. In addition to space for the data and left and right references, each node will have
an entry that indicates the null path length.

If either of the two heaps is empty, then we can return the other heap. Otherwise, to
merge the two heaps, we compare their roots. First, we recursively merge the heap with the
larger root with the right subheap of the heap with the smaller root. In our example, this
means we recursively merge H2 with the subheap of H1 rooted at 8, obtaining the heap in
Figure 6.22.

Since this tree is formed recursively, and we have not yet finished the description of
the algorithm, we cannot at this point show how this heap was obtained. However, it is
reasonable to assume that the resulting tree is a leftist heap, because it was obtained via a
recursive step. This is much like the inductive hypothesis in a proof by induction. Since we

244 Chapter 6 Priority Queues (Heaps)

can handle the base case (which occurs when one tree is empty), we can assume that the
recursive step works as long as we can finish the merge; this is rule 3 of recursion, which
we discussed in Chapter 1. We now make this new heap the right child of the root of H1
(see Figure 6.23).

Although the resulting heap satisfies the heap-order property, it is not leftist because
the left subtree of the root has a null path length of 1 whereas the right subtree has a null
path length of 2. Thus, the leftist property is violated at the root. However, it is easy to
see that the remainder of the tree must be leftist. The right subtree of the root is leftist,
because of the recursive step. The left subtree of the root has not been changed, so it too
must still be leftist. Thus, we need only to fix the root. We can make the entire tree leftist
by merely swapping the root’s left and right children (Figure 6.24) and updating the null
path length—the new null path length is 1 plus the null path length of the new right
child—completing the merge. Notice that if the null path length is not updated, then all
null path lengths will be 0, and the heap will not be leftist but merely random. In this case,
the algorithm will work, but the time bound we will claim will no longer be valid.

The description of the algorithm translates directly into code. The node class
(Figure 6.25) is the same as the binary tree, except that it is augmented with the npl
(null path length) field. The leftist heap stores a reference to the root as its data member.
We have seen in Chapter 4 that when an element is inserted into an empty binary tree,
the node referenced by the root will need to change. We use the usual technique of imple-
menting private recursive methods to do the merging. The class skeleton is also shown in
Figure 6.25.

The two merge routines (Figure 6.26) are drivers designed to remove special cases
and ensure that H1 has the smaller root. The actual merging is performed in merge1
(Figure 6.27). The public merge method merges rhs into the controlling heap. rhs becomes
empty. The alias test in the public method disallows h.merge(h).

The time to perform the merge is proportional to the sum of the length of the right
paths, because constant work is performed at each node visited during the recursive calls.
Thus we obtain an O(log N) time bound to merge two leftist heaps. We can also perform
this operation nonrecursively by essentially performing two passes. In the first pass, we
create a new tree by merging the right paths of both heaps. To do this, we arrange the nodes
on the right paths of H1 and H2 in sorted order, keeping their respective left children. In our
example, the new right path is 3, 6, 7, 8, 18 and the resulting tree is shown in Figure 6.28.
A second pass is made up the heap, and child swaps are performed at nodes that violate
the leftist heap property. In Figure 6.28, there is a swap at nodes 7 and 3, and the same
tree as before is obtained. The nonrecursive version is simpler to visualize but harder to
code. We leave it to the reader to show that the recursive and nonrecursive procedures do
the same thing.

As mentioned above, we can carry out insertions by making the item to be inserted
a one-node heap and performing a merge. To perform a deleteMin, we merely destroy the
root, creating two heaps, which can then be merged. Thus, the time to perform a deleteMin
is O(log N). These two routines are coded in Figure 6.29 and Figure 6.30.

6.6 Leftist Heaps 245

6

12 7

18 24 8 37

33 17 18

26

3

10

21 14

23

Figure 6.23 Result of attaching leftist heap of previous figure as H1’s right child

6

12 7

18 24 8 37

33 17 18

26

3

10

21 14

23

Figure 6.24 Result of swapping children of H1’s root

246 Chapter 6 Priority Queues (Heaps)

1 public class LeftistHeap>
2 {
3 public LeftistHeap( )
4 { root = null; }
5
6 public void merge( LeftistHeap rhs )
7 { /* Figure 6.26 */ }
8 public void insert( AnyType x )
9 { /* Figure 6.29 */ }

10 public AnyType findMin( )
11 { /* See online code */ }
12 public AnyType deleteMin( )
13 { /* Figure 6.30 */ }
14
15 public boolean isEmpty( )
16 { return root == null; }
17 public void makeEmpty( )
18 { root = null; }
19
20 private static class Node
21 {
22 // Constructors
23 Node( AnyType theElement )
24 { this( theElement, null, null ); }
25
26 Node( AnyType theElement, Node lt, Node rt )
27 { element = theElement; left = lt; right = rt; npl = 0; }
28
29 AnyType element; // The data in the node
30 Node left; // Left child
31 Node right; // Right child
32 int npl; // null path length
33 }
34
35 private Node root; // root
36
37 private Node merge( Node h1, Node h2 )
38 { /* Figure 6.26 */ }
39 private Node merge1( Node h1, Node h2 )
40 { /* Figure 6.27 */ }
41 private void swapChildren( Node t )
42 { /* See online code */ }
43 }

Figure 6.25 Leftist heap type declarations

6.6 Leftist Heaps 247

1 /**
2 * Merge rhs into the priority queue.
3 * rhs becomes empty. rhs must be different from this.
4 * @param rhs the other leftist heap.
5 */
6 public void merge( LeftistHeap rhs )
7 {
8 if( this == rhs ) // Avoid aliasing problems
9 return;

10
11 root = merge( root, rhs.root );
12 rhs.root = null;
13 }
14
15 /**
16 * Internal method to merge two roots.
17 * Deals with deviant cases and calls recursive merge1.
18 */
19 private Node merge( Node h1, Node h2 )
20 {
21 if( h1 == null )
22 return h2;
23 if( h2 == null )
24 return h1;
25 if( h1.element.compareTo( h2.element ) < 0 ) 26 return merge1( h1, h2 ); 27 else 28 return merge1( h2, h1 ); 29 } Figure 6.26 Driving routines for merging leftist heaps Finally, we can build a leftist heap in O(N) time by building a binary heap (obvi- ously using a linked implementation). Although a binary heap is clearly leftist, this is not necessarily the best solution, because the heap we obtain is the worst possible leftist heap. Furthermore, traversing the tree in reverse-level order is not as easy with links. The buildHeap effect can be obtained by recursively building the left and right subtrees and then percolating the root down. The exercises contain an alternative solution. 248 Chapter 6 Priority Queues (Heaps) 1 /** 2 * Internal method to merge two roots. 3 * Assumes trees are not empty, and h1’s root contains smallest item. 4 */ 5 private Node merge1( Node h1, Node h2 )
6 {
7 if( h1.left == null ) // Single node
8 h1.left = h2; // Other fields in h1 already accurate
9 else

10 {
11 h1.right = merge( h1.right, h2 );
12 if( h1.left.npl < h1.right.npl ) 13 swapChildren( h1 ); 14 h1.npl = h1.right.npl + 1; 15 } 16 return h1; 17 } Figure 6.27 Actual routine to merge leftist heaps 3 10 21 14 23 6 12 7 8 17 26 18 24 33 37 18 Figure 6.28 Result of merging right paths of H1 and H2 6.7 Skew Heaps 249 1 /** 2 * Insert into the priority queue, maintaining heap order. 3 * @param x the item to insert. 4 */ 5 public void insert( AnyType x ) 6 { 7 root = merge( new Node<>( x ), root );
8 }

Figure 6.29 Insertion routine for leftist heaps

1 /**
2 * Remove the smallest item from the priority queue.
3 * @return the smallest item, or throw UnderflowException if empty.
4 */
5 public AnyType deleteMin( )
6 {
7 if( isEmpty( ) )
8 throw new UnderflowException( );
9

10 AnyType minItem = root.element;
11 root = merge( root.left, root.right );
12
13 return minItem;
14 }

Figure 6.30 deleteMin routine for leftist heaps

6.7 Skew Heaps
A skew heap is a self-adjusting version of a leftist heap that is incredibly simple to imple-
ment. The relationship of skew heaps to leftist heaps is analogous to the relation between
splay trees and AVL trees. Skew heaps are binary trees with heap order, but there is no struc-
tural constraint on these trees. Unlike leftist heaps, no information is maintained about the
null path length of any node. The right path of a skew heap can be arbitrarily long at
any time, so the worst-case running time of all operations is O(N). However, as with splay
trees, it can be shown (see Chapter 11) that for any M consecutive operations, the total
worst-case running time is O(M log N). Thus, skew heaps have O(log N) amortized cost
per operation.

As with leftist heaps, the fundamental operation on skew heaps is merging. The merge
routine is once again recursive, and we perform the exact same operations as before, with

250 Chapter 6 Priority Queues (Heaps)

one exception. The difference is that for leftist heaps, we check to see whether the left
and right children satisfy the leftist heap structure property and swap them if they do not.
For skew heaps, the swap is unconditional; we always do it, with the one exception that
the largest of all the nodes on the right paths does not have its children swapped. This
one exception is what happens in the natural recursive implementation, so it is not really
a special case at all. Furthermore, it is not necessary to prove the bounds, but since this
node is guaranteed not to have a right child, it would be silly to perform the swap and give
it one. (In our example, there are no children of this node, so we do not worry about it.)
Again, suppose our input is the same two heaps as before, Figure 6.31.

If we recursively merge H2 with the subheap of H1 rooted at 8, we will get the heap in
Figure 6.32.

Again, this is done recursively, so by the third rule of recursion (Section 1.3) we need
not worry about how it was obtained. This heap happens to be leftist, but there is no

3

10 8

21 14

23

17

26 H1

6

12 7

18 24

33

37 18

H2

Figure 6.31 Two skew heaps H1 and H2

6

127

18 248 37

331718

26

Figure 6.32 Result of merging H2 with H1’s right subheap

6.7 Skew Heaps 251

6

127

18 248 37

331718

26

3

10

21 14

23

Figure 6.33 Result of merging skew heaps H1 and H2

guarantee that this is always the case. We make this heap the new left child of H1, and the
old left child of H1 becomes the new right child (see Figure 6.33).

The entire tree is leftist, but it is easy to see that that is not always true: Inserting 15
into this new heap would destroy the leftist property.

We can perform all operations nonrecursively, as with leftist heaps, by merging the
right paths and swapping left and right children for every node on the right path, with
the exception of the last. After a few examples, it becomes clear that since all but the last
node on the right path have their children swapped, the net effect is that this becomes the
new left path (see the preceding example to convince yourself). This makes it very easy to
merge two skew heaps visually.3

The implementation of skew heaps is left as a (trivial) exercise. Note that because a
right path could be long, a recursive implementation could fail because of lack of stack
space, even though performance would otherwise be acceptable. Skew heaps have the
advantage that no extra space is required to maintain path lengths and no tests are required
to determine when to swap children. It is an open problem to determine precisely the
expected right path length of both leftist and skew heaps (the latter is undoubtedly more
difficult). Such a comparison would make it easier to determine whether the slight loss of
balance information is compensated by the lack of testing.

3 This is not exactly the same as the recursive implementation (but yields the same time bounds). If we
only swap children for nodes on the right path that are above the point where the merging of right paths
terminated due to exhaustion of one heap’s right path, we get the same result as the recursive version.

252 Chapter 6 Priority Queues (Heaps)

B 3B 2B 1B 0

B 4

Figure 6.34 Binomial trees B0, B1, B2, B3, and B4

6.8 Binomial Queues
Although both leftist and skew heaps support merging, insertion, and deleteMin all effec-
tively in O(log N) time per operation, there is room for improvement because we know
that binary heaps support insertion in constant average time per operation. Binomial queues
support all three operations in O(log N) worst-case time per operation, but insertions take
constant time on average.

6.8.1 Binomial Queue Structure
Binomial queues differ from all the priority queue implementations that we have seen in
that a binomial queue is not a heap-ordered tree but rather a collection of heap-ordered
trees, known as a forest. Each of the heap-ordered trees is of a constrained form known
as a binomial tree (the reason for the name will be obvious later). There is at most one
binomial tree of every height. A binomial tree of height 0 is a one-node tree; a binomial
tree, Bk, of height k is formed by attaching a binomial tree, Bk−1, to the root of another
binomial tree, Bk−1. Figure 6.34 shows binomial trees B0, B1, B2, B3, and B4.

From the diagram we see that a binomial tree, Bk, consists of a root with children
B0, B1, . . . , Bk−1. Binomial trees of height k have exactly 2k nodes, and the number of
nodes at depth d is the binomial coefficient

(k
d

)
. If we impose heap order on the binomial

6.8 Binomial Queues 253

H 1:
16 12

18 24

65

21

Figure 6.35 Binomial queue H1 with six elements

trees and allow at most one binomial tree of any height, we can represent a priority queue
of any size by a collection of binomial trees. For instance, a priority queue of size 13 could
be represented by the forest B3, B2, B0. We might write this representation as 1101, which
not only represents 13 in binary but also represents the fact that B3, B2, and B0 are present
in the representation and B1 is not.

As an example, a priority queue of six elements could be represented as in Figure 6.35.

6.8.2 Binomial Queue Operations
The minimum element can then be found by scanning the roots of all the trees. Since there
are at most log N different trees, the minimum can be found in O(log N) time. Alternatively,
we can maintain knowledge of the minimum and perform the operation in O(1) time, if
we remember to update the minimum when it changes during other operations.