Java Structures

Data Structures in Java for the Principled Programmer

√
The 7 Edition
(Software release 33)

Duane A. Bailey

Williams College
September 2007
 √
This 7 text copyrighted 2005-2007 by

All rights are reserved by The Author.

No part of this draft publiciation may be reproduced or distributed in any form
without prior, written consent of the author.
Contents

Preface to First Edition xi

Preface to the Second Edition xiii

Preface to the “Root 7” Edition xv

0 Introduction 1
0.1 Read Me . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
0.2 He Can’t Say That, Can He? . . . . . . . . . . . . . . . . . . . . . 2

1 The Object-Oriented Method 5

1.1 Data Abstraction and Encapsulation . . . . . . . . . . . . . . . . . 6
1.2 The Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Object-Oriented Terminology . . . . . . . . . . . . . . . . . . . . 8
1.4 A Special-Purpose Class: A Bank Account . . . . . . . . . . . . . . 11
1.5 A General-Purpose Class: An Association . . . . . . . . . . . . . . 14
1.6 Sketching an Example: A Word List . . . . . . . . . . . . . . . . . 18
1.7 Sketching an Example: A Rectangle Class . . . . . . . . . . . . . 20
1.8 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.9 Who Is the User? . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.11 Laboratory: The Day of the Week Calculator . . . . . . . . . . . . 29

2 Comments, Conditions, and Assertions 33

2.1 Pre- and Postconditions . . . . . . . . . . . . . . . . . . . . . . . 34
2.2 Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3 Craftsmanship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5 Laboratory: Using Javadoc Commenting . . . . . . . . . . . . . . 39

3 Vectors 43
3.1 The Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2 Example: The Word List Revisited . . . . . . . . . . . . . . . . . . 47
3.3 Example: Word Frequency . . . . . . . . . . . . . . . . . . . . . . 48
3.4 The Implementation . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.5 Extensibility: A Feature . . . . . . . . . . . . . . . . . . . . . . . . 53
3.6 Example: L-Systems . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7 Example: Vector-Based Sets . . . . . . . . . . . . . . . . . . . . . 57
3.8 Example: The Matrix Class . . . . . . . . . . . . . . . . . . . . . . 60
3.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
iv Contents

3.10 Laboratory: The Silver Dollar Game . . . . . . . . . . . . . . . . . 67

4 Generics 69
4.1 Motivation (in case we need some) . . . . . . . . . . . . . . . . . 70
4.1.1 Possible Solution: Specialization . . . . . . . . . . . . . . 71
4.2 Implementing Generic Container Classes . . . . . . . . . . . . . . 72
4.2.1 Generic Associations . . . . . . . . . . . . . . . . . . . . 72
4.2.2 Parameterizing the Vector Class . . . . . . . . . . . . . . 74
4.2.3 Restricting Parameters . . . . . . . . . . . . . . . . . . . . 79
4.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 Design Fundamentals 81
5.1 Asymptotic Analysis Tools . . . . . . . . . . . . . . . . . . . . . . 81
5.1.1 Time and Space Complexity . . . . . . . . . . . . . . . . . 82
5.1.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.3 The Trading of Time and Space . . . . . . . . . . . . . . . 91
5.1.4 Back-of-the-Envelope Estimations . . . . . . . . . . . . . . 92
5.2 Self-Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.1 Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.2.2 Mathematical Induction . . . . . . . . . . . . . . . . . . . 101
5.3 Properties of Design . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.3.1 Symmetry . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.3.2 Friction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.5 Laboratory: How Fast Is Java? . . . . . . . . . . . . . . . . . . . . 115

6 Sorting 119
6.1 Approaching the Problem . . . . . . . . . . . . . . . . . . . . . . 119
6.2 Selection Sort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.3 Insertion Sort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.4 Mergesort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.5 Quicksort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6.6 Radix Sort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.7 Sorting Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
6.8 Ordering Objects Using Comparators . . . . . . . . . . . . . . . . 140
6.9 Vector-Based Sorting . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.10 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.11 Laboratory: Sorting with Comparators . . . . . . . . . . . . . . . 147

7 A Design Method 149

7.1 The Interface-Based Approach . . . . . . . . . . . . . . . . . . . . 149
7.1.1 Design of the Interface . . . . . . . . . . . . . . . . . . . . 150
7.1.2 Development of an Abstract Implementation . . . . . . . . 151
7.1.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . 152
7.2 Example: Development of Generators . . . . . . . . . . . . . . . . 152
7.3 Example: Playing Cards . . . . . . . . . . . . . . . . . . . . . . . 155
Contents v

7.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

8 Iterators 161
8.1 Java’s Enumeration Interface . . . . . . . . . . . . . . . . . . . . 161
8.2 The Iterator Interface . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.3 Example: Vector Iterators . . . . . . . . . . . . . . . . . . . . . . 165
8.4 Example: Rethinking Generators . . . . . . . . . . . . . . . . . . 167
8.5 Example: Filtering Iterators . . . . . . . . . . . . . . . . . . . . . 170
8.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
8.7 Laboratory: The Two-Towers Problem . . . . . . . . . . . . . . . 175

9 Lists 179
9.1 Example: A Unique Program . . . . . . . . . . . . . . . . . . . . . 182
9.2 Example: Free Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 183
9.3 Partial Implementation: Abstract Lists . . . . . . . . . . . . . . . 186
9.4 Implementation: Singly Linked Lists . . . . . . . . . . . . . . . . 188
9.5 Implementation: Doubly Linked Lists . . . . . . . . . . . . . . . . 201
9.6 Implementation: Circularly Linked Lists . . . . . . . . . . . . . . 206
9.7 Implementation: Vectors . . . . . . . . . . . . . . . . . . . . . . . 209
9.8 List Iterators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
9.9 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9.10 Laboratory: Lists with Dummy Nodes . . . . . . . . . . . . . . . . 215

10 Linear Structures 219

10.1 Stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
10.1.1 Example: Simulating Recursion . . . . . . . . . . . . . . . 222
10.1.2 Vector-Based Stacks . . . . . . . . . . . . . . . . . . . . . 225
10.1.3 List-Based Stacks . . . . . . . . . . . . . . . . . . . . . . . 227
10.1.4 Comparisons . . . . . . . . . . . . . . . . . . . . . . . . . 228
10.2 Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
10.2.1 Example: Solving a Coin Puzzle . . . . . . . . . . . . . . . 231
10.2.2 List-Based Queues . . . . . . . . . . . . . . . . . . . . . . 234
10.2.3 Vector-Based Queues . . . . . . . . . . . . . . . . . . . . . 235
10.2.4 Array-Based Queues . . . . . . . . . . . . . . . . . . . . . 238
10.3 Example: Solving Mazes . . . . . . . . . . . . . . . . . . . . . . . 242
10.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
10.5 Laboratory: A Stack-Based Language . . . . . . . . . . . . . . . . 247
10.6 Laboratory: The Web Crawler . . . . . . . . . . . . . . . . . . . . 251

11 Ordered Structures 253

11.1 Comparable Objects Revisited . . . . . . . . . . . . . . . . . . . . 253
11.1.1 Example: Comparable Ratios . . . . . . . . . . . . . . . . 254
11.1.2 Example: Comparable Associations . . . . . . . . . . . . . 256
11.2 Keeping Structures Ordered . . . . . . . . . . . . . . . . . . . . . 258
11.2.1 The OrderedStructure Interface . . . . . . . . . . . . . . . 258
11.2.2 The Ordered Vector and Binary Search . . . . . . . . . . . 259
vi Contents

11.2.3 Example: Sorting Revisited . . . . . . . . . . . . . . . . . 264

11.2.4 A Comparator-based Approach . . . . . . . . . . . . . . . 265
11.2.5 The Ordered List . . . . . . . . . . . . . . . . . . . . . . . 267
11.2.6 Example: The Modified Parking Lot . . . . . . . . . . . . . 270
11.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
11.4 Laboratory: Computing the “Best Of” . . . . . . . . . . . . . . . . 275

12 Binary Trees 277

12.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
12.2 Example: Pedigree Charts . . . . . . . . . . . . . . . . . . . . . . 280
12.3 Example: Expression Trees . . . . . . . . . . . . . . . . . . . . . . 281
12.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
12.4.1 The BinaryTree Implementation . . . . . . . . . . . . . . . 284
12.5 Example: An Expert System . . . . . . . . . . . . . . . . . . . . . 287
12.6 Traversals of Binary Trees . . . . . . . . . . . . . . . . . . . . . . 290
12.6.1 Preorder Traversal . . . . . . . . . . . . . . . . . . . . . . 291
12.6.2 In-order Traversal . . . . . . . . . . . . . . . . . . . . . . 293
12.6.3 Postorder Traversal . . . . . . . . . . . . . . . . . . . . . . 295
12.6.4 Level-order Traversal . . . . . . . . . . . . . . . . . . . . . 296
12.6.5 Recursion in Iterators . . . . . . . . . . . . . . . . . . . . 297
12.7 Property-Based Methods . . . . . . . . . . . . . . . . . . . . . . . 299
12.8 Example: Huffman Compression . . . . . . . . . . . . . . . . . . 303
12.9 Example Implementation: Ahnentafel . . . . . . . . . . . . . . . . 307
12.10Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
12.11Laboratory: Playing Gardner’s Hex-a-Pawn . . . . . . . . . . . . . 313

13 Priority Queues 315

13.1 The Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
13.2 Example: Improving the Huffman Code . . . . . . . . . . . . . . 317
13.3 A Vector-Based Implementation . . . . . . . . . . . . . . . . . . . 318
13.4 A Heap Implementation . . . . . . . . . . . . . . . . . . . . . . . 319
13.4.1 Vector-Based Heaps . . . . . . . . . . . . . . . . . . . . . 320
13.4.2 Example: Heapsort . . . . . . . . . . . . . . . . . . . . . . 326
13.4.3 Skew Heaps . . . . . . . . . . . . . . . . . . . . . . . . . . 329
13.5 Example: Circuit Simulation . . . . . . . . . . . . . . . . . . . . . 333
13.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
13.7 Laboratory: Simulating Business . . . . . . . . . . . . . . . . . . 341

14 Search Trees 343

14.1 Binary Search Trees . . . . . . . . . . . . . . . . . . . . . . . . . . 343
14.2 Example: Tree Sort . . . . . . . . . . . . . . . . . . . . . . . . . . 345
14.3 Example: Associative Structures . . . . . . . . . . . . . . . . . . . 345
14.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
14.5 Splay Trees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
14.6 Splay Tree Implementation . . . . . . . . . . . . . . . . . . . . . 357
14.7 An Alternative: Red-Black Trees . . . . . . . . . . . . . . . . . . . 361
Contents vii

14.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

14.9 Laboratory: Improving the BinarySearchTree . . . . . . . . . . . . 367

15 Maps 369
15.1 Example Revisited: The Symbol Table . . . . . . . . . . . . . . . . 369
15.2 The Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
15.3 Simple Implementation: MapList . . . . . . . . . . . . . . . . . . 372
15.4 Constant Time Maps: Hash Tables . . . . . . . . . . . . . . . . . . 374
15.4.1 Open Addressing . . . . . . . . . . . . . . . . . . . . . . . 375
15.4.2 External Chaining . . . . . . . . . . . . . . . . . . . . . . 383
15.4.3 Generation of Hash Codes . . . . . . . . . . . . . . . . . . 385
15.4.4 Hash Codes for Collection Classes . . . . . . . . . . . . . . 391
15.4.5 Performance Analysis . . . . . . . . . . . . . . . . . . . . . 392
15.5 Ordered Maps and Tables . . . . . . . . . . . . . . . . . . . . . . 392
15.6 Example: Document Indexing . . . . . . . . . . . . . . . . . . . . 395
15.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
15.8 Laboratory: The Soundex Name Lookup System . . . . . . . . . . 401

16 Graphs 403
16.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
16.2 The Graph Interface . . . . . . . . . . . . . . . . . . . . . . . . . 404
16.3 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
16.3.1 Abstract Classes Reemphasized . . . . . . . . . . . . . . . 408
16.3.2 Adjacency Matrices . . . . . . . . . . . . . . . . . . . . . . 410
16.3.3 Adjacency Lists . . . . . . . . . . . . . . . . . . . . . . . . 416
16.4 Examples: Common Graph Algorithms . . . . . . . . . . . . . . . 422
16.4.1 Reachability . . . . . . . . . . . . . . . . . . . . . . . . . . 422
16.4.2 Topological Sorting . . . . . . . . . . . . . . . . . . . . . . 424
16.4.3 Transitive Closure . . . . . . . . . . . . . . . . . . . . . . 427
16.4.4 All Pairs Minimum Distance . . . . . . . . . . . . . . . . . 428
16.4.5 Greedy Algorithms . . . . . . . . . . . . . . . . . . . . . . 429
16.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
16.6 Laboratory: Converting Between Units . . . . . . . . . . . . . . . 439

A Answers 441
A.1 Solutions to Self Check Problems . . . . . . . . . . . . . . . . . . 441
A.2 Solutions to Odd-Numbered Problems . . . . . . . . . . . . . . . 451

B Beginning with Java 489

B.1 A First Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
B.2 Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
B.2.1 Primitive Types . . . . . . . . . . . . . . . . . . . . . . . . 491
B.2.2 Reference Types . . . . . . . . . . . . . . . . . . . . . . . 493
B.3 Important Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
B.3.1 The structure.ReadStream Class . . . . . . . . . . . . . . . 494
B.3.2 The java.util.Scanner Class . . . . . . . . . . . . . . . . . 495
viii Contents

B.3.3 The PrintStream Class . . . . . . . . . . . . . . . . . . . . 496

B.3.4 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
B.4 Control Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . 498
B.4.1 Conditional Statements . . . . . . . . . . . . . . . . . . . 498
B.4.2 Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
B.5 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
B.6 Inheritance and Subtyping . . . . . . . . . . . . . . . . . . . . . . 502
B.6.1 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . 502
B.6.2 Subtyping . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
B.6.3 Interfaces and Abstract Classes . . . . . . . . . . . . . . . 504
B.7 Use of the Assert Command . . . . . . . . . . . . . . . . . . . . . 506
B.8 Use of the Keyword Protected . . . . . . . . . . . . . . . . . . . 507

C Collections 511
C.1 Collection Class Features . . . . . . . . . . . . . . . . . . . . . . . 511
C.2 Parallel Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
C.3 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

D Documentation 513
D.1 Structure Package Hierarchy . . . . . . . . . . . . . . . . . . . . . 513
D.2 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515

Index 517
 for Mary,
my wife and best friend

without
the model of my mentors,
the comments of my colleagues,
the support of my students,
the friendship of my family
this book would never be

thank you!
Preface to the First Edition
“I T ’ S A WONDERFUL TIME TO BE ALIVE .” At least that’s what I’ve found myself
saying over the past couple of decades. When I first started working with com-
puters, they were resources used by a privileged (or in my case, persistent) few.
They were physically large, and logically small. They were cast from iron. The
challenge was to make these behemoths solve complex problems quickly.
Today, computers are everywhere. They are in the office and at home. They
speak to us on telephones; they zap our food in the microwave. They make
starting cars in New England a possibility. Everyone’s using them. What has
aided their introduction into society is their diminished size and cost, and in-
creased capability. The challenge is to make these behemoths solve complex
problems quickly.
Thus, while the computer and its applications have changed over time, the
challenge remains the same: How can we get the best performance out of the
current technology? The design and analysis of data structures lay the funda-
mental groundwork for a scientific understanding of what computers can do
efficiently. The motivations for data structure design work accomplished three
decades ago in assembly language at the keypunch are just as familiar to us to-
day as we practice our craft in modern languages on computers on our laps. The
focus of this material is the identification and development of relatively abstract
principles for structuring data in ways that make programs efficient in terms of
their consumption of resources, as well as efficient in terms of “programmability.”
In the past, my students have encountered this material in Pascal, Modula-2,
and, most recently, C++. None of these languages has been ideal, but each has
been met with increasing expectation. This text uses The Java Programming
Language1 —“Java”—to structure data. Java is a new and exciting language
that has received considerable public attention. At the time of this writing, for
example, Java is one of the few tools that can effectively use the Internet as a
computing resource. That particular aspect of Java is not touched on greatly
in this text. Still, Internet-driven applications in Java will need supporting data
structures. This book attempts to provide a fresh and focused approach to the
design and implementation of classic structures in a manner that meshes well
with existing Java packages. It is hoped that learning this material in Java
will improve the way working programmers craft programs, and the way future
designers craft languages.
Pedagogical Implications. This text was developed specifically for use with
CS2 in a standard Computer Science curriculum. It is succinct in its approach,
and requires, perhaps, a little more effort to read. I hope, though, that this text

1 Java is a trademark of Sun Microsystems, Incorporated.

xii Preface to the First Edition

becomes not a brief encounter with object-oriented data structure design, but a
touchstone for one’s programming future.
The material presented in this text follows the syllabus I have used for sev-
eral years at Williams. As students come to this course with experience using
Java, the outline of the text may be followed directly. Where students are new
to Java, a couple of weeks early in the semester will be necessary with a good
N
companion text to introduce the student to new concepts, and an introductory
NW

NE

Java language text or reference manual is recommended. For students that need
W

a quick introduction to Java we provide a tutorial in Appendix B. While the text

SW

SE

was designed as a whole, some may wish to eliminate less important topics
and expand upon others. Students may wish to drop (or consider!) the sec-
tion on induction (Section 5.2.2). The more nontraditional topics—including,
for example, iteration and the notions of symmetry and friction—have been in-
cluded because I believe they arm programmers with important mechanisms for
implementing and analyzing problems. In many departments the subtleties of
more advanced structures—maps (Chapter 15) and graphs (Chapter 16)—may
be considered in an algorithms course. Chapter 6, a discussion of sorting, pro-
vides very important motivating examples and also begins an early investigation
of algorithms. The chapter may be dropped when better examples are at hand,
but students may find the refinements on implementing sorting interesting.
Associated with this text is a Java package of data structures that is freely
available over the Internet for noncommercial purposes. I encourage students,
educators, and budding software engineers to download it, tear it down, build it
List up, and generally enjoy it. In particular, students of this material are encouraged
to follow along with the code online as they read. Also included is extensive
documentation gleaned from the code by javadoc. All documentation—within
the book and on the Web—includes pre- and postconditions. The motivation for
this style of commenting is provided in Chapter 2. While it’s hard to be militant
about commenting, this style of documentation provides an obvious, structured
approach to minimally documenting one’s methods that students can appreciate
and users will welcome. These resources, as well as many others, are available
from McGraw-Hill at http://www.mhhe.com/javastructures.
Three icons appear throughout the text, as they do in the margin. The
top “compass” icon highlights the statement of a principle—a statement that
nim encourages abstract discussion. The middle icon marks the first appearance of
a particular class from the structure package. Students will find these files at
McGraw-Hill, or locally, if they’ve been downloaded. The bottom icon similarly
marks the appearance of example code.
Finally, I’d like to note an unfortunate movement away from studying the
implementation of data structures, in favor of studying applications. In the
extreme this is a disappointing and, perhaps, dangerous precedent. The design
of a data structure is like the solution to a riddle: the process of developing the
answer is as important as the answer itself. The text may, however, be used as a
reference for using the structure package in other applications by selectively
avoiding the discussions of implementation.
Preface to the Second Edition
Since the first edition of Java Structures support for writing programs in Java2
has grown considerably. At that time the Java Development Toolkit consisted
of 504 classes in 23 packages3 In Java 1.2 (also called Java 2) Sun rolled out
1520 classes in 59 packages. This book is ready for Java 1.4, where the number
of classes and packages continues to grow.
Most computer scientists are convinced of the utility of Java for program-
ming in a well structured and platform independent manner. While there are
still significant arguments about important aspects of the language (for exam-
ple, support for generic types), the academic community is embracing Java, for
example, as the subject of the Computer Science Advanced Placement Exami-
nation.
It might seem somewhat perplexing to think that many aspects of the origi-
nal Java environment have been retracted (or deprecated) or reconsidered. The
developers at Sun have one purpose in mind: to make Java the indispensable
language of the current generation. As a result, documenting their progress on
the development of data structures gives us valuable insight into the process of
designing useful data structures for general purpose programming. Those stu-
dents and faculty considering a move to this second edition of Java Structures
will see first-hand some of the decisions that have been made in the interven-
ing years. During that time, for example, the Collection-based classes were
introduced, and are generally considered an improvement. Another force—
one similar to calcification—has left a trail of backwards compatible features
that are sometimes difficult to understand. For example, the Iterator class
was introduced, but the Enumeration class was not deprecated. One subject of
the first edition—the notion of Comparable classes—has been introduced into
a number of important classes including String and Integer. This is a step
forward and a reconsideration of what we have learned about that material has
lead to important improvements in the text.
Since the main purpose of the text is to demonstrate the design and behavior
of traditional data structures, we have not generally tracked the progress of
Java where it blurs the view. For example, Java 2 introduces a List interface
(we applaud) but the Vector class has been extended to include methods that
are, essentially, motivated by linked lists (we wonder). As this text points out
frequently, the purpose of an interface is often to provide reduced functionality.
If the data structure does not naturally provide the functionality required by the
application, it is probably not an effective tool for solving the problem: search
elsewhere for an effective structure.

2 The Java Programming Language is a trademark of Sun Microsystems, Incorporated.

3 David Flanagan, et al., Java in a Nutshell, O’Reilly & Associates.
xiv Preface to the Second Edition

As of this writing, more than 100, 000 individuals have searched for and
downloaded the structure package. To facilitate using the comprehensive set
of classes with the Java 2 environment, we have provided a number of features
that support the use of the structure package in more concrete applications.
Please see Appendix C.
Also new to this edition are more than 200 new problems, several dozen
exercises, and over a dozen labs we regularly use at Williams.
Acknowledgments. Several students, instructors, and classes have helped to
shape this edition of Java Structures. Parth Doshi and Alex Glenday—diligent
Williams students—pointed out a large number of typos and stretches of logic.
Kim Bruce, Andrea Danyluk, Jay Sachs, and Jim Teresco have taught this course
at Williams over the past few years, and have provided useful feedback. I tip
my hat to Bill Lenhart, a good friend and advisor, who has helped improve this
text in subtle ways. To Sean Sandys I am indebted for showing me new ways to
teach new minds.
The various reviewers have made, collectively, hundreds of pages of com-
ments that have been incorporated (as much as possible) into this edition:
Eleanor Hare and David Jacobs (Clemson University), Ram Athavale (North
Carolina State University), Yannick Daoudi (McGill University), Walter Daugh-
erty (Texas A&M University), Subodh Kumar (Johns Hopkins University), Toshimi
Minoura (Oregon State University), Carolyn Schauble (Colorado State Univer-
sity), Val Tannen (University of Pennsylvania), Frank Tompa (University of Wa-
terloo), Richard Wiener (University of Colorado at Colorado Springs), Cynthia
Brown Zickos (University of Mississippi), and my good friend Robbie Moll (Uni-
versity of Massachusetts). Deborah Trytten (University of Oklahoma) has re-
viewed both editions! Still, until expert authoring systems are engineered, au-
thors will remain human. Any mistakes left behind or introduced are purely
those of the author.
The editors and staff at McGraw-Hill–Kelly Lowery, Melinda Dougharty, John
Wannemacher, and Joyce Berendes–have attempted the impossible: to keep me
within a deadline. David Hash, Phil Meek, and Jodi Banowetz are responsible
for the look and feel of things. I am especially indebted to Lucy Mullins, Judy
Gantenbein, and Patti Evers whose red pens have often shown me a better way.
Betsy Jones, publisher and advocate, has seen it all and yet kept the faith:
thanks.
Be aware, though: long after these pages are found to be useless folly, my
best work will be recognized in my children, Kate, Megan, and Ryan. None
of these projects, of course, would be possible without the support of my best
friend, my north star, and my partner, Mary.

Enjoy!

Duane A. Bailey
Williamstown, May 2002
 √
Preface to the 7 Edition
In your hand is a special edition of Java Structures designed for use with two
semesters of Williams’ course on data structures, Computer Science 136. This
version is only marginally different than the preceding edition, but is positioned
to make use of Java 5 (the trademarked name for version 1.5 of the JDK).
Because Java 5 may not be available (yet) on the platform you use, most of the
code available in this book will run on older JDK’s. The one feature that would
not be available is Java’s new Scanner class from the java.util package; an
alternative is my ReadStream class, which is lightly documented in Section B.3.1
on page 494. It is a feature of the structure package soon to be removed.
In making this book available in this paperbound format, my hope is that
you find it a more inviting place to write notes: additions, subtractions, and
updates that you’re likely to have discussed in class. Sometimes you’ll identify
improvements, and I hope you’ll pass those along to me. In any case, you can
download the software (as hundreds of thousands have done in the past) and
modify it as you desire.
On occasion, I will release new sections you can incorporate into your text,
including a discussion of how the structure package can make use of generic
types.
I have spent a considerable amount of time designing the structure pack-
age. The first structures were available 8 years ago when Java was still in its
infancy. Many of the structures have since been incorporated (directly or indi-
rectly) into Sun’s own JDK. (Yes, we’ve sold a few books in California.) Still, I
feel the merit of my approach is a slimness that, in the end, you will not find
surprising.
Meanwhile, for those of you keeping track, the following table (adapted
from the 121 cubic inch, 3 pound 6 ounce, Fifth edition of David Flanagan’s
essential Java in a Nutshell) demonstrates the growth of Java’s support:

JDK Packages Classes Features

1.0 8 212 First public version
1.1 23 504 Inner classes
1.2 (Java 2) 59 1520 Collection classes
1.3 76 1842 A “maintenance” release.
1.4 135 2991 Improvments, including assert
1.5 (Java 5) 166 3562 Generics, autoboxing, and “varargs.”

Seeing this reminds me of the comment made by Niklaus Wirth, designer of

Pascal and the first two releases of Modula. After the design team briefed him
on the slew of new features to be incorporated into Modula 3, he parried: “But,
what features have you removed?” A timeless question.
 √
xvi Preface to the 7 Edition

Acknowledgments. This book was primarily written for students of Williams

College. The process of publishing and reviewing a text tends to move the focus
off campus and toward the bottom line. The Route 7 edition4 —somewhere
between editions 2 and 3—is an initial attempt to bring that focus back to those
students who made it all possible.
For nearly a decade, students at many institutions have played an important
role in shaping these resources. In this edition, I’m especially indebted to Katie
Creel ’10 (Williams) and Brian Bargh ’07 (Messiah): thanks!
Many colleagues, including Steve Freund ’95 (Stanford, now at Williams),
Jim Teresco ’92 (Union, now at Mount Holyoke), and especially Gene Chase ’65
(M.I.T., now at Messiah) continue to nudge this text in a better direction. Brent
Heeringa ’99 (Morris, now at Williams) showers all around him with youthful
enthusiasm.
And a most special thanks to Bill Mueller for the shot heard around the
world—the game-winning run that showed all things were possible. Called by
Joe Castiglione ’68 (Colgate, now at Fenway):
“Three-and-one to Mueller. One out, nineth inning. 10-9 Yankees,
runner at first. Here’s the pitch...swing and a High Drive Deep to
Right...Back Goes Sheffield to the Bullpen...AND IT IS GONE!...AND
THE RED SOX HAVE WON IT!...ON A WALKOFF TWO RUN HOMER
BY BILL MUELLER OFF MARIANO RIVERA! CAN YOU BELIEVE IT?!”
Have I been a Red Sox fan all my life? Not yet.
Finally, nothing would be possible without my running mate, my Sox buddy,
and my best friend, Mary.

Cheers!

Duane A. Bailey ’82 (Amherst, now at Williams)

Williamstown, September 2007

4 Route 7 is a scenic byway through the Berkshires and Green Mountains that eddies a bit as it
passes through Williamstown and Middlebury.
Chapter 0
Introduction

Concepts: This is an important notice.

. Approaches to this material Please have it translated.
. Principles —The Phone Company

Y OUR MOTHER probably provided you with constructive toys, like blocks or
Tinkertoys1 or Lego bricks. These toys are educational: they teach us to think
spatially and to build increasingly complex structures. You develop modules
that can be stuck together and rules that guide the building process.
If you are reading this book, you probably enjoyed playing with construc-
tive toys. You consider writing programs an artistic process. You have grown
from playing with blocks to writing programs. The same guidelines for building
structures apply to writing programs, save one thing: there is, seemingly, no
limit to the complexity of the programs you can write. I lie.
Well, almost. When writing large programs, the data structures that main-
tain the data in your program govern the space and time consumed by your
running program. In addition, large programs take time to write. Using differ-
ent structures can actually have an impact on how long it takes to write your
program. Choosing the wrong structures can cause your program to run poorly
or be difficult or impossible to implement effectively.
Thus, part of the program-writing process is choosing between different
structures. Ideally you arrive at solutions by analyzing and comparing their
various merits. This book focuses on the creation and analysis of traditional
data structures in a modern programming environment, The Java Programming
Language, or Java for short.

0.1 Read Me
As might be expected, each chapter is dedicated to a specific topic. Many of the
topics are concerned with specific data structures. The structures we will inves-
tigate are abstracted from working implementations in Java that are available
to you if you have access to the Internet.2 Other topics concern the “tools of the

1 All trademarks are recognized.

2 For more information, see http://www.cs.williams.edu/JavaStructures.
2 Introduction

trade.” Some are mathematical and others are philosophical, but all consider
the process of programming well.
The topics we cover are not all-inclusive. Some useful structures have been
left out. Instead, we will opt to learn the principles of programming data struc-
tures, so that, down the road, you can design newer and better structures your-
self.
Perhaps the most important aspect of this book is the set of problems at the
end of each section. All are important for you to consider. For some problems
I have attempted to place a reasonable hint or answer in the back of the book.
Why should you do problems? Practice makes perfect. I could show you how to
Unicycles: the ride a unicycle, but if you never practiced, you would never learn. If you study
ultimate riding and understand these problems, you will find your design and analytical skills
structure. are improved. As for your mother, she’ll be proud of you.
Sometimes we will introduce problems in the middle of the running text—
these problems do not have answers (sometimes they are repeated as formal
problems in the back of the chapter, where they do have answers)—they should
be thought about carefully as you are reading along. You may find it useful to
have a pencil and paper handy to help you “think” about these problems on the
fly.
Exercise 0.1 Call3 your Mom and tell her you’re completing your first exercise. If
you don’t have a phone handy, drop her a postcard. Ask her to verify that she’s
proud of you.
This text is brief and to the point. Most of us are interested in experimenting.
We will save as much time as possible for solving problems, perusing code, and
practicing writing programs. As you read through each of the chapters, you
might find it useful to read through the source code online. As we first consider
the text of files online, the file name will appear in the margin, as you see here.
Structure The top icon refers to files in the structure package, while the bottom icon
refers to files supporting examples.
One more point—this book, like most projects, is an ongoing effort, and
the latest thoughts are unlikely to have made it to the printed page. If you
are in doubt, turn to the website for the latest comments. You will also find
online documentation for each of the structures, generated from the code using
Example javadoc. It is best to read the online version of the documentation for the
most up-to-date details, as well as the documentation of several structures not
formally presented within this text.

0.2 He Can’t Say That, Can He?

Sure! Throughout this book are little political comments. These remarks may
seem trivial at first blush. Skip them! If, however, you are interested in ways

3 Don’t e-mail her. Call her. Computers aren’t everything, and they’re a poor medium for a mother’s
pride.
0.2 He Can’t Say That, Can He? 3

to improve your skills as a programmer and a computer scientist, I invite you

to read on. Sometimes these comments are so important that they appear as
principles: N

NW

NE
W
Principle 1 The principled programmer understands a principle well enough to

E
SW

SE
form an opinion about it. S

Self Check Problems

Solutions to these problems begin on page 441.
0.1 Where are the answers for “self check” problems found?
0.2 What are features of large programs?
0.3 Should you read the entire text?
0.4 Are principles statements of truth?

Problems
Solutions to the odd-numbered problems begin on page 451.
0.1 All odd problems have answers. Where do you find answers to prob-
lems? (Hint: See page 451.)
0.2 You are an experienced programmer. What five serious pieces of advice
would you give a new programmer?
0.3 Surf to the website associated with this text and review the resources
available to you.
0.4 Which of the following structures are described in this text (see Append-
ix D): BinarySearchTree, BinaryTree, BitSet, Map, Hashtable, List?
0.5 Surf to http://www.javasoft.com and review the Java resources avail-
able from Sun, the developers of Java.
0.6 Review documentation for Sun’s java.util package. (See the Core
API Documentation at http://www.javasoft.com.) Which of the following
data structures are available in this package: BinarySearchTree, BinaryTree,
BitSet, Dictionary, Hashtable, List?
0.7 Check your local library or bookstore for Java reference texts.
0.8 If you haven’t done so already, learn how to use your local Java pro-
gramming environment by writing a Java application to write a line of text.
(Hint: Read Appendix B.)
0.9 Find the local documentation for the structure package. If none is to
be found, remember that the same documentation is available over the Internet
from http://www.cs.williams.edu/JavaStructures.
0.10 Find the examples electronically distributed with the structure pack-
age. Many of these examples are discussed later in this text.
Chapter 1

The Object-Oriented Method

Concepts: I will pick up the hook.

. Data structures You will see something new.
Two things. And I call them
. Abstract data types
Thing One and Thing Two.
. Objects
These Things will not bite you.
. Classes They want to have fun.
. Interfaces —Theodor Seuss Geisel

C OMPUTER SCIENCE DOES NOT SUFFER the great history of many other disci-
plines. While other subjects have well-founded paradigms and methods, com-
puter science still struggles with one important question: What is the best method
to write programs? To date, we have no best answer. The focus of language de-
signers is to develop programming languages that are simple to use but provide
the power to accurately and efficiently describe the details of large programs
and applications. The development of Java is one such effort.
Throughout this text we focus on developing data structures using object-
oriented programming. Using this paradigm the programmer spends time devel- OOP:
oping templates for structures called classes. The templates are then used to Object-oriented
construct instances or objects. A majority of the statements in object-oriented programming.
programs involve sending messages to objects to have them report or change
their state. Running a program involves, then, the construction and coordina-
tion of objects. In this way languages like Java are object-oriented.
In all but the smallest programming projects, abstraction is a useful tool
for writing working programs. In programming languages including Pascal,
Scheme, and C, the details of a program’s implementation are hidden away in
its procedures or functions. This approach involves procedural abstraction. In
object-oriented programming the details of the implementation of data struc-
tures are hidden away within its objects. This approach involves data abstrac-
tion. Many modern programming languages use object orientation to support
basic abstractions of data. We review the details of data abstraction and the
design of formal interfaces for objects in this chapter.
6 The Object-Oriented Method

1.1 Data Abstraction and Encapsulation

If you purchase a donut from Morningside Bakery in Pittsfield, Massachusetts,
you can identify it as a donut without knowing its ingredients. Donuts are
circular, breadlike, and sweet. The particular ingredients in a donut are of little
concern to you. Of course, Morningside is free to switch from one sweetener to
another, as long as the taste is preserved.1 The donut’s ingredients list and its
construction are details that probably do not interest you.
Likewise, it is often unimportant to know how data structures are imple-
mented in order to appreciate their use. For example, most of us are familiar
with the workings or semantics of strings or arrays, but, if pressed, we might
find it difficult to describe their mechanics: Do all consecutive locations in the
array appear close together in memory in your computer, or are they far apart?
The answer is: it is unimportant. As long as the array behaves like an array or
the string behaves like a string we are happy. The less one knows about how
arrays or strings are implemented, the less one becomes dependent on a partic-
Macintosh and ular implementation. Another way to think about this abstractly is that the data
UNIX store structure lives up to an implicit “contract”: a string is an ordered list of charac-
strings ters, or elements of an array may be accessed in any order. The implementor of
differently. the data structure is free to construct it in any reasonable way, as long as all the
terms of the contract are met. Since different implementors are in the habit of
making very different implementation decisions, anything that helps to hide the
implementation details—any means of using abstraction—serves to make the
world a better place to program.
When used correctly, object-oriented programming allows the programmer
to separate the details that are important to the user from the details that are
only important to the implementation. Later in this book we shall consider very
general behavior of data structures; for example, in Section 10.1 we will study
structures that allow the user only to remove the most recently added item.
Such behavior is inherent to our most abstract understanding of how the data
structure works. We can appreciate the unique behavior of this structure even
though we haven’t yet discussed how these structures might be implemented.
Those abstract details that are important to the user of the structure—including
abstract semantics of the methods—make up its contract or interface. The in-
terface describes the abstract behavior of the structure. Most of us would agree
that while strings and arrays are very similar structures, they behave differently:
you can shrink or expand a string, while you cannot directly do the same with
an array; you can print a string directly, while printing an array involves explic-
itly printing each of its elements. These distinctions suggest they have distinct
abstract behaviors; there are distinctions in the design of their interfaces.
The unimportant details hidden from the user are part of what makes up
the implementation. We might decide (see Figure 1.1) that a string is to be

1 Apple cider is often used to flavor donuts in New England, but that decision decidedly changes

the flavor of the donut for the better. Some of the best apple cider donuts can be found at Atkin’s
apple farm in Amherst, Massachusetts.
1.2 The Object Model 7

Counted string

Data L I C K E T Y S P L I T !
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 n

Count 13

Terminated string

E
Data L I C K E T Y S P L I T ! O
S
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 n

Figure 1.1 Two methods of implementing a string. A counted string explicitly records
its length. The terminated string’s length is determined by an end-of-string mark.

constructed from a large array of characters with an attendant character count.

Alternatively, we might specify the length implicitly by terminating the string
with a special end-of-string mark that is not used for any other purpose. Both
of these approaches are perfectly satisfactory, but there are trade-offs. The first
implementation (called a counted string) has its length stored explicitly, while
the length of the second implementation (called a terminated string) is implied.
It takes longer to determine the length of a terminated string because we have to
search for the end-of-string mark. On the other hand, the size of a terminated
string is limited only by the amount of available memory, while the longest
counted string is determined by the range of integers that can be stored in its
length field (often this is only several hundred characters). If implementors can
hide these details, users do not have to be distracted from their own important
design work. As applications mature, a fixed interface to underlying objects
allows alternative implementations of the object to be considered.
Data abstraction in languages like Java allows a structure to take responsibil-
ity for its own state. The structure knows how to maintain its own state without
bothering the programmer. For example, if two strings have to be concatenated
into a single string structure, a request might have to be made for a new allot-
ment of memory. Thankfully, because strings know how to perform operations
on themselves, the user doesn’t have to worry about managing memory.

1.2 The Object Model

To facilitate the construction of well-designed objects, it is useful to have a de-
sign method in mind. As alluded to earlier, we will often visualize the data for
our program as being managed by its objects. Each object manages its own data
that determine its state. A point on a screen, for example, has two coordinates.
8 The Object-Oriented Method

A medical record maintains a name, a list of dependents, a medical history, and

a reference to an insurance company. A strand of genetic material has a se-
quence of base pairs. To maintain a consistent state we imagine the program
manipulates the data within its objects only through messages or method calls
to the objects. A string might receive a message “tell me your length,” while
a medical record might receive a “change insurance” message. The string mes-
sage simply accesses information, while the medical record method may involve
changing several pieces of information in this and other objects in a consistent
manner. If we directly modify the reference to the insurance company, we may
forget to modify similar references in each of the dependents. For large applica-
tions with complex data structures, it can be extremely difficult to remember to
coordinate all the operations that are necessary to move a single complex object
from one consistent state to another. We opt, instead, to have the designer of
the data structure provide us a method for carefully moving between states; this
method is activated in response to a high-level message sent to the object.
This text, then, focuses on two important topics: (1) how we implement and
evaluate objects with methods that are logically complex and (2) how we might
use the objects we create. These objects typically represent data structures, our
primary interest. Occasionally we will develop control structures—structures
whose purpose is to control the manipulation of other objects. Control struc-
tures are an important concept and are described in detail in Chapter 8.

1.3 Object-Oriented Terminology

In Java, data abstraction is accomplished through encapsulation of data in an
object—an instance of a class. Like a record in other languages, an object has
fields. Unlike records, objects also contain methods. Fields and methods of an
object may be declared public, which means that they are visible to entities
outside the class, or protected, in which case they may only be accessed by
code within methods of the class.2 A typical class declaration is demonstrated
by the following simple class that keeps track of the ratio of two integer values:

public class Ratio

{
protected int numerator; // numerator of ratio
Ratio protected int denominator; // denominator of ratio

public Ratio(int top, int bottom)

// pre: bottom != 0
// post: constructs a ratio equivalent to top::bottom
{
numerator = top;
denominator = bottom;
reduce();

2 This is not quite the truth. For a discussion of the facts, see Appendix B.8.
1.3 Object-Oriented Terminology 9

public int getNumerator()

// post: return the numerator of the fraction
{
return numerator;
}

public int getDenominator()

// post: return the denominator of the fraction
{
return denominator;
}

public double getValue()

// post: return the double equivalent of the ratio
{
return (double)numerator/(double)denominator;
}

public Ratio add(Ratio other)

// pre: other is nonnull
// post: return new fraction--the sum of this and other
{
return new Ratio(this.numerator*other.denominator+
this.denominator*other.numerator,
this.denominator*other.denominator);
}

protected void reduce()

// post: numerator and denominator are set so that
// the greatest common divisor of the numerator and denominator is 1
{
int divisor = gcd(numerator,denominator);
if (denominator < 0) divisor = -divisor;
numerator /= divisor;
denominator /= divisor;
}

protected static int gcd(int a, int b)

// post: computes the greatest integer value that divides a and b
{
if (a < 0) return gcd(-a,b);
if (a == 0) {
if (b == 0) return 1;
else return b;
}
if (b < a) return gcd(b,a);
return gcd(b%a,a);
}
10 The Object-Oriented Method

public String toString()

// post: returns a string that represents this fraction.
{
return getNumerator()+"/"+getDenominator();
}
}

First, a Ratio object maintains the numerator and denominator as protected

ints that are not directly modifiable by the user. The Ratio method is a con-
structor: a method whose name is the same as that of the class. (The formal
comments at the top of methods are pre- and postconditions; we discuss these
in detail in Chapter 2.) The constructor is called whenever a new Ratio object is
formed. Constructors initialize all the fields of the associated object, placing the
object into a predictable and consistent initial state. We declare the construc-
tors for a class public. To construct a new Ratio object, users will have to call
these methods. The value method returns a double that represents the ratio,
while the getNumerator and getDenominator methods fetch the current values
of the numerator and denominator of the fraction. The add method is useful for
adding one Ratio to another; the result is a newly constructed Ratio object.
Finally, the toString method generates the preferred printable representation
of the object; we have chosen to represent it in fractional form.
Two methods, reduce and gcd, are utility methods. The gcd method com-
putes the greatest common divisor of two values using Euclid’s method, one of
the oldest numerical algorithms used today. It is used by the reduce method to
reduce the numerator and denominator to lowest terms by removing any com-
mon factors. Both are declared protected because computing the reduction is
not a necessary (or obvious) operation to be performed on ratios of integers;
it’s part of the implementation. The gcd method is declared static because
the algorithm can be used at any time—its utility is independent of the number
of Ratio objects that exist in our program. The reduce method, on the other
hand, works only with a Ratio object.

Exercise 1.1 Nearly everything can be improved. Are there improvements that
might be made to the gcd method? Can you write the method iteratively? Is
iteration an improvement?

As with the Ratio class, data fields are usually declared protected. To ma-
nipulate protected fields the user must invoke public methods. The following
example demonstrates the manipulation of the Ratio class:

public static void main(String[] args)

{
Ratio r = new Ratio(1,1); // r == 1.0
r = new Ratio(1,2); // r == 0.5
r.add(new Ratio(1,3)); // sum computed, but r still 0.5
r = r.add(new Ratio(2,8)); // r == 0.75
System.out.println(r.getValue()); // 0.75 printed
1.4 A Special-Purpose Class: A Bank Account 11

System.out.println(r.toString()); // calls toString()

System.out.println(r); // calls toString()
}

To understand the merit of this technique of class design, we might draw an

analogy between a well-designed object and a lightbulb for your back porch.
The protected fields and methods of an object are analogous to the internal de-
sign of the bulb. The observable features, including the voltage and the size of
the socket, are provided without giving any details about the implementation
of the object. If light socket manufacturers depended on a particular imple-
mentation of lightbulbs—for example the socket only supported bright xenon
bulbs—it might ultimately restrict the variety of suppliers of lightbulbs in the
future. Likewise, manufacturers of lightbulbs should be able to have a cer-
tain freedom in their implementation: as long as they only draw current in an
agreed-upon way and as long as their bulb fits the socket, they should be free
to use whatever design they want. Today, most lamps take either incandescent
or fluorescent bulbs.
In the same way that fields are encapsulated by a class, classes may be encap-
sulated by a package. A package is a collection of related classes that implement
some set of structures with a common theme. The classes of this text, for ex-
ample, are members of the structure package. In the same way that there are
users of classes, there are users of packages, and much of the analogy holds. In
particular, classes may be declared public, in which case they may be used by
anyone who imports the package into their program. If a class is not public, it
is automatically considered protected. These protected classes may only be
constructed and used by other classes within the same package.

1.4 A Special-Purpose Class: A Bank Account

We now look at the detailed construction of a simplistic class: a BankAccount.
Many times, it is necessary to provide a tag associated with an instance of a
data structure. You might imagine that your bank balance is kept in a database
at your bank. When you get money for a trip through the Berkshires, you swipe
your card through an automated teller bringing up your account. Your account Automated
number, presumably, is unique to your account. Nothing about you or your teller: a robotic
banking history is actually stored in your account number. Instead, that num- palm reader.
ber is used to find the record linked to your account: the bank searches for a
structure associated with the number you provide. Thus a BankAccount is a sim-
ple, but important, data structure. It has an account (an identifier that never
changes) and a balance (that potentially does change). The public methods of
such a structure are as follows:

public class BankAccount

{
public BankAccount(String acc, double bal)
// pre: account is a string identifying the bank account BankAccount
12 The Object-Oriented Method

// balance is the starting balance

// post: constructs a bank account with desired balance

public boolean equals(Object other)

// pre: other is a valid bank account
// post: returns true if this bank account is the same as other

public String getAccount()

// post: returns the bank account number of this account

public double getBalance()

// post: returns the balance of this bank account

public void deposit(double amount)

// post: deposit money in the bank account

public void withdraw(double amount)

// pre: there are sufficient funds in the account
// post: withdraw money from the bank account
}

The substance of these methods has purposefully been removed because, again,
it is unimportant for us to know exactly how a BankAccount is implemented.
We have ways to construct and compare BankAccounts, as well as ways to read
the account number or balance, or update the balance.
Let’s look at the implementation of these methods, individually. To build a
new bank account, you must use the new operator to call the constructor with
two parameters. The account number provided never changes over the life of
the BankAccount—if it were necessary to change the value of the account num-
ber, a new BankAccount would have to be made, and the balance would have to
be transferred from one to the other. The constructor plays the important role
of performing the one-time initialization of the account number field. Here is
the code for a BankAccount constructor:

protected String account; // the account number

protected double balance; // the balance associated with account

public BankAccount(String acc, double bal)

// pre: account is a string identifying the bank account
// balance is the starting balance
// post: constructs a bank account with desired balance
{
account = acc;
balance = bal;
}

Two fields—account and balance—of the BankAccount object are responsible

for maintaining the object’s state. The account keeps track of the account num-
ber, while the balance field maintains the balance.
1.4 A Special-Purpose Class: A Bank Account 13

Since account numbers are unique to BankAccounts, to check to see if two

accounts are “the same,” we need only compare the account fields. Here’s the
code:

public boolean equals(Object other)

// pre: other is a valid bank account
// post: returns true if this bank account is the same as other
{
BankAccount that = (BankAccount)other;
// two accounts are the same if account numbers are the same
return this.account.equals(that.account);
}

Notice that the BankAccount equals method calls the equals method of the key,
a String. Both BankAccount and String are nonprimitive types, or examples
of Objects. Every object in Java has an equals method. If you don’t explicitly
provide one, the system will write one for you. Generally speaking, one should
assume that the automatically written or default equals method is of little use.
This notion of “equality” of objects is often based on the complexities of our
abstraction; its design must be considered carefully.
One can ask the BankAccount about various aspects of its state by calling its
getAccount or getBalance methods:
public String getAccount()
// post: returns the bank account number of this account
{
return account;
}

public double getBalance()

// post: returns the balance of this bank account
{
return balance;
}

These methods do little more than pass along the information found in the
account and balance fields, respectively. We call such methods accessors. In a
different implementation of the BankAccount, the balance would not have to be
explicitly stored—the value might be, for example, the difference between two
fields, deposits and drafts. Given the interface, it is not much of a concern to
the user which implementation is used.
We provide two more methods, deposit and withdraw, that explicitly mod-
ify the current balance. These are mutator methods:

public void deposit(double amount)

// post: deposit money in the bank account
{
balance = balance + amount;
}
14 The Object-Oriented Method

public void withdraw(double amount)

// pre: there are sufficient funds in the account
// post: withdraw money from the bank account
{
balance = balance - amount;
}

Because we would like to change the balance of the account, it is important to

have a method that allows us to modify it. On the other hand, we purposefully
don’t have a setAccount method because we do not want the account number
to be changed without a considerable amount of work (work that, by the way,
models reality).
Here is a simple application that determines whether it is better to deposit
$100 in an account that bears 5 percent interest for 10 years, or to deposit $100
in an account that bears 2 21 percent interest for 20 years. It makes use of the
BankAccount object just outlined:

public static void main(String[] args)

{
// Question: is it better to invest $100 over 10 years at 5%
// or to invest $100 over 20 years at 2.5% interest?
BankAccount jd = new BankAccount("Jain Dough",100.00);
BankAccount js = new BankAccount("Jon Smythe",100.00);

for (int years = 0; years < 10; years++)

{
jd.deposit(jd.getBalance() * 0.05);
}
for (int years = 0; years < 20; years++)
{
js.deposit(js.getBalance() * 0.025);
}
System.out.println("Jain invests $100 over 10 years at 5%.");
System.out.println("After 10 years " + jd.getAccount() +
" has $" + jd.getBalance());
System.out.println("Jon invests $100 over 20 years at 2.5%.");
System.out.println("After 20 years " + js.getAccount() +
" has $" + js.getBalance());
}

Exercise 1.2 Which method of investment would you pick?

1.5 A General-Purpose Class: An Association

At least Dr. The following small application implements a Pig Latin translator based on a
Seuss started dictionary of nine words. The code makes use of an array of Associations,
with 50 words! each of which establishes a relation between an English word and its Pig Latin
1.5 A General-Purpose Class: An Association 15

translation. For each string passed as the argument to the main method, the
dictionary is searched to determine the appropriate translation.

public class atinLay {

// a pig latin translator for nine words
public static void main(String args[])
{ atinlay
// build and fill out an array of nine translations
Association dict[] = new Association[9];
dict[0] = new Association("a","aay");
dict[1] = new Association("bad","adbay");
dict[2] = new Association("had","adhay");
dict[3] = new Association("dad","adday");
dict[4] = new Association("day","ayday");
dict[5] = new Association("hop","ophay");
dict[6] = new Association("on","onay");
dict[7] = new Association("pop","oppay");
dict[8] = new Association("sad","adsay");

for (int argn = 0; argn < args.length; argn++)

{ // for each argument
for (int dictn = 0; dictn < dict.length; dictn++)
{ // check each dictionary entry
if (dict[dictn].getKey().equals(args[argn]))
System.out.println(dict[dictn].getValue());
}
}
}
}

When this application is run with the arguments hop on pop, the results are

ophay
onay
oppay

While this application may seem rather trivial, it is easy to imagine a large-scale
application with similar needs.3
We now consider the design of the Association. Notice that while the type
of data maintained is different, the purpose of the Association is very similar
to that of the BankAccount class we discussed in Section 1.4. An Association
is a key-value pair such that the key cannot be modified. Here is the interface
for the Association class:

import java.util.Map;

3 Pig Latin has played an important role in undermining court-ordered restrictions placed on music Association
piracy. When Napster—the rebel music trading firm—put in checks to recognize copyrighted music
by title, traders used Pig Latin translators to foil the recognition software!
16 The Object-Oriented Method

public class Association implements Map.Entry

{
public Association(Object key, Object value)
// pre: key is non-null
// post: constructs a key-value pair

public Association(Object key)

// pre: key is non-null
// post: constructs a key-value pair; value is null

public boolean equals(Object other)

// pre: other is non-null Association
// post: returns true iff the keys are equal

public Object getValue()

// post: returns value from association

public Object getKey()

// post: returns key from association

public Object setValue(Object value)

// post: sets association's value to value
}

For the moment, we will ignore the references to Map and Map.entry; these will
be explained later, in Chapter 15. What distinguishes an Association from a
more specialized class, like BankAccount, is that the fields of an Association
are type Object. The use of the word Object in the definition of an Association
makes the definition very general: any value that is of type Object—any non-
primitive data type in Java—can be used for the key and value fields.
Unlike the BankAccount class, this class has two different constructors:
protected Object theKey; // the key of the key-value pair
protected Object theValue; // the value of the key-value pair

public Association(Object key, Object value)

// pre: key is non-null
// post: constructs a key-value pair
{
Assert.pre(key != null, "Key must not be null.");
theKey = key;
theValue = value;
}

public Association(Object key)

// pre: key is non-null
// post: constructs a key-value pair; value is null
{
this(key,null);
}
1.5 A General-Purpose Class: An Association 17

The first constructor—the constructor distinguished by having two parame-

ters—allows the user to construct a new Association by initializing both fields.
On occasion, however, we may wish to have an Association whose key field is
set, but whose value field is left referencing nothing. (An example might be a
medical record: initially the medical history is incomplete, perhaps waiting to
be forwarded from a previous physician.) For this purpose, we provide a sin-
gle parameter constructor that sets the value field to null. Note that we use
this(key,null) as the body. The one-parameter constructor calls this object’s
two-parameter constructor with null as the second parameter. We write the
constructors in this dependent manner so that if the underlying implementation
of the Association had to be changed, only the two-parameter method would
have to be updated. It also reduces the complexity of the code and saves your
fingerprints!
Now, given a particular Association, it is useful to be able to retrieve the
key or value. Since the implementation is hidden, no one outside the class is
able to see it. Users must depend on the accessor methods to observe the data.

public Object getValue()

// post: returns value from association
{
return theValue;
}

public Object getKey()

// post: returns key from association
{
return theKey;
}

When necessary, the method setValue can be used to change the value associ-
ated with the key. Thus, the setValue method simply takes its parameter and
assigns it to the value field:

public Object setValue(Object value)

// post: sets association's value to value
{
Object oldValue = theValue;
theValue = value;
return oldValue;
}

There are other methods that are made available to users of the Association
class, but we will not discuss the details of that code until later. Some of the
methods are required, some are useful, and some are just nice to have around.
While the code may look complicated, we take the time to implement it cor- N
NW

NE

rectly, so that we will not have to reimplement it in the future.

W

E
SW

SE

S
Principle 2 Free the future: reuse code.
18 The Object-Oriented Method

It is difficult to fight the temptation to design data structures from scratch. We

shall see, however, that many of the more complex structures would be very
difficult to construct if we could not base our implementations on the results of
previous work.

1.6 Sketching an Example: A Word List

Suppose we’re interested in building a game of Hangman. The computer selects
random words and we try to guess them. Over several games, the computer
should pick a variety of words and, as each word is used, it should be removed
from the word list. Using an object-oriented approach, we’ll determine the
essential features of a WordList, the Java object that maintains our list of words.
Our approach to designing the data structures has the following five informal
steps:

1. Identify the types of operations you expect to perform on your object.

What operations access your object only by reading its data? What opera-
tions might modify or mutate your objects?

2. Identify, given your operations, those data that support the state of your
object. Information about an object’s state is carried within the object
between operations that modify the state. Since there may be many ways
to encode the state of your object, your description of the state may be
very general.

3. Identify any rules of consistency. In the Ratio class, for example, it would
not be good to have a zero denominator. Also, the numerator and denom-
inator should be in lowest terms.

4. Determine the number and form of the constructors. Constructors are

synthetic: their sole responsibility is to get a new object into a good initial
and consistent state. Don’t forget to consider the best state for an object
constructed using the parameterless default constructor.

5. Identify the types and kinds of information that, though declared pro-
tected, can efficiently provide the information needed by the public
methods. Important choices about the internals of a data structure are
usually made at this time. Sometimes, competing approaches are devel-
oped until a comparative evaluation can be made. That is the subject of
much of this book.

The operations necessary to support a list of words can be sketched out

easily, even if we don’t know the intimate details of constructing the Hangman
game itself. Once we see how the data structure is used, we have a handle on
the design of the interface. Thinking about the overall design of Hangman, we
can identify the following general use of the WordList object:
1.6 Sketching an Example: A Word List 19

WordList list; // declaration

String targetWord;

list = new WordList(10); // construction WordList

list.add("disambiguate"); // is this a word? how about ambiguate?
list.add("inputted"); // really? what verbification!
list.add("subbookkeeper"); // now that's coollooking!
while (!list.isEmpty()) // game loop
{
targetWord = list.selectAny(); // selection
// ...play the game using target word...
list.remove(targetWord); // update
}

Let’s consider these lines. One of the first lines (labeled declaration) de-
clares a reference to a WordList. For a reference to refer to an object, the object
must be constructed. We require, therefore, a constructor for a WordList. The
construction line allocates an initially empty list of words ultimately contain-
ing as many as 10 words. We provide an upper limit on the number of words
that are potentially stored in the list. (We’ll see later that providing such infor-
mation can be useful in designing efficient data structures.) On the next three
lines, three (dubious) words are added to the list.
The while loop accomplishes the task of playing Hangman with the user.
This is possible as long as the list of words is not empty. We use the isEmpty
method to test this fact. At the beginning of each round of Hangman, a random
word is selected (selectAny), setting the targetWord reference. To make things
interesting, we presume that the selectAny method selects a random word each
time. Once the round is finished, we use the remove method to remove the word
from the word list, eliminating it as a choice in future rounds.
There are insights here. First, we have said very little about the Hangman
game other than its interaction with our rather abstract list of words. The details
of the screen’s appearance, for example, do not play much of a role in under-
standing how the WordList structure works. We knew that a list was necessary
for our program, and we considered the program from the point of view of the
object. Second, we don’t really know how the WordList is implemented. The
words may be stored in an array, or in a file on disk, or they may use some tech-
nology that we don’t currently understand. It is only important that we have
faith that the structure can be implemented. We have sketched out the method
headers, or signatures, of the WordList interface, and we have faith that an im-
plementation supporting the interface can be built. Finally we note that what
we have written is not a complete program. Still, from the viewpoint of the
WordList structure, there are few details of the interface that are in question.
A reasoned individual should be able to look at this design and say “this will
work—provided it is implemented correctly.” If a reviewer of the code were to
ask a question about how the structure works, it would lead to a refinement of
our understanding of the interface.
We have, then, the following required interface for the WordList class:
20 The Object-Oriented Method

public class WordList

{
public WordList(int size)
// pre: size >= 0
// post: construct a word list capable of holding "size" words

public boolean isEmpty()

// post: return true iff the word list contains no words

public void add(String s)

// post: add a word to the word list, if it is not already there

public String selectAny()

// pre: the word list is not empty
// post: return a random word from the list

public void remove(String word)

// pre: word is not null
// post: remove the word from the word list
}

We will leave the implementation details of this example until later. You might
consider various ways that the WordList might be implemented. As long as
the methods of the interface can be supported by your data structure, your
implementation is valid.

Exercise 1.3 Finish the sketch of the WordList class to include details about the
state variables.

1.7 Sketching an Example: A Rectangle Class

Suppose we are developing a graphics system that allows the programmer to
draw on a DrawingWindow. This window has, associated with it, a Cartesian
coordinate system that allows us to uniquely address each of the points within
the window. Suppose, also, that we have methods for drawing line segments,
say, using the Line object. How might we implement a rectangle—called a
Rect—to be drawn in the drawing window?
One obvious goal would be to draw a Rect on the DrawingWindow. This
might be accomplished by drawing four line segments. It would be useful to
be able to draw a filled rectangle, or to erase a rectangle (think: draw a filled
rectangle in the background color). We’re not sure how to do this efficiently, but
these latter methods seem plausible and consistent with the notion of drawing.
(We should check to see if it is possible to draw in the background color.) This
leads to the following methods:

Rect public void fillOn(DrawingTarget d)

// pre: d is a valid drawing window
// post: the rectangle is filled on the drawing window d
1.7 Sketching an Example: A Rectangle Class 21

public void clearOn(DrawingTarget d)

// pre: d is a valid drawing window
// post: the rectangle is erased from the drawing window

public void drawOn(DrawingTarget d)

// pre: d is a valid drawing window
// post: the rectangle is drawn on the drawing window

It might be useful to provide some methods to allow us to perform basic calcu-

lations—for example, we might want to find out if the mouse arrow is located
within the Rect. These require accessors for all the obvious data. In the hope
that we might use a Rect multiple times in multiple locations, we also provide
methods for moving and reshaping the Rect.
public boolean contains(Pt p)
// pre: p is a valid point
// post: true iff p is within the rectangle

public int left()

// post: returns left coordinate of the rectangle

public void left(int x)

// post: sets left to x; dimensions remain unchanged

public int width()

// post: returns the width of the rectangle

public void width(int w)

// post: sets width of rectangle, center and height unchanged

public void center(Pt p)

// post: sets center of rect to p; dimensions remain unchanged

public void move(int dx, int dy)

// post: moves rectangle to left by dx and down by dy

public void moveTo(int left, int top)

// post: moves left top of rectangle to (left,top);
// dimensions are unchanged

public void extend(int dx, int dy)

// post: moves sides of rectangle outward by dx and dy

Again, other approaches might be equally valid. No matter how we might rep-
resent a Rect, however, it seems that all rectangular regions with horizontal
and vertical sides can be specified with four integers. We can, then, construct a
Rect by specifying, say, the left and top coordinates and the width and height.
For consistency’s sake, it seems appropriate to allow rectangles to be drawn
anywhere (even off the screen), but the width and height should be non-negative
22 The Object-Oriented Method

values. We should make sure that these constraints appear in the documenta-
tion associated with the appropriate constructors and methods. (See Section 2.2
for more details on how to write these comments.)
Given our thinking, we have some obvious Rect constructors:

public Rect()
// post: constructs a trivial rectangle at origin

public Rect(Pt p1, Pt p2)

// post: constructs a rectangle between p1 and p2

public Rect(int x, int y, int w, int h)

// pre: w >= 0, h >= 0
// post: constructs a rectangle with upper left (x,y),
// width w, height h

We should feel pleased with the progress we have made. We have developed
the signatures for the rectangle interface, even though we have no immediate
application. We also have some emerging answers on approaches to implement-
ing the Rect internally. If we declare our Rect data protected, we can insulate
ourselves from changes suggested by inefficiencies we may yet discover.

Exercise 1.4 Given this sketch of the Rect interface, how would you declare the
private data associated with the Rect object? Given your approach, describe how
you might implement the center(int x, int y) method.

1.8 Interfaces
Sometimes it is useful to describe the interface for a number of different classes,
without committing to an implementation. For example, in later sections of this
text we will implement a number of data structures that are able to be modified
by adding or removing values. We can, for all of these classes, specify a few of
their fundamental methods by using the Java interface declaration:

public interface Structure

{
public int size();
Structure // post: computes number of elements contained in structure

public boolean isEmpty();

// post: return true iff the structure is empty

public void clear();

// post: the structure is empty

public boolean contains(Object value);

// pre: value is non-null
// post: returns true iff value.equals some value in structure
1.8 Interfaces 23

public void add(Object value);

// pre: value is non-null
// post: value has been added to the structure
// replacement policy is not specified

public Object remove(Object value);

// pre: value is non-null
// post: an object equal to value is removed and returned, if found

public java.util.Enumeration elements();

// post: returns an enumeration for traversing structure;
// all structure package implementations return
// an AbstractIterator

public Iterator iterator();

// post: returns an iterator for traversing structure;
// all structure package implementations return
// an AbstractIterator

public Collection values();

// post: returns a Collection that may be used with
// Java's Collection Framework
}

Notice that the body of each method has been replaced by a semicolon. It
is, in fact, illegal to specify any code in a Java interface. Specifying just the
method signatures in an interface is like writing boilerplate for a contract with-
out committing to any implementation. When we decide that we are interested
in constructing a new class, we can choose to have it implement the Structure
interface. For example, our WordList structure of Section 1.6 might have made
use of our Structure interface by beginning its declaration as follows:

public class WordList implements Structure

When the WordList class is compiled by the Java compiler, it checks to see that
each of the methods mentioned in the Structure interface—add, remove, size, WordList
and the others—is actually implemented. In this case, only isEmpty is part of
the WordList specification, so we must either (1) not have WordList implement
the Structure interface or (2) add the methods demanded by Structure.
Interfaces may be extended. Here, we have a possible definition of what it
means to be a Set:

public interface Set extends Structure

{
public void addAll(Structure other);
// pre: other is non-null Set
// post: values from other are added into this set
24 The Object-Oriented Method

public boolean containsAll(Structure other);

// pre: other is non-null
// post: returns true if every value in set is in other

public void removeAll(Structure other);

// pre: other is non-null
// post: values of this set contained in other are removed

public void retainAll(Structure other);

// pre: other is non-null
// post: values not appearing in the other structure are removed
}

A Set requires several set-manipulation methods—addAll (i.e., set union) retain-

All (set intersection), and removeAll (set difference)—as well as the meth-
ods demanded by being a Structure. If we implement these methods for the
WordList class and indicate that WordList implements Set, the WordList class
could be used wherever either a Structure or Set is required. Currently, our
WordList is close to, but not quite, a Structure. Applications that demand
the functionality of a Structure will not be satisfied with a WordList. Having
the class implement an interface increases the flexibility of its use. Still, it may
require considerable work for us to upgrade the WordList class to the level of
a Structure. It may even work against the design of the WordList to provide
the missing methods. The choices we make are part of an ongoing design pro-
cess that attempts to provide the best implementations of structures to meet the
demands of the user.

1.9 Who Is the User?

When implementing data structures using classes and interfaces, it is sometimes
hard to understand why we might be interested in hiding the implementation.
After all, perhaps we know that ultimately we will be the only programmers
making use of these structures. That might be a good point, except that if
you are really a successful programmer, you will implement the data structure
flawlessly this week, use it next week, and not return to look at the code for
a long time. When you do return, your view is effectively that of a user of the
code, with little or no memory of the implementation.
One side effect of this relationship is that we have all been reminded of the
need to write comments. If you do not write comments, you will not be able to
read the code. If, however, you design, document, and implement your interface
carefully, you might not ever have to look at the implementation! That’s good
news because, for most of us, in a couple of months our code is as foreign to
us as if someone else had implemented it. The end result: consider yourself a
user and design and abide by your interface wherever possible. If you know of
some public field that gives a hint of the implementation, do not make use of it.
Instead, access the data through appropriate methods. You will be happy you
1.10 Conclusions 25
N

NW

NE
did later, when you optimize your implementation.

E
SW

SE
S
Principle 3 Design and abide by interfaces as though you were the user.

A quick corollary to this statement is the following:

Principle 4 Declare data fields protected.

N

NW

NE
W

E
If the data are protected, you cannot access them from outside the class, and

SW

SE
S

you are forced to abide by the restricted access of the interface.

1.10 Conclusions
The construction of substantial applications involves the development of com-
plex and interacting structures. In object-oriented languages, we think of these
structures as objects that communicate through the passing of messages or,
more formally, the invocation of methods.
We use object orientation in Java to write the structures found in this book.
It is possible, of course, to design data structures without object orientation, but
any effective data structuring model ultimately depends on the use of some form
of abstraction that allows the programmer to avoid considering the complexities
of particular implementations.
In many languages, including Java, data abstraction is supported by sepa-
rating the interface from the implementation of the data structure. To ensure
that users cannot get past the interface to manipulate the structure in an uncon-
trolled fashion, the system controls access to fields, methods, and classes. The
implementor plays an important role in making sure that the structure is usable,
given the interface. This role is so important that we think of implementation
as supporting the interface—sometimes usefully considered a contract between
the implementor and the user. This analogy is useful because, as in the real
world, if contracts are violated, someone gets upset!
Initial design of the interfaces for data structures arises from considering
how they are used in simple applications. Those method calls that are required
by the application determine the interface for the new structure and constrain,
in various ways, the choices we make in implementing the object.
In our implementation of an Association, we can use the Object class—
that class inherited by all other Java classes—to write very general data struc-
tures. The actual type of value that is stored in the Association is determined
by the values passed to the constructors and mutators of the class. This abil-
ity to pass a subtype to any object that requires a super type is a strength of
object-oriented languages—and helps to reduce the complexity of code.
26 The Object-Oriented Method

Self Check Problems

Solutions to these problems begin on page 441.
1.1 What is meant by abstraction?
1.2 What is procedural abstraction?
1.3 What is data abstraction?
1.4 How does Java support the concept of a message?
1.5 What is the difference between an object and a class?
1.6 What makes up a method’s signature?
1.7 What is the difference between an interface and an implementation?
1.8 What is the difference between an accessor and a mutator?
1.9 A general purpose class, such as an Association, often makes use of
parameters of type Object. Why?
1.10 What is the difference between a reference and an object?
1.11 Who uses a class?

Problems
Solutions to the odd-numbered problems begin on page 451.
1.1 Which of the following are primitive Java types: int, Integer, double,
Double, String, char, Association, BankAccount, boolean, Boolean?
1.2 Which of the following variables are associated with valid constructor
calls?
BankAccount a,b,c,d,e,f;
Association g,h;
a = new BankAccount("Bob",300.0);
b = new BankAccount(300.0,"Bob");
c = new BankAccount(033414,300.0);
d = new BankAccount("Bob",300);
e = new BankAccount("Bob",new Double(300));
f = new BankAccount("Bob",(double)300);
g = new Association("Alice",300.0);
h = new Association("Alice",new Double(300));

1.3 For each pair of classes, indicate which class extends the other:
a. java.lang.Number, java.lang.Double
b. java.lang.Number, java.lang.Integer
c. java.lang.Number, java.lang.Object
d. java.util.Stack, java.util.Vector
1.10 Conclusions 27

e. java.util.Hashtable, java.util.Dictionary

1.4 Rewrite the compound interest program (discussed when considering

BankAccounts in Section 1.4) so that it uses Associations.
1.5 Write a program that attempts to modify one of the private fields of
an Association. When does your environment detect the violation? What
happens?
1.6 Finish the design of a Ratio class that implements a ratio between
two integers. The class should support standard math operations: addition,
subtraction, multiplication, and division. You should also be able to construct
Ratios from either a numerator-denominator pair, or a single integer, or with
no parameter at all (what is a reasonable default value?).
1.7 Amazing fact: If you construct a Ratio from two random integers, 0 <
a, b, the probability that ab is already in reduced terms is π62 . Use this fact to
write a program to compute an approximation to π.
1.8 Design a class to represent a U.S. telephone number. It should sup-
port three types of constructors—one that accepts three numbers, represent-
ing area code, exchange, and extension; another that accepts two integers,
representing a number within your local area code; and a third constructor
that accepts a string of letters and numbers that represent the number (e.g.,
"900-410-TIME"). Provide a method that determines if the number is provided
toll-free (such numbers have area codes of 800, 866, 877, 880, 881, 882, or
888).
1.9 Sometimes it is useful to measure the length of time it takes for a piece
of code to run. (For example, it may help determine where optimizations of
your code would be most effective.) Design a Stopwatch class to support tim-
ing of events. You should consider use of the nanosecond clock in the Java
environment, System.nanoTime(). Like many stopwatches, it should support
starting, temporary stopping, and a reset. The design of the protected section
of the stopwatch should hide the implementation details.
1.10 Design a data structure in Java that represents a musical tone. A tone
can be completely specified as a number of cycles per second (labeled Hz for
hertz), or the number of half steps above a commonly agreed upon tone, such
as A (in modern times, in the United States, considered to be 440 Hz). Higher
tones have higher frequencies. Two tones are an octave (12 semitones) apart
if one
√ has a frequency twice the other. A half step or semitone increase in tone
is 12 2 ≈ 1.06 times higher. Your tone constructors should accept a frequency
(a double) or a number of half steps (an int) above A. Imperfect frequencies
should be tuned to the nearest half step. Once constructed, a tone should be
able to provide its frequency in either cycles per second or half-steps above A.
1.11 Extend Problem 1.10 to allow a second parameter to each constructor
to specify the definition of A upon which the tone’s definition is based. What
modern tone most closely resembles that of modern middle C (9 semitones
below A) if A is defined to be 415 Hz?
28 The Object-Oriented Method

1.12 Design a data structure to represent a combination lock. When the

lock is constructed, it is provided with an arbitrary length array of integers
between 0 and 25 specifying a combination (if no combination is provided,
9 − 0 − 21 − 0 is the default). Initially, it is locked. Two methods—press
and reset—provide a means of entering a combination: press enters the next
integer to be used toward matching the combination, while reset re-readies
the lock for accepting the first integer of the combination. Only when press is
used to match the last integer of the combination does the lock silently unlock.
Mismatched integers require a call to the reset method before the combination
can again be entered. The isLocked method returns true if and only if the lock
is locked. The lock method locks and resets the lock. In the unlocked state only
the isLocked and lock methods have effect. (Aside: Because of the physical
construction of many combination locks, it is often the case that combinations
have patterns. For example, a certain popular lock is constructed with a three-
number combination. The first and last numbers result in the same remainder x
when divided by 4. The middle number has remainder (x + 2)%4 when divided
by 4!)
1.13 Design a data structure to simulate the workings of a car radio. The
state of the radio is on or off, and it may be used to listen to an AM or FM
station. A dozen modifiable push buttons (identified by integers 1 through 12)
allow the listener to store and recall AM or FM frequencies. AM frequencies can
be represented by multiples of 10 in the range 530 to 1610. FM frequencies are
found at multiples of 0.2 in the range 87.9 to 107.9.
1.14 Design a data structure to maintain the position of m coins of radius 1
through m on a board with n ≥ m squares numbered 0 through n − 1. You may
provide whatever interface you find useful to allow your structure to represent
any placement of coins, including stacks of coins in a single cell. A configuration
is valid only if large coins are not stacked on small coins. Your structure should
have an isValid method that returns true if the coins are in a valid position.
(A problem related to this is discussed in Section 10.2.1.)

Top view

Side view
1.11 Laboratory: The Day of the Week
Calculator

Objective. To (re)establish ties with Java: to write a program that reminds us

of the particulars of numeric calculations and array manipulation in Java.
Discussion. In this lab we learn to compute the day of the week for any date
between January 1, 1900, and December 31, 2099.4 During this period of time,
the only calendar adjustment is a leap-year correction every 4 years. (Years
divisible by 100 are normally not leap years, but years divisible by 400 always
are.) Knowing this, the method essentially computes the number of days since
the beginning of the twentieth century in modulo 7 arithmetic. The computed
remainder tells us the day of the week, where 0 is Saturday.
An essential feature of this algorithm involves remembering a short table of
monthly adjustments. Each entry in the table corresponds to a month, where
January is month 1 and December is month 12.

Month 1 2 3 4 5 6 7 8 9 10 11 12
Adjustment 1 4 4 0 2 5 0 3 6 1 4 6

If the year is divisible by 4 (it’s a leap year) and the date is January or February,
you must subtract 1 from the adjustment.
Remembering this table is equivalent to remembering how many days are in
each month. Notice that 144 is 122 , 025 is 52 , 036 is 62 , and 146 is a bit more
than 122 . Given this, the algorithm is fairly simple:

1. Write down the date numerically. The date consists of a month between
1 and 12, a day of the month between 1 and 31, and the number of
years since 1900. Grace Hopper, computer language pioneer, was born
December 9, 1906. That would be represented as year 6. Jana the Giraffe,
of the National Zoo, was born on January 18, 2001. That year would be
represented as year 101.

2. Compute the sum of the following quantities:

• the month adjustment from the given table (e.g., 6 for Admiral Hop-
per)
• the day of the month
• the year

4 This particular technique is due to John Conway, of Princeton University. Professor Conway
answers 10 day of the week problems before gaining access to his computer. His record is at the
time of this writing well under 15 seconds for 10 correctly answered questions. See “Scientist
at Work: John H. Conway; At Home in the Elusive World of Mathematics,” The New York Times,
October 12, 1993.
30 The Object-Oriented Method

• the whole number of times 4 divides the year (e.g., 25 for Jana the
Giraffe)
3. Compute the remainder of the sum of step 2, when divided by 7. The
remainder gives the day of the week, where Saturday is 0, Sunday is 1, etc.
Notice that we can compute the remainders before we compute the sum.
You may also have to compute the remainder after the sum as well, but if
you’re doing this in your head, this considerably simplifies the arithmetic.

What day of the week was Tiger Woods born?

1. Tiger’s birth date is 12-30-75.
2. Remembering that 18 × 4 = 72, we write the sum as follows:

6 + 30 + 75 + 18

which is equivalent to the following sum, modulo 7:

6 + 2 + 5 + 4 = 17 ≡ 3 mod 7

3. He was born on day 3, a Tuesday.

Now you practice: Which of Grace and Jana was born on a Thursday? (The
other was born on a Sunday.)
Procedure. Write a Java program that performs Conway’s day of the week chal-
lenge:
1. Develop an object that can hold a date.
2. Write a method to compute a random date between 1900 and 2099. How
will you limit the range of days potentially generated for any particular
month?
3. Write a method of your date class to compute the day of the week associ-
ated with a date. Be careful: the table given in the discussion has January
as month 1, but Java would prefer it to be month 0! Don’t forget to handle
Jimmy was a the birthday of Jimmy Dorsey (famous jazzman), February 29, 1904.
Monday’s child.
4. Your main method should repeatedly (1) print a random date, (2) read a
predicted day of the week (as an integer/remainder), and (3) check the
correctness of the guess. The program should stop when 10 dates have
been guessed correctly and print the elapsed time. (You may wish to set
this threshold lower while you’re testing the program.)

Helpful Hints. You may find the following Java useful:

1. Random integers may be selected using the java.util.Random class:

Random r = new Random();

int month = (Math.abs(r.nextInt()) % 12) + 1;
1.11 Laboratory: The Day of the Week Calculator 31

You will need to import java.util.Random; at the top of your program

to make use of this class. Be aware that you need to only construct one
random number generator per program run. Also, the random number
generator potentially returns negative numbers. If Math.abs is not used,
these values generate negative remainders.

2. You can find out how many thousandths of seconds have elapsed since
the 1960s, by calling the Java method, System.currentTimeMillis(). It In 2001,
returns a value of type long. We can use this to measure the duration of 1 trillion millis
an experiment, with code similar to the following: since the ’60s.
Dig that!
long start = System.currentTimeMillis();
//
// place experiment to be timed here
//
long duration = System.currentTimeMillis()-start;
System.out.println("time: "+(duration/1000.0)+" seconds.");

The granularity of this timer isn’t any better than a thousandth of a second.
Still, we’re probably not in Conway’s league yet.
After you finish your program, you will find you can quickly learn to answer
10 of these day of the week challenges in less than a minute.
Thought Questions. Consider the following questions as you complete the lab:
1. True or not: In Java is it true that (a % 7) == (a - a/7*7) for a >= 0?
2. It’s rough to start a week on Saturday. What adjustments would be nec-
essary to have a remainder of 0 associated with Sunday? (This might
allow a mnemonic of Nun-day, One-day, Twos-day, Wednesday, Fours-day,
Fives-day, Saturday.)
3. Why do you subtract 1 in a leap year if the date falls before March?
4. It might be useful to compute the portion of any calculation associated
with this year, modulo 7. Remembering that value will allow you to opti- For years
mize your most frequent date calculations. What is the remainder associ- divisible by 28:
ated with this year? think zero!

Notes:
Chapter 2
Comments, Conditions,
and Assertions

Concepts:
. Preconditions /* This is bogus code.
. Postconditions Wizards are invited to improve it. */
. Assertions —Anonymous
. Copyrighting code

C ONSIDER THIS : WE CALL OUR PROGRAMS “ CODE ”! The features of computer

languages, including Java, are designed to help express algorithms in a manner
that a machine can understand. Making a program run more efficiently often
makes it less understandable. If language design was driven by the need to
make the program readable by programmers, it would be hard to argue against
programming in English. Okay, perhaps
A comment is a carefully crafted piece of text that describes the state of the French!
machine, the use of a variable, or the purpose of a control construct. Many
of us, though, write comments for the same reason that we exercise: we feel
guilty. You feel that, if you do not write comments in your code, you “just know”
something bad is going to happen. Well, you are right. A comment you write Ruth Krauss: “A
today will help you out of a hole you dig tomorrow. hole
All too often comments are hastily written after the fact, to help under- is to dig.”
stand the code. The time spent thinking seriously about the code has long since
passed, and the comment might not be right. If you write comments before-
hand, while you are designing your code, it is more likely your comments will
describe what you want to do as you carefully think it out. Then, when some-
thing goes wrong, the comment is there to help you figure out the code. In
fairness, the code and the comment have a symbiotic relationship. Writing one
or the other does not really feel complete, but writing both provides you with
the redundancy of concept: one lucid and one as clear as Java.
The one disadvantage of comments is that, unlike code, they cannot be
checked. Occasionally, programmers come across comments such as “If you
think you understand this, you don’t!” or “Are you reading this?” One could, of
course, annotate programs with mathematical formulas. As the program is com-
piled, the mathematical comments are distilled into very concise descriptions of
34 Comments, Conditions, and Assertions

what should be going on. When the output from the program’s code does not
Semiformal match the result of the formula, something is clearly wrong with your logic. But
convention: a which logic? The writing of mathematical comments is a level of detail most
meeting of tie programmers would prefer to avoid.
haters. A compromise is a semiformal convention for comments that provide a rea-
sonable documentation of when and what a program does. In the code associ-
ated with this book, we see one or two comments for each method or function
that describe its purpose. These important comments are the precondition and
postcondition.

2.1 Pre- and Postconditions

The precondition describes, as succinctly as possible in your native tongue, the
conditions under which a method may be called and expected to produce correct
results. Ideally the precondition expresses the state of the program. This state
is usually cast in terms of the parameters passed to the routine. For example,
the precondition on a square root function might be
// pre: x is nonnegative

The authors of this square root function expect that the parameter is not a
sqrt negative number. It is, of course, legal in Java to call a function or method if
the precondition is not met, but it might not produce the desired result. When
there is no precondition on a procedure, it may be called without failure.
The postcondition describes the state of the program once the routine has
been completed, provided the precondition was met. Every routine should have
some postcondition. If there were not a postcondition, then the routine would
not change the state of the program, and the routine would have no effect!
Always provide postconditions.
Pre- and postconditions do not force you to write code correctly. Nor do they
help you find the problems that do occur. They can, however, provide you with
a uniform method for documenting the programs you write, and they require
more thought than the average comment. More thought put into programs
lowers your average blood pressure and ultimately saves you time you might
spend more usefully playing outside, visiting museums, or otherwise bettering
your mind.

2.2 Assertions
In days gone by, homeowners would sew firecrackers in their curtains. If the
house were to catch fire, the curtains would burn, setting off the firecrackers. It
And the was an elementary but effective fire alarm.
batteries never An assertion is an assumption you make about the state of your program. In
needed Java, we will encode the assertion as a call to a function that verifies the state
replacing. of the program. That function does nothing if the assertion is true, but it halts
2.2 Assertions 35

your program with an error message if it is false. It is a firecracker to sew in

your program. If you sew enough assertions into your code, you will get an N

NW

NE
early warning if you are about to be burned by your logic.

E
SW

SE
Principle 5 Test assertions in your code. S

The Assert class provides several functions to help you test the state of your
program as it runs:
public class Assert
{
static public void pre(boolean test, String message)
// pre: result of precondition test
Assert
// post: does nothing if test true, otherwise abort w/message

static public void post(boolean test, String message)

// pre: result of postcondition test
// post: does nothing if test true, otherwise abort w/message

static public void condition(boolean test, String message)

// pre: result of general condition test
// post: does nothing if test true, otherwise abort w/message

static public void invariant(boolean test, String message)

// pre: result of an invariant test
// post: does nothing if test true, otherwise abort w/message

static public void fail(String message)

// post: throws error with message
}

Each of pre, post, invariant, and condition methods test to see if its first
argument—the assertion—is true. The message is used to indicate the condition
tested by the assertion. Here’s an example of a check to make sure that the
precondition for the sqrt function was met:
public static double sqrt(double x)
// pre: x is nonnegative
// post: returns the square root of x
{
Assert.pre(x >= 0,"the value is nonnegative.");
double guess = 1.0;
double guessSquared = guess * guess;

while (Math.abs(x-guessSquared) >= 0.00000001) {

// guess is off a bit, adjust
guess += (x-guessSquared)/2.0/guess;
guessSquared = guess*guess;
}
return guess;
}
36 Comments, Conditions, and Assertions

Should we call sqrt with a negative value, the assertion fails, the message
is printed out, and the program comes to a halt. Here’s what appears at the
display:

structure.FailedPrecondition:
Assertion that failed: A precondition: the value is nonnegative.
at Assert.pre(Assert.java:17)
at sqrt(examples.java:24)
at main(examples.java:15)

The first two lines of this message indicate that a precondition (that x was non-
negative) failed. This message was printed within Assert.pre on line 17 of the
source, found in Assert.java. The next line of this stack trace indicates that
the call to Assert.pre was made on line 24 of examples.java at the start of
the sqrt function. This is the first line of the sqrt method. The problem is
(probably) on line 15 of the main procedure of examples.java. Debugging our
code should probably start in the main routine.
Beginning with Java 1.4, assertion testing is part of the formal Java language
specification. The assert keyword can be used to perform many of the types of
checks we have described. If, however, you are using an earlier version of Java,
or you expect your users may wish to use a version of Java before version 1.4,
you may find the Assert class to be a more portable approach to the testing of
the conditions of one’s code. A feature of language-based assertion testing is
that the tests can be automatically removed at compile time when one feels se-
cure about the way the code works. This may significantly improve performance
of classes that heavily test conditions.

2.3 Craftsmanship
If you really desire to program well, a first step is to take pride in your work—
pride enough to sign your name on everything you do. Through the centuries,
fine furniture makers signed their work, painters finished their efforts by dab-
bing on their names, and authors inscribed their books. Programmers should
stand behind their creations.
Computer software has the luxury of immediate copyright protection—it is
a protection against piracy, and a modern statement that you stand behind the
belief that what you do is worth fighting for. If you have crafted something as
best you can, add a comment at the top of your code:

// Image compression barrel for downlink to robotic cow tipper.

// (c) 2001, 2002 duane r. bailey

If, of course, you have stolen work from another, avoid the comment and
consider, heavily, the appropriate attribution.
2.4 Conclusions 37

2.4 Conclusions
Effective programmers consider their work a craft. Their constructions are well
considered and documented. Comments are not necessary, but documentation
makes working with a program much easier. One of the most important com-
ments you can provide is your name—it suggests you are taking credit and re-
sponsibility for things you create. It makes our programming world less anony-
mous and more humane.
Special comments, including conditions and assertions, help the user and
implementor of a method determine whether the method is used correctly.
While it is difficult for compilers to determine the “spirit of the routine,” the
implementor is usually able to provide succinct checks of the sanity of the func-
tion. Five minutes of appropriate condition description and checking provided I’ve done my
by the implementor can prevent hours of debugging by the user. time!

Self Check Problems

Solutions to these problems begin on page 442.
2.1 Why is it necessary to provide pre- and postconditions?
2.2 What can be assumed if a method has no precondition?
2.3 Why is it not possible to have a method with no postcondition?
2.4 Object orientation allows us to hide unimportant details from the user.
Why, then, must we put pre- and postconditions on hidden code?

Problems
Solutions to the odd-numbered problems begin on page 457.
2.1 What are the pre- and postconditions for the length method of the
java.lang.String class?
2.2 What are the pre- and postconditions for String’s charAt method?
2.3 What are the pre- and postconditions for String’s concat method?
2.4 What are the pre- and postconditions for the floor function in the
java.lang.Math class?
2.5 Improve the comments on an old program.
2.6 Each of the methods of Assert (pre, post, and condition) takes the
same parameters. In what way do the methods function differently? (Write a
test program to find out!)
2.7 What are the pre- and postconditions for java.lang.Math.asin class?
2.5 Laboratory: Using Javadoc Commenting

Objective. To learn how to generate formal documentation for your programs.

Discussion. The Javadoc program1 allows the programmer to write comments
in a manner that allows the generation web-based documentation. Program-
mers generating classes to be used by others are particularly encouraged to
consider using Javadoc-based documentation. Such comments are portable,
web-accessible, and they are directly extracted from the code.
In this lab, we will write documentation for an extended version of the Ratio
class we first met in Chapter 1.
Comments used by Javadoc are delimited by a /** */ pair. Note that there
are two asterisks in the start of the comment. Within the comment are a number
of keywords, identified by a leading “at-sign” (@). These keywords identify
the purpose of different comments you right. For example, the text following
an @author comment identifies the programmer who originally authored the
code. These comments, called Javadoc comments, appear before the objects
they document. For example, the first few lines of the Assert class are:
package structure;
/**
* A library of assertion testing and debugging procedures.
* <p>
* This class of static methods provides basic assertion testing
* facilities. An assertion is a condition that is expected to
* be true at a certain point in the code. Each of the
* assertion-based routines in this class perform a verification
* of the condition and do nothing (aside from testing side-effects)
* if the condition holds. If the condition fails, however, the
* assertion throws an exception and prints the associated message,
* that describes the condition that failed. Basic support is
* provided for testing general conditions, and pre- and
* postconditions. There is also a facility for throwing a
* failed condition for code that should not be executed.
* <p>
* Features similar to assertion testing are incorporated
* in the Java 2 language beginning in SDK 1.4.
* @author duane a. bailey
*/
public class Assert
{
. . .
}
For each class you should provide any class-wide documentation, including
@author and @version-tagged comments.

1 Javadoc is a feature of command-line driven Java environments. Graphical environments likely

provide Javadoc-like functionality, but pre- and postcondition support may not be available.
40 Comments, Conditions, and Assertions

Within the class definition, there should be a Javadoc comment for each in-
stance variable and method. Typically, Javadoc comments for instance variables
are short comments that describe the role of the variable in supporting the class
state:

/**
* Size of the structure.
*/
int size;

Comments for methods should include a description of the method’s purpose.

A comment should describe the purpose of each parameter (@param), as well as
the form of the value returned (@return) for function-like methods. Program-
mers should also provide pre- and postconditions using the @pre and @post
keywords.2 Here is the documentation for a square root method.

/**
*
* This method computes the square root of a double value.
* @param x The value whose root is to be computed.
* @return The square root of x.
* @pre x >= 0
* @post computes the square root of x
*/

To complete this lab, you are to

1. Download a copy of the Ratio.java source from the Java Structures web-
site. This version of the Ratio class does not include full comments.

2. Review the code and make sure that you understand the purpose of each
of the methods.

3. At the top of the Ratio.java file, place a Javadoc comment that describes
the class. The comment should describe the features of the class and an
example of how the class might be used. Make sure that you include an
@author comment (use your name).
4. Run the documentation generation facility for your particular environ-
ment. For Sun’s Java environment, the Javadoc command takes a parame-
ter that describes the location of the source code that is to be documented:

javadoc prog.java

2 In this book, where there are constraints on space, the pre- and postconditions are provided in
non-Javadoc comments. Code available on the web, however, is uniformly commented using the
Javadoc comments. Javadoc can be upgraded to recognize pre- and postconditions; details are
available from the Java Structures website.
2.5 Laboratory: Using Javadoc Commenting 41

The result is an index.html file in the current directory that contains links
to all of the necessary documentation. View the documentation to make
sure your description is formatted correctly.
5. Before each instance variable write a short Javadoc comment. The com-
ment should begin with /** and end with */. Generate and view the
documentation and note the change in the documentation.
6. Directly before each method write a Javadoc comment that includes, at
a minimum, one or two sentences that describe the method, a @param
comment for each parameter in the method, a @return comment describ-
ing the value returned, and a @pre and @post comment describing the
conditions.
Generate and view the documentation and note the change in the doc-
umentation. If the documentation facility does not appear to recognize
the @pre and @post keywords, the appropriate Javadoc doclet software
has not been installed correctly. More information on installation of the
Javadoc software can be found at the Java Structures website.

Notes:
Chapter 3
Vectors

Concepts:
Climb high, climb far,
. Vectors
your goal the sky, your aim the star.
. Extending arrays
—Inscription on a college staircase
. Matrices

T HE BEHAVIOR OF A PROGRAM usually depends on its input. Suppose, for ex-

ample, that we wish to write a program that reads in n String values. One
approach would keep track of the n values with n String variables:

public static void main(String args[])

{
// read in n = 4 strings
Scanner s = new Scanner(System.in); StringReader
String v1, v2, v3, v4;
v1 = s.next(); // read a space-delimited word
v2 = s.next();
v3 = s.next();
v4 = s.next();
}

This approach is problematic for the programmer of a scalable application—an

application that works with large sets of data as well as small. As soon as n
changes from its current value of 4, it has to be rewritten. Scalable applications
are not uncommon, and so we contemplate how they might be supported.
One approach is to use arrays. An array of n values acts, essentially, as a
collection of similarly typed variables whose names can be computed at run
time. A program reading n values is shown here:

public static void main(String args[])

{
// read in n = 4 strings
Scanner s = new Scanner(System.in);
String data[];
int n = 4;
// allocate array of n String references:
data = new String[n];
for (int i = 0; i < n; i++)
44 Vectors

{
data[i] = s.next();
}
}

Here, n is a constant whose value is determined at compile time. As the program

starts up, a new array of n integers is constructed and referenced through the
variable named data.
All is fine, unless you want to read a different number of values. Then n
has to be changed, and the program must be recompiled and rerun. Another
solution is to pick an upper bound on the length of the array and only use the
portion of the array that is necessary. Here’s a modified procedure that uses up
to one million array elements:

public static void main(String args[])

{
// read in up to 1 million Strings
Scanner s = new Scanner(System.in);
String data[];
int n = 0;
data = new String[1000000];
// read in strings until we hit end of file
while (s.hasNext())
{
data[n] = s.next();
n++;
}
}

Unfortunately, if you are running your program on a small machine and have
small amounts of data, you are in trouble (see Problem 3.9). Because the array
is so large, it will not fit on your machine—even if you want to read small
amounts of data. You have to recompile the program with a smaller upper
bound and try again. All this seems rather silly, considering how simple the
problem appears to be.
We might, of course, require the user to specify the maximum size of the
array before the data are read, at run time. Once the size is specified, an appro-
priately sized array can be allocated. While this may appear easier to program,
the burden has shifted to the user of the program: the user has to commit to a
specific upper bound—beforehand:

public static void main(String args[])

{
// read in as many Strings as demanded by input
Scanner s = new Scanner(System.in);
String data[];
int n;
// read in the number of strings to be read
n = s.nextInt();
3.1 The Interface 45

// allocate references for n strings

data = new String[n];
// read in the n strings
for (int i = 0; i < n; i++)
{
data[i] = s.next();
}
}

A nice solution is to build a vector—an array whose size may easily be

changed. Here is our String reading program retooled one last time, using
Vectors:

public static void main(String args[])

{
// read in an arbitrary number of strings
Scanner s = new Scanner(System.in);
Vector data;
// allocate vector for storage
data = new Vector();
// read strings, adding them to end of vector, until eof
while (s.hasNext())
{
String st = s.next();
data.add(st);
}
}

The Vector starts empty and expands (using the add method) with every String
read from the input. Notice that the program doesn’t explicitly keep track of the
number of values stored in data, but that the number may be determined by a
call to the size method.

3.1 The Interface

The semantics of a Vector are similar to the semantics of an array. Both can
store multiple values that may be accessed in any order. We call this property
random access. Unlike the array, however, the Vector starts empty and is ex-
tended to hold object references. In addition, values may be removed from the
Vector causing it to shrink. To accomplish these same size-changing operations
in an array, the array would have to be reallocated.
With these characteristics in mind, let us consider a portion of the “inter-
face”1 for this structure:

1 Stricktly speaking, constructors cannot be specified in formal Javainterfaces. Nonetheless,

adopt a convention of identifying constructors as part of the public view of structures (often called
the Application Program Interface or API).
Vector
46 Vectors

public class Vector extends AbstractList implements Cloneable

{
public Vector()
// post: constructs a vector with capacity for 10 elements

public Vector(int initialCapacity)

// pre: initialCapacity >= 0
// post: constructs an empty vector with initialCapacity capacity

public void add(Object obj)

// post: adds new element to end of possibly extended vector

public Object remove(Object element)

// post: element equal to parameter is removed and returned

public Object get(int index)

// pre: 0 <= index && index < size()
// post: returns the element stored in location index

public void add(int index, Object obj)

// pre: 0 <= index <= size()
// post: inserts new value in vector with desired index,
// moving elements from index to size()-1 to right

public boolean isEmpty()

// post: returns true iff there are no elements in the vector

public Object remove(int where)

// pre: 0 <= where && where < size()
// post: indicated element is removed, size decreases by 1

public Object set(int index, Object obj)

// pre: 0 <= index && index < size()
// post: element value is changed to obj; old value is returned

public int size()

// post: returns the size of the vector
}

First, the constructors allow construction of a Vector with an optional initial

capacity. The capacity is the initial number of Vector locations that are reserved
for expansion. The Vector starts empty and may be freely expanded to its
capacity. At that point the Vector’s memory is reallocated to handle further
expansion. While the particulars of memory allocation and reallocation are
hidden from the user, there is obvious benefit to specifying an appropriate initial
capacity.
The one-parameter add method adds a value to the end of the Vector, ex-
panding it. To insert a new value in the middle of the Vector, we use the
two-parameter add method, which includes a location for insertion. To access
3.2 Example: The Word List Revisited 47

an existing element, one calls get. If remove is called with an Object, it re-
moves at most one element, selected by value. Another remove method shrinks
the logical size of the Vector by removing an element from an indicated loca-
tion. The set method is used to change a value in the Vector. Finally, two
methods provide feedback about the current logical size of the Vector: size
and isEmpty. The size method returns the number of values stored within
the Vector. As elements are added to the Vector, the size increases from zero
up to the capacity of the Vector. When the size is zero, then isEmpty returns
true. The result is a data structure that provides constant-time access to data
within the structure, without concern for determining explicit bounds on the
structure’s size.
There are several ways that a Vector is different than its array counterpart.
First, while both the array and Vector maintain a number of references to ob-
jects, the Vector typically grows with use and stores a non-null reference in
each entry. An array is a static structure whose entries may be initialized and
used in any order and are often null. Second, the Vector has an end where ele-
ments can be appended, while the array does not directly support the concept of
appending values. There are times, of course, when the append operation might
not be a feature desired in the structure; either the Vector or array would be a
suitable choice.
The interface for Vectors in the structure package was driven, almost ex-
clusively, by the interface for Java’s proprietary java.util.Vector class. Thus,
while we do not have access to the code for that class, any program written to
use Java’s Vector class can be made to use the Vector class described here;
their interfaces are consistent.

3.2 Example: The Word List Revisited

We now reconsider an implementation of the word list part of our Hangman
program of Section 1.6 implemented directly using Vectors:

Vector list;
String targetWord;
java.util.Random generator = new java.util.Random();
list = new Vector(10); WordList
list.add("clarify");
list.add("entered");
list.add("clerk");
while (list.size() != 0)
{
{ // select a word from the list
int index = Math.abs(generator.nextInt())%list.size();
targetWord = (String)list.get(index);
}
// ... play the game using targetWord ...
list.remove(targetWord);
}
48 Vectors

Here, the operations of the Vector are seen to be very similar to the opera-
tions of the WordList program fragment shown on page 19. The Vector class,
however, does not have a selectAny method. Instead, the bracketed code ac-
complishes that task. Since only Strings are placed within the Vector, the
assignment of targetWord involves a cast from Object (the type of value re-
turned from the get method of Vector) to String. This cast is necessary for
Java to be reassured that you’re expecting an element of type String to be
returned. If the cast were not provided, Java would complain that the types
involved in the assignment were incompatible.
Now that we have an implementation of the Hangman code in terms of both
the WordList and Vector structures, we can deduce an implementation of the
WordList structure in terms of the Vector class. In this implementation, the
WordList contains a Vector that is used to hold the various words, as well
as the random number generator (the variable generator in the code shown
above). To demonstrate the implementation, we look at the implementation of
the WordList’s constructor and selectAny method:
protected Vector theList;
protected java.util.Random generator;

public WordList(int n)
{
theList = new Vector(n);
generator = new java.util.Random();
}

public String selectAny()

{
int i = Math.abs(generator.nextInt())%theList.size();
return (String)theList.get(i);
}

Clearly, the use of a Vector within the WordList is an improvement over the
direct use of an array, just as the use of WordList is an improvement over the
complications of directly using a Vector in the Hangman program.

3.3 Example: Word Frequency

Suppose one day you read a book, and within the first few pages you read
“behemoth” twice. A mighty unusual writing style! Word frequencies within
documents can yield interesting information.2 Here is a little application for
computing the frequency of words appearing on the input:
public static void main(String args[])

2 Recently, using informal “literary forensics,” Don Foster has identified the author of the anony-
WordFreq mously penned book Primary Colors and is responsible for new attributions of poetry to Shake-
speare. Foster also identified Major Henry Livingston Jr. as the true author of “The Night Before
Christmas.”
3.3 Example: Word Frequency 49

{
Vector vocab = new Vector(1000);
Scanner s = new Scanner(System.in);
int i;

// for each word on input

while (s.hasNext())
{
Association wordInfo; // word-frequency association
String vocabWord; // word in the list

// read in and tally instance of a word

String word = s.next();
for (i = 0; i < vocab.size(); i++)
{
// get the association
wordInfo = (Association)vocab.get(i);
// get the word from the association
vocabWord = (String)wordInfo.getKey();
if (vocabWord.equals(word))
{ // match: increment integer in association
Integer f = (Integer)wordInfo.getValue();
wordInfo.setValue(new Integer(f.intValue() + 1));
break;
}
}
// mismatch: add new word, frequency 1.
if (i == vocab.size())
{
vocab.add(new Association(word,new Integer(1)));
}
}
// print out the accumulated word frequencies
for (i = 0; i < vocab.size(); i++)
{
Association wordInfo = (Association)vocab.get(i);
System.out.println(
wordInfo.getKey()+" occurs "+
wordInfo.getValue()+" times.");
}
}

First, for each word found on the input, we maintain an Association between
the word (a String) and its frequency (an Integer). Each element of the
Vector is such an Association. Now, the outer loop at the top reads in each
word. The inner loop scans through the Vector searching for matching words
that might have been read in. Matching words have their values updated. New
words cause the construction of a new Association. The second loop scans
through the Vector, printing out each of the Associations.
50 Vectors

Each of these applications demonstrates the most common use of Vectors—

keeping track of data when the number of entries is not known far in advance.
When considering the List data structure we will consider the efficiency of
these algorithms and, if necessary, seek improvements.

3.4 The Implementation

Clearly, the Vector must be able to store a large number of similar items. We
choose, then, to have the implementation of the Vector maintain an array of
Objects, along with an integer that describes its current size or extent. When
the size is about to exceed the capacity (the length of the underlying array), the
Vector’s capacity is increased to hold the growing number of elements.
The constructor is responsible for allocation of the space and initializing the
local variables. The number of elements initially allocated for expansion can be
specified by the user:
protected Object elementData[]; // the data
protected int elementCount; // number of elements in vector

Vector public Vector()

// post: constructs a vector with capacity for 10 elements
{
this(10); // call one-parameter constructor
}

public Vector(int initialCapacity)

// pre: initialCapacity >= 0
// post: constructs an empty vector with initialCapacity capacity
{
Assert.pre(initialCapacity >= 0, "Initial capacity should not be negative.");
elementData = new Object[initialCapacity];
elementCount = 0;
}

Unlike other languages, all arrays within Java must be explicitly allocated. At
the time the array is allocated, the number of elements is specified. Thus, in the
constructor, the new operator allocates the number of elements desired by the
user. Since the size of an array can be gleaned from the array itself (by asking
for elementData.length), the value does not need to be explicitly stored within
the Vector object.3
To access and modify elements within a Vector, we use the following oper-
ations:
public Object get(int index)

3 It could, of course, but explicitly storing it within the structure would mean that the implementor
would have to ensure that the stored value was always consistent with the value accessible through
the array’s length variable.
3.4 The Implementation 51

// pre: 0 <= index && index < size()

// post: returns the element stored in location index
{
return elementData[index];
}

public Object set(int index, Object obj)

// pre: 0 <= index && index < size()
// post: element value is changed to obj; old value is returned
{
Object previous = elementData[index];
elementData[index] = obj;
return previous;
}

The arguments to both methods identify the location of the desired element. Be-
cause the index should be within the range of available values, the precondition
states this fact.
For the accessor (get), the desired element is returned as the result. The set
method allows the Object reference to be changed to a new value and returns
the old value. These operations, effectively, translate operations on Vectors
into operations on arrays.
Now consider the addition of an element to the Vector. One way this can
be accomplished is through the use of the one-parameter add method. The task
requires extending the size of the Vector and then storing the element at the
location indexed by the current number of elements (this is the first free location
within the Vector). Here is the Java method:
public void add(Object obj)
// post: adds new element to end of possibly extended vector
{
ensureCapacity(elementCount+1);
elementData[elementCount] = obj;
elementCount++;
}

(We will discuss the method ensureCapacity later. Its purpose is simply to en-
sure that the data array actually has enough room to hold the indicated number
of values.) Notice that, as with many modern languages, arrays are indexed
starting at zero. There are many good reasons for doing this. There are prob-
ably just as many good reasons for not doing this, but the best defense is that
this is what programmers are currently used to. N
NW

NE
W

Principle 6 Maintaining a consistent interface makes a structure useful.

SW

SE

If one is interested in inserting an element in the middle of the Vector, it is

necessary to use the two-parameter add method. The operation first creates an
unused location at the desired point by shifting elements out of the way. Once
the opening is created, the new element is inserted.
52 Vectors

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9

0 0 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8

0 0 0 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 7 8

0 0 0 0 0 0 0 0 0 9 0 1 1 2 3 4 5 6 7 8

(a) (b)

Figure 3.1 The incorrect (a) and correct (b) way of moving values in an array to make
room for an inserted value.

public void add(int index, Object obj)

// pre: 0 <= index <= size()
// post: inserts new value in vector with desired index,
// moving elements from index to size()-1 to right
{
int i;
ensureCapacity(elementCount+1);
// must copy from right to left to avoid destroying data
for (i = elementCount; i > index; i--) {
elementData[i] = elementData[i-1];
}
// assertion: i == index and element[index] is available
elementData[index] = obj;
elementCount++;
}

Note that the loop that moves the elements higher in the array runs backward.
To see why, it is only necessary to see what happens if the loop runs forward (see
Figure 3.1a): the lowest element gets copied into higher and higher elements,
ultimately copying over the entire Vector to the right of the insertion point.
Figure 3.1b demonstrates the correct technique.
Removing an element from a specific location in the Vector is very similar,
reversing the effect of add. Here, using an argument similar to the previous one,
the loop moves in the forward direction:

public Object remove(int where)

// pre: 0 <= where && where < size()
// post: indicated element is removed, size decreases by 1
{
3.5 Extensibility: A Feature 53

Object result = get(where);

elementCount--;
while (where < elementCount) {
elementData[where] = elementData[where+1];
where++;
}
elementData[elementCount] = null; // free reference
return result;
}

We also allow the removal of a specific value from the Vector, by passing an
example Object to remove (not shown). Within this code, the equals method
of the value passed to the routine is used to compare it to values within the
Vector. When (and if) a match is found, it is removed using the technique just
described.
The methods having to do with size are relatively straightforward:
public boolean isEmpty()
// post: returns true iff there are no elements in the vector
{
return size() == 0;
}

public int size()

// post: returns the size of the vector
{
return elementCount;
}

The logical size of the Vector is the number of elements stored within the
Vector, and it is empty when this size is zero.

3.5 Extensibility: A Feature

Sometimes, our initial estimate of the maximum number of values is too small.
In this case, it is necessary to extend the capacity of the Vector, carefully main-
taining the values already stored within the Vector. Fortunately, because we
have packaged the implementation within an interface, it is only necessary to
extend the functionality of the existing operations and provide some additional
methods to describe the features.
A first approach might be to extend the Vector to include just as many
elements as needed. Every time an element is added to the Vector, the number
of elements is compared to the capacity of the array. If the capacity is used up,
an array that is one element longer is allocated. This reallocation also requires
copying of the existing data from one array to the other. Of course, for really
long arrays, these copying operations would take a proportionally long time.
Over time, as the array grows to n elements, the array data get copied many
times. At the beginning, the array holds a single element, but it is expanded to
54 Vectors

hold two. The original element must be copied to the new space to complete
the operation. When a third is added, the first two must be copied. The result
is that
n(n − 1)
1 + 2 + 3 + · · · + (n − 1) =
2
elements are copied as the array grows to size n. (Proving this last formula is
the core of Problem 3.8.) This is expensive since, if in the beginning we had
just allocated the Vector with a capacity of n elements, none of the data items
would have to be copied during extension!
It turns out there is a happy medium: every time you extend the array, just
double its capacity. Now, if we reconsider the number of times that an item
gets copied during the extension process, the result is dramatically different.
Suppose, for neatness only, that n is a power of 2, and that the Vector started
with a capacity of 1. What do we know? When the Vector was extended from
capacity 1 to capacity 2, one element was copied. When the array was extended
from capacity 2 to capacity 4, two elements were copied. When the array was
extended from capacity 4 to capacity 8, four elements were copied. This contin-
ues until the last extension, when the Vector had its capacity extended from n2
to n: then n2 elements had to be preserved. The total number of times elements
were copied is
n
1 + 2 + 4 + ··· + = n − 1
2
Thus, extension by doubling allows unlimited growth of the Vector with an
overhead that is proportional to the ultimate length of the array. Another way
to think about it is that there is a constant overhead in supporting each element
of a Vector extended in this way.
The Java language specifies a Vector interface that allows the user to specify
how the Vector is to be extended if its capacity is not sufficient for the current
operation. When the Vector is constructed, a capacityIncrement is specified.
This is simply the number of elements to be added to the underlying array
when extension is required. A nonzero value for this increment leads to the n2
behavior we saw before, but it may be useful if, for example, one does not have
the luxury of being able to double the size of a large array. If the increment is
zero, the doubling strategy is used.
Our design, then, demands another protected value to hold the increment;
we call this capacityIncrement. This value is specified in a special constructor
and is not changed during the life of the Vector:

protected int capacityIncrement; // the rate of growth for vector

public Vector(int initialCapacity, int capacityIncr)

// pre: initialCapacity >= 0, capacityIncr >= 0
// post: constructs an empty vector with initialCapacity capacity
// that extends capacity by capacityIncr, or doubles if 0
{
Assert.pre(initialCapacity >= 0 && capacityIncr >= 0,
"Neither capacity nor increment should be negative.");
3.5 Extensibility: A Feature 55

elementData = new Object[initialCapacity];

elementCount = 0;
capacityIncrement = capacityIncr;
}

We are now prepared to investigate ensureCapacity, a method that, if nec-

essary, resizes Vector to have a capacity of at least minCapacity:

public void ensureCapacity(int minCapacity)

// post: the capacity of this vector is at least minCapacity
{
if (elementData.length < minCapacity) {
int newLength = elementData.length; // initial guess
if (capacityIncrement == 0) {
// increment of 0 suggests doubling (default)
if (newLength == 0) newLength = 1;
while (newLength < minCapacity) {
newLength *= 2;
}
} else {
// increment != 0 suggests incremental increase
while (newLength < minCapacity)
{
newLength += capacityIncrement;
}
}
// assertion: newLength > elementData.length.
Object newElementData[] = new Object[newLength];
int i;
// copy old data to array
for (i = 0; i < elementCount; i++) {
newElementData[i] = elementData[i];
}
elementData = newElementData;
// garbage collector will (eventually) pick up old elementData
}
// assertion: capacity is at least minCapacity
}

This code deserves careful investigation. If the current length of the underlying
array is already sufficient to provide minCapacity elements, then the method
does nothing. On the other hand, if the Vector is too short, it must be ex-
tended. We use a loop here that determines the new capacity by doubling (if
capacityIncrement is zero) or by directly incrementing if capacityIncrement
is nonzero. In either case, by the time the loop is finished, the desired capacity
is determined. At that point, an array of the appropriate size is allocated, the
old values are copied over, and the old array is dereferenced in favor of the new.
56 Vectors

3.6 Example: L-Systems

In the late 1960s biologists began to develop computational models for growth.
One of the most successful models, L-systems, was developed by Aristid Lin-
denmayer. An L-system consists of a seed or start string of symbols derived
from an alphabet, along with a number of rules for changing or rewriting the
symbols, called productions. To simulate an interval of growth, strings are com-
pletely rewritten using the productions. When the rewriting begins with the
start string, it is possible to iteratively simulate the growth of a simple organ-
ism. To demonstrate the complexity of this approach, we can use an alphabet
of two characters—S (for stem) and L (for leaf). If the two productions
Before After
S L
L SL
are used, we can generate the following strings over 6 time steps:
Time String
0 S
1 L
2 SL
3 LSL
4 SLLSL
5 LSLSLLSL
6 SLLSLLSLSLLSL
Although there are some observations that might be made (there are never two
consecutive Ss), any notion of a pattern in this string quickly breaks down. Still,
many organisms display patterns that are motivated by the seemingly simple
production system.
We can use Vectors to help us perform this rewriting process. By construct-
ing two Character objects, L and S, we can store patterns in a Vector of refer-
ences. The rewriting process involves constructing a new result Vector. Here is
a program that would verify the growth pattern suggested in the table:

public class LSystem

{ // constants that define the alphabet
final static Character L = new Character('L');
LSystem final static Character S = new Character('S');

public static Vector rewrite(Vector s)

// pre: s is a string of L and S values
// post: returns a string rewritten by productions
{
Vector result = new Vector();
for (int pos = 0; pos < s.size(); pos++)
{
3.7 Example: Vector-Based Sets 57

// rewrite according to two different rules

if (S == s.get(pos)) {
result.add(L);
} else if (L == s.get(pos)) {
result.add(S); result.add(L);
}
}
return result;
}

public static void main(String[] args)

{
Vector string = new Vector();
string.add(S);

// determine the number of strings

Scanner s = new Scanner(System.in);
int count = s.nextInt();

// write out the start string

System.out.println(string);
for (int i = 1; i <= count; i++)
{
string = rewrite(string); // rewrite the string
System.out.println(string); // print it out
}
}
}

L-systems are an interesting example of a grammar system. The power of a

grammar to generate complex structures—including languages and, biologi-
cally, plants—is of great interest to theoretical computer scientists.

3.7 Example: Vector-Based Sets

In Section 1.8 we discussed Java’s interface for a Set. Mathematically, it is an
unordered collection of unique values. The set abstraction is an important fea-
ture of many algorithms that appear in computer science, and so it is important
that we actually consider a simple implementation before we go much further.
As we recall, the Set is an extension of the Structure interface. It demands
that the programmer implement not only the basic Structure methods (add,
contains, remove, etc.), but also the following methods of a Set. Here is the
interface associated with a Vector-based implementation of a Set:

public class SetVector extends AbstractSet

{
public SetVector()
// post: constructs a new, empty set SetVector
58 Vectors

public SetVector(Structure other)

// post: constructs a new set with elements from other

public void clear()

// post: elements of set are removed

public boolean isEmpty()

// post: returns true iff set is empty

public void add(Object e)

// pre: e is non-null object
// post: adds element e to set

public Object remove(Object e)

// pre: e is non-null object
// post: e is removed from set, value returned

public boolean contains(Object e)

// pre: e is non-null
// post: returns true iff e is in set

public boolean containsAll(Structure other)

// pre: other is non-null reference to set
// post: returns true iff this set is subset of other

public Object clone()

// post: returns a copy of set

public void addAll(Structure other)

// pre: other is a non-null structure
// post: add all elements of other to set, if needed

public void retainAll(Structure other)

// pre: other is non-null reference to set
// post: returns set containing intersection of this and other

public void removeAll(Structure other)

// pre: other is non-null reference to set
// post: returns set containing difference of this and other

public Iterator iterator()

// post: returns traversal to traverse the elements of set

public int size()

// post: returns number of elements in set
}

A SetVector might take the approach begun by the WordList implementation

3.7 Example: Vector-Based Sets 59

we have seen in Section 3.2: each element of the Set would be stored in a
location in the Vector. Whenever a new value is to be added to the Set, it
is only added if the Set does not already contain the value. When values are
removed from the Set, the structure contracts. At all times, we are free to keep
the order of the data in the Vector hidden from the user since the ordering of
the values is not part of the abstraction.
We construct a SetVector using the following constructors, which initialize
a protected Vector:

protected Vector data; // the underlying vector

public SetVector()
// post: constructs a new, empty set
{
data = new Vector();
}

public SetVector(Structure other)

// post: constructs a new set with elements from other
{
this();
addAll(other);
}

The second constructor is a copy constructor that makes use of the union op-
erator, addAll. Since the initial set is empty (the call to this() calls the first
constructor), the SetVector essentially picks up all the values found in the other
structure.
Most methods of the Set are adopted from the underlying Vector class. For
example, the remove method simply calls the remove method of the Vector:

public Object remove(Object e)

// pre: e is non-null object
// post: e is removed from set, value returned
{
return data.remove(e);
}

The add method, though, is responsible for ensuring that duplicate values are
not added to the Set. It must first check to see if the value is already a member:

public void add(Object e)

// pre: e is non-null object
// post: adds element e to set
{
if (!data.contains(e)) data.add(e);
}
60 Vectors

To perform the more complex Set-specific operations (addAll and others), we

must perform the specified operation for all the values of the other set. To ac-
complish this, we make use of an Iterator, a mechanism we will not study
until Chapter 8, but which is nonetheless simple to understand. Here, for ex-
ample, is the implementation of addAll, which attempts to add all the values
found in the other structure:

public void addAll(Structure other)

// pre: other is a non-null structure
// post: add all elements of other to set, if needed
{
Iterator yourElements = other.iterator();
while (yourElements.hasNext())
{
add(yourElements.next());
}
}

Other methods are defined in a straightforward manner.

3.8 Example: The Matrix Class

One application of the Vector class is to support a two-dimensional Vector-like
object: the matrix. Matrices are used in applications where two dimensions of
data are needed. Our Matrix class has the following methods:

public class Matrix

{
public Matrix(int h, int w)
Matrix // pre: h >= 0, w >= 0;
// post: constructs an h row by w column matrix

public Object get(int row, int col)

// pre: 0 <= row < height(), 0 <= col < width()
// post: returns object at (row, col)

public void set(int row, int col, Object value)

// pre: 0 <= row < height(), 0 <= col < width()
// post: changes location (row, col) to value

public void addRow(int r)

// pre: 0 <= r < height()
// post: inserts row of null values to be row r

public void addCol(int c)

// pre: 0 <= c < width()
// post: inserts column of null values to be column c
3.8 Example: The Matrix Class 61

Rows 0 1 2 3

0 (0,0) (0,1) (0,2) (0,3)

1 (1,0) (1,1) (1,2) (1,3)

2 (2,0) (2,1) (2,2) (2,3)

3 (3,0) (3,1) (3,2) (3,3)

4 (4,0) (4,1) (4,2) (4,3)

Figure 3.2 The Matrix class is represented as a Vector of rows, each of which is a
Vector of references to Objects. Elements are labeled with their indices.

public Vector removeRow(int r)

// pre: 0 <= r < height()
// post: removes row r and returns it as a Vector

public Vector removeCol(int c)

// pre: 0 <= c < width()
// post: removes column c and returns it as a vector

public int width()

// post: returns number of columns in matrix

public int height()

// post: returns number of rows in matrix
}

The two-parameter constructor specifies the width and height of the Matrix. El-
ements of the Matrix are initially null, but may be reset with the set method.
This method, along with the get method, accepts two parameters that identify
the row and the column of the value. To expand and shrink the Matrix, it is
possible to insert and remove both rows and columns at any location. When a
row or column is removed, a Vector of removed values is returned. The meth-
ods height and width return the number of rows and columns found within
the Matrix, respectively.
To support this interface, we imagine that a Matrix is a Vector of rows,
which are, themselves, Vectors of values (see Figure 3.2). While it is not strictly
necessary, we explicitly keep track of the height and width of the Matrix (if we
determine at some later date that keeping this information is unnecessary, the
interface would hide the removal of these fields). Here, then, is the constructor
for the Matrix class:

protected int height, width; // size of matrix

62 Vectors

protected Vector rows; // vector of row vectors

public Matrix(int h, int w)

// pre: h >= 0, w >= 0;
// post: constructs an h row by w column matrix
{
height = h; // initialize height and width
width = w;
// allocate a vector of rows
rows = new Vector(height);
for (int r = 0; r < height; r++)
{ // each row is allocated and filled with nulls
Vector theRow = new Vector(width);
rows.add(theRow);
for (int c = 0; c < width; c++)
{
theRow.add(null);
}
}
}

We allocate a Vector for holding the desired number of rows, and then, for each
row, we construct a new Vector of the appropriate width. All the elements are
initialized to null. It’s not strictly necessary to do this initialization, but it’s a
good habit to get into.
The process of manipulating individual elements of the matrix is demon-
strated by the get and set methods:
public Object get(int row, int col)
// pre: 0 <= row < height(), 0 <= col < width()
// post: returns object at (row, col)
{
Assert.pre(0 <= row && row < height, "Row in bounds.");
Assert.pre(0 <= col && col < width, "Col in bounds.");
Vector theRow = (Vector)rows.get(row);
return theRow.get(col);
}

public void set(int row, int col, Object value)

// pre: 0 <= row < height(), 0 <= col < width()
// post: changes location (row, col) to value
{
Assert.pre(0 <= row && row < height, "Row in bounds.");
Assert.pre(0 <= col && col < width, "Col in bounds.");
Vector theRow = (Vector)rows.get(row);
theRow.set(col,value);
}

The process of manipulating an element requires looking up a row within the

rows table and finding the element within the row. It is also important to notice
3.8 Example: The Matrix Class 63

Rows 0 1 2 3

0 (0,0) (0,1) (0,2) (0,3)

1 (1,0) (1,1) (1,2) (1,3)

2 (2,0) (2,1) (2,2) (2,3)

4 (3,0) (3,1) (3,2) (3,3)

5 (4,0) (4,1) (4,2) (4,3)

Figure 3.3 The insertion of a new row (gray) into an existing matrix. Indices are those
associated with matrix before addRow. Compare with Figure 3.2.

that in the set method, the row is found using the get method, while the
element within the row is changed using the set method. Although the element
within the row changes, the row itself is represented by the same vector.
Many of the same memory management issues discussed in reference to
Vectors hold as well for the Matrix class. When a row or column needs to be
expanded to make room for new elements (see Figure 3.3), it is vital that the
management of the arrays within the Vector class be hidden. Still, with the
addition of a row into the Matrix, it is necessary to allocate the new row object
and to initialize each of the elements of the row to null:

public void addRow(int r)

// pre: 0 <= r < height()
// post: inserts row of null values to be row r
{
Assert.pre(0 <= r && r < width, "Row in bounds.");
height++;
Vector theRow = new Vector(width);
for (int c = 0; c < width; c++)
{
theRow.add(null);
}
rows.add(r,theRow);
}

We leave it to the reader to investigate the implementation of other Matrix

methods. In addition, a number of problems consider common extensions to
the Matrix class.
64 Vectors

3.9 Conclusions
Most applications that accept data are made more versatile by not imposing
constraints on the number of values processed by the application. Because the
size of an array is fixed at the time it is allocated, programmers find it difficult
to create size-independent code without the use of extensible data structures.
The Vector and Matrix classes are examples of extensible structures.
Initially Vectors are empty, but can be easily expanded when necessary.
When a programmer knows the upper bound on the Vector size, this infor-
mation can be used to minimize the amount of copying necessary during the
entire expansion process. When a bound is not known, we saw that doubling
the allocated storage at expansion time can reduce the overall copying cost.
The implementation of Vector and Matrix classes is not trivial. Data ab-
straction hides many important housekeeping details. Fortunately, while these
details are complex for the implementor, they can considerably reduce the com-
plexity of applications that make use of the Vector and Matrix structures.

Self Check Problems

Solutions to these problems begin on page 442.
3.1 How are arrays and Vectors the same? How do they differ?
3.2 What is the difference between the add(v) and add(i,v) methods of
Vector?
3.3 What is the difference between the add(i,v) method and the set(i,v)
method?
3.4 What is the difference between the remove(v) method (v is an Object
value), and the remove(i) (i is an int)?
3.5 What is the distinction between the capacity and size of a Vector?
3.6 Why is the use of a Vector an improvement over the use of an array in
the implementation of Hangman in Section 3.2?
3.7 When inserting a value into a Vector why is it necessary to shift ele-
ments to the right starting at the high end of the Vector? (See Figure 3.1.)
3.8 By default, when the size first exceeds the capacity, the capacity of the
Vector is doubled. Why?
3.9 What is the purpose of the following code?

elementData = new Object[initialCapacity];

What can be said about the values found in elementData after this code is
executed?
3.10 When there is more than one constructor for a class, when and how do
we indicate the appropriate method to use? Compare, for example,
3.9 Conclusions 65

Vector v = new Vector();

Vector w = new Vector(1000);

3.11 Is the row index of the Matrix bounded by the matrix height or width?
When indexing a Matrix which is provided first, the row or the column?

Problems
Solutions to the odd-numbered problems begin on page 457.
3.1 Explain the difference between the size and capacity of a vector. Which
is more important to the user?
3.2 The default capacity of a Vector in a structure package implementa-
tion is 10. It could have been one million. How would you determine a suitable
value?
3.3 The implementation of java.util.Vector provides a method trimTo-
Size. This method ensures that the capacity of the Vector is the same as its
size. Why is this useful? Is it possible to trim the capacity of a Vector without
using this method?
3.4 The implementation of java.util.Vector provides a method setSize.
This method explicitly sets the size of the Vector. Why is this useful? Is it
possible to set the size of the Vector without using this method?
3.5 Write a Vector method, indexOf, that returns the index of an object in
the Vector. What should the method return if no object that is equals to this
object can be found? What does java.lang.Vector do in this case? How long
does this operation take to perform, on average?
3.6 Write a class called BitVector that has an interface similar to Vector,
but the values stored within the BitVector are all known to be boolean (the
primitive type). What is the primary advantage of having a special-purpose
vector, like BitVector?
3.7 Suppose we desire to implement a method reverse for the Vector class.
One approach would be to remove location 0 and to use add near the end or tail
of the Vector. Defend or reject this suggested implementation. In either case,
write the best method you can.
3.8 Suppose that a precisely sized array is used to hold data, and that each
time the array size is to be increased, it is increased by exactly one and the data
are copied over. Prove that, in the process of growing an array incrementally
from size 0 to size n, approximately n2 values must be copied.
3.9 What is the maximum length array of Strings you can allocate on your
machine? (You needn’t initialize the array.) What is the maximum length array
of boolean you can allocate on your machine? What is to be learned from the
ratio of these two values?
3.10 Implement the Object-based remove method for the Vector class.
66 Vectors

3.11 In our discussion of L-systems, the resulting strings are always linear.
Plants, however, often branch. Modify the LSystem program so that it includes
the following five productions:
Before After Before After Before After
S T U V W [S]U
T U V W
where [S] is represented by a new Vector that contains a single S. (To test to
see if an Object, x, is a Vector, use the test x instanceof Vector.)
3.12 Finish the two-dimensional Vector-like structure Matrix. Each element
of the Matrix is indexed by two integers that identify the row and column
containing the value. Your class should support a constructor, methods addRow
and addCol that append a row or column, the get and set methods, and width
and height methods. In addition, you should be able to use the removeRow and
removeCol methods.
3.13 Write Matrix methods for add and multiply. These methods should
implement the standard matrix operations from linear algebra. What are the
preconditions that are necessary for these methods?
3.14 A Matrix is useful for nonmathematical applications. Suppose, for ex-
ample, that the owners of cars parked in a rectangular parking lot are stored
in a Matrix. How would you design a new Matrix method to return the lo-
cation of a particular value in the Matrix? (Such an extension implements an
associative memory. We will discuss associative structures when we consider
Dictionarys.)
3.15 An m × n Matrix could be implemented using a single Vector with
mn locations. Assuming that this choice was made, implement the get method.
What are the advantages and disadvantages of this implementation over the
Vector of Vectors approach?
3.16 A triangular matrix is a two-dimensional structure with n rows. Row i
has i + 1 columns (numbered 0 through i) in row i. Design a class that supports
all the Matrix operations, except addRow, removeRow, addCol, and removeCol.
You should also note that when a row and column must be specified, the row
must be greater than or equal to the column.
3.17 A symmetric matrix is a two-dimensional Matrix-like structure such that
the element at [i][j] is the same element found at [j][i]. How would you imple-
ment each of the Matrix operations? The triangular matrix of Problem 3.16
may be useful here. Symmetric matrices are useful in implementing undirected
graph structures.
3.18 Sometimes it is useful to keep an unordered list of characters (with
ASCII codes 0 through 127), with no duplicates. Java, for example, has a
CharSet class in the java.util package. Implement a class, CharSet, using
a Vector. Your class should support (1) the creation of an empty set, (2) the
addition of a single character to the set, (3) the check for a character in the set,
(4) the union of two sets, and (5) a test for set equality.
3.10 Laboratory: The Silver Dollar Game

Objective. To implement a simple game using Vectors or arrays.

Discussion. The Silver Dollar Game is played between two players. An arbitrar-
ily long strip of paper is marked off into squares:

The game begins by placing silver dollars in a few of the squares. Each square
holds at most one coin. Interesting games begin with some pairs of coins sepa-
rated by one or more empty squares.

The goal is to move all the n coins to the leftmost n squares of the paper.
This is accomplished by players alternately moving a single coin, constrained by
the following rules:
1. Coins move only to the left.
2. No coin may pass another.
3. No square may hold more than one coin.
The last person to move is the winner.
Procedure. Write a program to facilitate playing the Silver Dollar Game. When
the game starts, the computer has set up a random strip with 3 or more coins.
Two players are then alternately presented with the current game state and are
allowed to enter moves. If the coins are labeled 0 through n−1 from left to right,
a move could be specified by a coin number and the number of squares to move
the coin to the left. If the move is illegal, the player is repeatedly prompted to
enter a revised move. Between turns the computer checks the board state to
determine if the game has been won.
Here is one way to approach the problem:
1. Decide on an internal representation of the strip of coins. Does your rep-
resentation store all the information necessary to play the game? Does
your representation store more information than is necessary? Is it easy to
test for a legal move? Is it easy to test for a win?
2. Develop a new class, CoinStrip, that keeps track of the state of the play-
ing strip. There should be a constructor, which generates a random board.
Another method, toString, returns a string representation of the coin
strip. What other operations seem to be necessary? How are moves per-
formed? How are rules enforced? How is a win detected?
68 Vectors

3. Implement an application whose main method controls the play of a single

game.

Thought Questions. Consider the following questions as you complete the lab:

Hint: When 1. How might one pick game sizes so that, say, one has a 50 percent chance
flipped, the of a game with three coins, a 25 percent chance of a game with four coins,
Belgian Euro is a 12 12 percent chance of a game with five coins, and so on? Would your
heads technique bias your choice of underlying data structure?
149 times
out of 250. 2. How might one generate games that are not immediate wins? Suppose
you wanted to be guaranteed a game with the possibility of n moves?
3. Suppose the computer could occasionally provide good hints. What op-
portunities appear easy to recognize?
4. How might you write a method, computerPlay, where the computer plays
to win?
5. A similar game, called Welter’s Game (after C. P. Welter, who analyzed the
game), allows the coins to pass each other. Would this modification of the
rules change your implementation significantly?

Notes:
Chapter 4
Generics

Concepts: Thank God that

the people running this world
. Motivation for Parameterized Types
are not smart enough
. Simple Parameterized Types
to keep running it forever.
. Parameterization in Vector —Arlo Guthrie

T HE MAIN PURPOSE OF A LANGUAGE is to convey information from one party

to another. Programming languages are no exception. Ideally, a language like
Java lets the programmer express the logic of an algorithm in a natural way,
and the language would identify errors of grammar (i.e., errors of syntax) and
meaning (semantics). When these errors are flagged as the program is com-
piled, we call them compile-time errors. Certain logical errors, of course, do not
appear until the program is run. When these errors are detected (for example,
a division-by-zero, or an object reference through a null pointer) Java generates
runtime errors.1 It is generally believed that the sooner one can detect an error,
the better. So, for example, it is useful to point out a syntax error (“You’ve for-
gotten to declare the variable, cheatCode, you use, here, on line 22.”) where
it occurs rather than a few lines later (“After compiling Lottery.java, we no-
ticed that you mentioned 4 undeclared variables: random, range, trapdoor, and
winner.”). Because a runtime error may occur far away and long after the pro-
gram was written, compile-time errors (that can be fixed by the programming
staff) are considered to be preferable to runtime errors (that must be fixed by
the public relations staff).
Java 5 provides some important language features that shift the detection of
certain important errors from runtime to compile-time. The notion of a generic
class is one of them. This chapter is about building generic classes.

1 Even after considering compile-time and runtime errors, there are many errors that even a run-
ning system cannot detect. For example, undesirable infinite loops (some are desirable) are often
the result of errors in logic that the computer cannot detect. The word “cannot” is quite strong here:
it is impossible to build an environment that correctly identifies any program that loops infinitely
(or even more broadly–fails to halt). This result is due to Alan Turing.
70 Generics

4.1 Motivation (in case we need some)

In Chapter 3 we constructed the Vector class, a general purpose array. Its pri-
mary advantage over arrays is that it is extensible: the Vector can be efficiently
lengthened and shortened as needed. It suffers one important disadvantage:
it is impossible to declare a Vector that contains exactly one type of object.
Ponder this: we almost always declare variables and arrays to contain values of
one particular type, but Vectors hold Objects. As we have seen, an Object can
hold any reference type, so it is hardly a restriction. How can we construct a
Vector restricted to holding just String references?
Of course, you could depend on your naturally good behavior. As long as
the programs you write only add and remove Strings from the Vector, life will
be good. As an example, consider the following (silly) program:
public static void main(String[] args)
{
Vector longWords = new Vector();
int i;
LongWords for (i = 0; i < args.length; i++) {
if (args[i].length() > 4) {
longWords.add(args[i]); // line 12
}
}
...
for (i = 0; i < longWords.size(); i++) {
String word = (String)longWords.get(i); // line 31
System.out.println(word+", length "+word.length());
}
}
This main method builds a Vector of long arguments—Strings longer than 4
characters—and, sometime later, prints out the list of words along with their
respective lengths. If we type
java LongWords Fuzzy Wozzie was a bear
we expect to get
Fuzzy, length 5
Wozzie, length 6
But programming is rarely so successful. Suppose we had instead written
for (i = 0; i < args.length; i++) {
if (args[i].length() > 4) {
longWords.add(args); // line 12
}
}
This mistake is On line 12 we are missing the index from the args array in the call to add.
silly, but most Instead of adding the ith argument, we have added the entire argument array,
mistakes are. every time. Because we have no way to restrict the Vector class, the program
compiles correctly. We only notice the mistake when we type
4.1 Motivation (in case we need some) 71

java LongWords Fuzzy Wozzie had no hair

and get
Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.String;
at LongWords.main(LongWords.java:31)
The problem is eventually recognized (on line 31) when what we thought was
a String (but is actually an array) is removed as an Object (O.K.) and cast to a
String (not O.K.). Notice if our broken program is run with only short words:
java LongWords aye but what a bear that Fuzz was
no runtime error occurs because no words are added to the Vector.

4.1.1 Possible Solution: Specialization

Another solution to our problem would be to create a specialized class, a String-
Vector that was similar to the Vector class in every way, except that Objects
are replaced with Strings. The add method, for example, would be declared:
public class StringVector implements Cloneable
{
protected String elementData[]; // the data
protected int elementCount; // number of elements in vector
... StringVector
public void add(String obj)
{
ensureCapacity(elementCount+1);
elementData[elementCount] = obj;
elementCount++;
}
}
Compare this with the code that appears in Chapter 3 on page 51.
There are several things to note about this approach. First, it works. For
fun, we create a similar (erroneous) program, LongWords2, that makes use of
the StringVector:
public static void main(String[] args)
{
StringVector longWords = new StringVector();
int i;
for (i = 0; i < args.length; i++) { LongWords2
if (args[i].length() > 4) {
longWords.add(args); // line 12
}
}
...
for (i = 0; i < longWords.size(); i++) {
String word = longWords.get(i); // line 31
System.out.println(word+", length "+word.length());
}
}
72 Generics

Instead of using Vector we use StringVector. The compiler knows that the
add method must take a String, so passing an array of Strings to the add
method generates the error:
LongWords2.java:12: cannot find symbol
symbol : method add(java.lang.String[])
location: class StringVector
longWords.add(args);
^

N The success of this technique leads us to the following principle:

NW

NE

Principle 7 Write code to identify errors as soon as possible.

W

E
SW

SE

Here, (1) the actual source of the logical error was identified, and (2) it was
identified at compile-time.
To accomplish this, however, we had to write a new class and modify it
appropriately. This is, itself, an error-prone task. Also, we must rewrite the
class for every every new contained type. Soon we would be overwhelmed by
special-purpose classes. These classes are not related in any way and, it should
be noted, our original class, Vector, would never be used. Imagine the difficulty
of adding a new method to the Vector class that you wished to make available
to each of your specialized versions! A better solution is to create a generic class
or a class parameterized by the type of data it holds.

4.2 Implementing Generic Container Classes

Ideally, we would like to be able to construct container types, like Associations
and Vectors, that hold objects of one or more specific types. At the same time,
we would like to write each of these classes once, probably without prior knowl-
edge of their client applications. If this were possible, we could provide much of
the polymorphic utility of these classes as they were implemented in Chapters 1
and 3, and still identify errors in data types at compile-time. In Java 5, generic
or parameterized data types provide the programmer the necessarily flexibility.

4.2.1 Generic Associations

For simplicity, we first consider the signatures of the protected data and several
of the methods of the Association class, declared using parameterized types:2
package structure5;
public class Association<K,V>
{
Association
2 The remainder of this text describes classes of the structure5 package. The structure package
provides Object-based implementation, for backward comparability with pre-Java5 compilers. Both
the structure and structure5 packages are available in a single jar file, bailey.jar, that may
be inserted in your CLASSPATH.
4.2 Implementing Generic Container Classes 73

protected K theKey; // the key of the key-value pair

protected V theValue; // the value of the key-value pair

/*
for example:
Association<String,Integer> personAttribute =
new Assocation<String,Integer>("Age",34);
*/
public Association(K key, V value)
// pre: key is non-null
// post: constructs a key-value pair

public V getValue()
// post: returns value from association

public K getKey()
// post: returns key from association

public V setValue(V value)

// post: sets association's value to value
}

At the time of their declaration, parameterized class name are followed by a list
of comma-separated type parameters in angle brackets. This book follows the
common convention that type parameters are indicated by single capital Latin
letters.3 In this example, K is a place holder for the type of the association’s
key, while V will be used to represent the actual type of the association’s value.
Within the class definition, these type variables may be used wherever class
names are used: declaring data variables and declaring method parameters and
return values. The one constraint is that

Generic types may not appear in array allocations.

The reason is technical and obviously not of concern in our declaration of

Associations.
The code associated with the generic implementation of the Association
class is, at this point, straightforward. For example, the setValue method would
be written:

public V setValue(V value)

{
V oldValue = theValue;
theValue = value;
return oldValue;
}

3 There is some dispute about this convention. See your instructor. Professional driver, closed
course. Your mileage may vary. Danger, Will Robinson. Some identifiers too small for three year
olds.
74 Generics

Notice that there are no casts in this code: since the value is declared to be of
type V, and since the return value for setValue is the same, no cast is necessary.
The removal of casts is a sign that type checking will happen in the compiler
and not while the program is running.
To make use of the generic version of a class, we must specify the actual
parameter types associated with the formal types demanded by Association.
For example, a new Association between a String and an Integer would be
declared:
Association<String,Integer> personAttribute =
new Assocation<String,Integer>("Age",34);

(Hotdoggers: the 34 here is, yes, autoboxed4 into an Integer.) Of course, if

the Association is declared within a class that is itself parameterized, formal
type parameters may be specified. We will see this on many occasions in future
chapters.

4.2.2 Parameterizing the Vector Class

We now consider the parameterization of a significant container class, Vector.
Because of the way that Vectors are implemented, there will be special techni-
cal details (associated with arrays) that pertain, for the most part, only to the
Yeah, and if we Vector class. Most other structures will avoid these difficulties because they
eat our spinach will make use of parameterized Vectors, and therefore build on the work we
now, we won’t do here. Still, for the purposes of efficiency, it may be useful to declare struc-
get E. coli later. tures that make direct use of the array-based techniques described here.
(The reader may find it useful to review the implementation of the non-
generic Vector as declared in Chapter 3 before following along here, where the
technical details of the Vector implementation will not be reviewed.)
One thing seems fairly obvious: the parameterized Vector class should be
defined in terms of a single type—the type of each element within the Vector.
The declaration of the major method signatures of the Vector class is as follows:
public class Vector<E> extends AbstractList<E> implements Cloneable
{
private Object elementData[]; // the data
Vector protected int elementCount; // number of elements in vector
protected int capacityIncrement; // the rate of growth for vector
protected E initialValue; // new elements have this value
protected final static int defaultCapacity = 10; // def't capacity, must be>0

public Vector()
// post: constructs a vector with capacity for 10 elements

4 Two syntactic features of Java 5 include autoboxing and its inverse, -unboxing. With autobox-

ing, primitive types are automatically “boxed” into their object equivalents if doing so would fix
a type incompatibility. In addition, the corresponding object types will be converted to primitive
equivalents, if necessary.
4.2 Implementing Generic Container Classes 75

public Vector(int initialCapacity)

// pre: initialCapacity >= 0
// post: constructs an empty vector with initialCapacity capacity

public Vector(int initialCapacity, int capacityIncr)

// pre: initialCapacity >= 0, capacityIncr >= 0
// post: constructs an empty vector with initialCapacity capacity
// that extends capacity by capacityIncr, or doubles if 0

public Vector(int initialCapacity, int capacityIncr, E initValue)

// pre: initialCapacity, capacityIncr >= 0
// post: constructs empty vector with capacity that begins at
// initialCapacity and extends by capacityIncr or doubles
// if 0. New entries in vector are initialized to initValue.

public void add(E obj)

// post: adds new element to end of possibly extended vector

public E remove(E element)

// post: element equal to parameter is removed and returned

public boolean contains(E elem)

// post: returns true iff Vector contains the value
// (could be faster, if orderedVector is used)

public E get(int index)

// pre: 0 <= index && index < size()
// post: returns the element stored in location index

public void insertElementAt(E obj, int index)

// pre: 0 <= index <= size()
// post: inserts new value in vector with desired index,
// moving elements from index to size()-1 to right

public E remove(int where)

// pre: 0 <= where && where < size()
// post: indicated element is removed, size decreases by 1

public E set(int index, E obj)

// pre: 0 <= index && index < size()
// post: element value is changed to obj; old value is returned
}
First, it is important to note that the Vector holding objects of type E, the
Vector<E> class, implements AbstractList<E>. Anywhere where an Abstract-
List<E> is required, Vector<E> may be provided.5 The E in the Vector<E>
identifies the formal type parameter, while the E of AbstractList<E> is used

5 This reads like a law journal. A technical point important to note here is that a Vector<E>
does not have any relation to Vector<S> if S is a subclass of E. For example, you cannot assign a
76 Generics

to provide an actual type parameter to the AbstractList class. This, of course,

presumes that the AbstractList class has been implemented using a single
generic type parameter.
At the top of the declaration, we see the instance variables and constants
that are found in a Vector. The initialValue variable holds, for each object,
the value that is used to fill out the Vector as it is extended. Typically (and, in
most constructors, by default) this is null. Clearly, if it is non-null, it should
be a value of type E. The values elementCount, capacityIncrement, and the
constant defaultCapacity are all ints, unconstrained by the choice of the pa-
rameterized type.
The variable elementData is an extensible array (the array the supports the
Vector’s store): it should contain only objects of type E. Again, because of a
technical constraint in Java6 , it is impossible to construct new arrays of any
type that involves a type parameter. We must know, at the time the class is
compiled, the exact type of the array constructed.
But this goes against our desire to construct a parameterized array of type E.
Our “workaround” is to construct an array of type Object, limit the type of the
elements to E with appropriate casts within mutator methods, and to declare the
array private eliminating the possibility that subclasses would be able to store
non-E values within the array.7 When values are retrieved from the array, we
can be confident that they are of the right type, and using casts (that we know
are trivial) we return values of type E.
Let’s look at the details. Here is the implementation of the most general
Vector constructor:
public Vector(int initialCapacity, int capacityIncr, E initValue)
{
Assert.pre(initialCapacity >= 0, "Nonnegative capacity.");
capacityIncrement = capacityIncr;
elementData = new Object[initialCapacity];
elementCount = 0;
initialValue = initValue;
}

The Vector constructor does not mention the <E> type parameter in its name.
Why? The type parameter is obvious because the constructor declaration ap-
pears within the class Vector<E>. When the value is constructed, of course,

Vector<Integer> to a Vector<Number>, even though Integer values may be assigned to Numbers.

You might think about why this is the case: Why is this the case?
6 This constraint is related to the fact that every assignment to the array at runtime forces a runtime

check of the data type. This check is necessitated by the fact that, over time, alternative arrays—
arrays of different base types—can be assigned to a single array reference. Unfortunately Java 5
does not transmit parameterized type information to the running program. This means that param-
eterized types cannot be exactly checked at runtime, but they should be. The easiest way to enforce
correct checking is to make it impossible to construct arrays of parameterized types. We expect
future implementations of Java will address this issue, and that David Ortiz will be the American
League Most Valuable Player, but good things take time.
7 See more about privacy rights in Appendix B.8.
4.2 Implementing Generic Container Classes 77

the actual parameter appears within the new statement (see the example on
page 78). Within the constructor, the supporting array is allocated as a logically
empty array of Object, and the initial value (type E) is cached away within the
type. Is there any way that a non-E value can be stored in elementData, using
this method? No. The method ensures the safety of the types of Vector’s values.
If we ask this question for each mutator method, and the answer is uniformly
No, we can be sure the Vector contains only the correct types.
Now, consider a method that adds a value to the Vector:
public void add(E obj)
// post: adds new element to end of possibly extended vector
{
ensureCapacity(elementCount+1);
elementData[elementCount] = obj;
elementCount++;
}

The Vector is expanded and the new value is appended to the end of the array.
Is there a possibility of a type error, here? In a more extensive review, we might
check to make sure ensureCapacity allows only type E values in elementData.
(It does.) The second and third statements append an object of type E to the ar-
ray, so there is no opportunity for a non-E value to be assigned. Incidentally, one
might wonder what happens if the add method were called with a non-E type. It
is precisely what happens in the StringVector example at the beginning of the
chapter: an exception is raised at the site of the call, during compilation. We’ll
review this in a moment.
Next, we consider the get method. This accessor method retrieves a value
from within the array.
public E get(int index)
{
return (E)elementData[index];
}

By assumption (and eventually through proof) we believe the safety of the array
is intact to this point of access. Every element is of type E, even though it appears
in a more general array of Objects. The cast of the value, while required, will
always hold; runtime type errors will never occur at this point. The method,
then, returns a value of type E.
The set method is a combination of the prior two methods. It is useful to
convince yourself that (1) the method is type-safe, and (2) the cast is necessary
but always successful.
public E set(int index, E obj)
{
Assert.pre(0 <= index && index < elementCount,"index is within bounds");
E previous = (E)elementData[index];
elementData[index] = obj;
return previous;
}
78 Generics

It is, of course, possible to make type mistakes when using the Vector class.
They fall, however, into two distinct categories. Vector implementation mis-
takes may allow elements of types other than E into the array. These mistakes
are always possible, but they are the responsiblity of a single programmer. Good
design and testing will detect and elminate these compile-time and runtime er-
rors quickly. The second class of errors are abuses of the Vector<E> class by
the client application. These errors are unfortunate, but they will be reported
at compile-time at the appropriate location, one that focuses the programmer’s
attention on the mistake.
We can now test our new implementation on working code and then attempt
to break it. In LongWords3, we consider, yet again, the implementation of our
program that checks for long argument words. The implementation makes use
of a Vector<String> as follows:
public static void main(String[] args)
{
Vector<String> longWords = new Vector<String>();
LongWords3 int i;
for (i = 0; i < args.length; i++) {
if (args[i].length() > 4) {
longWords.add(args[i]); // line 12
}
}
...
for (i = 0; i < longWords.size(); i++) {
String word = longWords.get(i); // line 31
System.out.println(word+", length "+word.length());
}
}

Because the Vector<String> only contains String elements, there is no need

for a cast to a String on line 31. This makes the running program safer and
faster.
If the add statement were incorrectly written as:
longWords.add(args); // line 12: woops!

the compiler would be confused—we’re passing an array of Strings to a class

that has only methods to add Strings. The resulting error is, again, a missing
symbol (i.e. a missing method) error:
LongWords3.java:12: cannot find symbol
symbol : method add(java.lang.String[])
location: class java.util.Vector<java.lang.String>
longWords.add(args);
^

The compiler cannot find an appropriate add method.

By the way, you can get the behavior of an unparameterized Vector class by
simply using Vector<Object>.
4.2 Implementing Generic Container Classes 79

4.2.3 Restricting Parameters

There are times when it is useful to place restrictions on type parameters to
generic classes. For example, we may wish to implement a class called a Num-
ericalAssociation, whose keys are always some specific subtype of java.lang.Number.
This would, for example, allow us to make an assumption that we could com-
pute the integer value by calling intValue on the key. Examples of declarations
of NumericalAssociations include: “numerical”
means
NumericalAssociation<Integer,String> i;
“numeric”
NumericalAssociation<Double,Integer> d;
NumericalAssociation<Number,Object> n;
NumericalAssociation<BigInteger,Association<String,Object>> I;
We declare the NumericalAssociation class as follows:
public class NumericalAssociation<K extends Number,V>
extends Association<K,V>
{
public NumericalAssociation(K key, V value)
// pre: key is a non-null value of type K
// post: constructs a key-value pair
{
super(key,value);
}

public int keyValue()

// post: returns the integer that best approximates the key
{
return getKey().intValue();
}
}
The extends keyword in the type parameter for the class indicates that type K is
any subclass of Number (including itself). Such a constraint makes it impossible
to construct an class instance where K is a String because String is not a
subclass of Number. Since the Number class implements the intValue method,
we can call intValue on the key of our new class. This type restriction is called
a type bound.
Realize, of course, that the type bound bounds the type of class constructed.
Once the class is constructed, the particular types used may be more restric-
tive. The class NumericalAssociation<Double,Object> supports keys of type
Double, but not Integer. The NumericalAssociation<Number,Object> is the
most general form of the class.
By the way, the same extends type bound can be used to indicate that a type
variable implements a specific interface. An Association whose key is a Number
and whose value implements a Set of keys is declared as
public class NSAssociation<K extends Number, V extends Set<K>>
extends Association<K,V>
We have only touched on the complexities of parametric type specification.
80 Generics

4.3 Conclusions
When we write data structures, we often write them for others. When we write
for others, we rarely know the precise details of the application. It is important
that we write our code as carefully as possible so that semantic errors associated
with our data structures occur as early as possible in development and as close
as possible to the mistake.
We have seen, here, several examples of generic data types. The Association
class has two type parameters, and is typical in terms of the simplicity of writ-
ing generalized code that can be tailored for use in specific applications. Formal
type parameters hold the place for actual type parameters to be specified later.
Code is written just as before, but with the knowledge that our structures will
not sacrifice the type-safety of their client applications.
There is one “fly in the ointment”: we cannot construct arrays of any type
that involves a formal type parameter. These situations are relatively rare and,
for the most part, can be limited to the some carefully crafted code in the Vector
class. When array-like storage is required in the future, use of the extensible
Vector class has one more advantage over arrays: it hides the difficulties of
manipulating generic arrays.
Type bounds provide a mechanism to constrain the type parameters that ap-
pear in generic class specifications. These bounds can be disturbingly complex.
The remainder of this text demonstrates the power of the generic approach
to writing data structures. While the structure of these data types becomes
increasingly technical, the nature of specifying these structures in a generic and
flexible manner remains quite simple, if not natural.
Chapter 5
Design Fundamentals

Concepts:
. Asymptotic analysis and big-O notation We shape clay into a pot,
but it is the emptiness inside
. Time-space trade-off
that holds whatever we want.
. Back-of-the-envelope estimations —Lao Tzu
. Recursion and Induction

P ROGRAMMERS ARE CRAFTSMEN . Their medium—their programming language—

often favors no particular design and pushes for an individual and artistic de-
cision. Given the task of implementing a simple program, any two individuals
are likely to make different decisions about their work. Because modern lan-
guages allow programmers a great deal of expression, implementations of data
structures reflect considerable personal choice.
Some aspects of writing programs are, of course, taught and learned. For
example, everyone agrees that commenting code is good. Programmers should
write small and easily understood procedures. Other aspects of the design of
programs, however, are only appreciated after considerable design experience.
In fact, computer science as a whole has only recently developed tools for un-
derstanding what it means to say that an algorithm is “implemented nicely,” or
that a data structure “works efficiently.” Since many data structures are quite
subtle, it is important to develop a rich set of tools for developing and analyzing
their performance.
In this chapter, we consider several important conceptual tools. Big-O com-
plexity analysis provides a means of classifying the growth of functions and,
therefore, the performance of the structures they describe. The concepts of
recursion and self-reference make it possible to concisely code solutions to com-
plex problems, and mathematical induction helps us demonstrate the important
properties—including trends in performance—of traditional data structures. Fi-
nally, notions of symmetry and friction help us understand how to design data
structures so that they have a reasonable look and feel.

5.1 Asymptotic Analysis Tools

We might be satisfied with evaluating the performance or complexity of data
structures by precisely counting the number of statements executed or objects
82 Design Fundamentals

referenced. Yet, modern architectures may have execution speeds that vary as
much as a factor of 10 or more. The accurate counting of any specific kind of
operation alone does not give us much information about the actual running
time of a specific implementation. Thus, while detailed accounting can be use-
ful for understanding the fine distinctions between similar implementations, it
is not generally necessary to make such detailed analyses of behavior. Distinc-
tions between structures and algorithms, however, can often be identified by
observing patterns of performance over a wide variety of problems.

5.1.1 Time and Space Complexity

What concerns the designer most are trends suggested by the various perfor-
mance metrics as the problem size increases. Clearly, an algorithm that takes
time proportional to the problem size degrades more slowly than algorithms
that decay quadratically. Likewise, it is convenient to agree that any algorithm
that takes time bounded by a polynomial in the problem size, is better than
one that takes exponential time. Each of these rough characterizations—linear,
quadratic, and so on—identifies a class of functions with similar growth behav-
ior. To give us a better grasp on these classifications, we use asymptotic or big-O
analysis to help us to describe and evaluate a function’s growth.

Definition 5.1 A function f (n) is O(g(n)) (read “order g” or “big-O of g”), if and
only if there exist two positive constants, c and n0 , such that

|f (n)| ≤ c · g(n)

for all n ≥ n0 .

In this text, f will usually be a function of problem size that describes the utiliza-
tion of some precious resource (e.g., time or space). This is a subtle definition
(and one that is often stated incorrectly), so we carefully consider why each of
the parts of the definition is necessary.
Most importantly, we would like to think of g(n) as being proportional to an
upper bound for f (n) (see Figure 5.1). After some point, f (n) does not exceed
an “appropriately scaled” g(n). The selection of an appropriate c allows us to
enlarge g(n) to the extent necessary to develop an upper bound. So, while g(n)
may not directly exceed f (n), it might if it is multiplied by a constant larger
than 1. If so, we would be happy to say that f (n) has a trend that is no worse
than that of g(n). You will note that if f (n) is O(g(n)), it is also O(10 · g(n)) and
O(5 + g(n)). Note, also, that c is positive. Generally we will attempt to bound
f (n) by positive functions.
Second, we are looking for long-term behavior. Since the most dramatic
growth in functions is most evident for large values, we are happy to ignore
“glitches” and anomalous behavior up to a certain point. That point is n0 . We
Nails = proofs. do not care how big n0 must be, as long as it can be nailed down to some fixed
value when relating specific functions f and g.
5.1 Asymptotic Analysis Tools 83

g(n)
g(n)
f(n)
f(n) g(n)

f(n)
n n n

Figure 5.1 Examples of functions, f (n), that are O(g(n)).

Third, we are not usually interested in whether the function f (n) is negative
or positive; we are just interested in the magnitude of its growth. In reality, most
of the resources we consider (e.g., time and space) are measured as positive
values and larger quantities of the resource are consumed as the problem grows
in size; growth is usually positive.
Most functions we encounter fall into one of a few categories. A function
that is bounded above by a constant is classified as O(1).1 The constant factor
can be completely accounted for in the value of c in Definition 5.1. These func-
tions measure size-independent characteristics of data structures. For example,
the time it takes to assign a value to an arbitrary element of an array of size n
is constant. What’s your
When a function grows proportionately to problem size, or linearly, we ob- best guess for
serve it is O(n). Depending on what’s being measured, this can be classified as the time to
“nice behavior.” Summing the values in an n-element array, for example, can be assign a value?
1
second?
accomplished in linear time. If we double the size of the array, we expect the 1000
1
sec.?
time of the summation process to grow proportionately. Similarly, the Vector 1000000
1
s.?
takes linear space. Most methods associated with the Vector class, if not con- 1000000000

stant, are linear in time and space. If we develop methods that manipulate
the n elements of a Vector of numbers in superlinear time—faster than linear
growth—we’re not pleased, as we know it can be accomplished more efficiently.
Other functions grow polynomially and are O(nc ), where c is some constant
greater than 1. The function n2 + n is O(n2 ) (let c = 2 and n0 = 1) and
therefore grows as a quadratic. Many simple methods for sorting n elements of
an array are quadratic. The space required to store a square matrix of size n
takes quadratic space. Usually, we consider functions with polynomial growth
to be fairly efficient, though we would like to see c remain small in practice. Grass could be
Because a function nc−1 is O(n · nc−1 ) (i.e., O(nc )), we only need consider the greener.
growth of the most significant term of a polynomial function. (It is, after all,
most significant!) The less significant terms are ultimately outstripped by the
leading term.

1 It is also O(13), but we try to avoid such distractions.

84 Design Fundamentals

5
n! n log( n)
n
4

3
2
2n n
sqrt( n)
2

1
log(n)

0
0 1 2 3 4 5

Figure 5.2 Near-origin details of common curves. Compare with Figure 5.3.

100
2n

n! n
80
n log( n)
n2
60

40

20
sqrt( n)
log( n)
0
0 20 40 60 80 100

Figure 5.3 Long-range trends of common curves. Compare with Figure 5.2.
5.1 Asymptotic Analysis Tools 85

Some functions experience exponential growth (see Figures 5.2 and 5.3).
The functions are O(cn ), where c is a constant greater than 1. Enumerating
all strings of length n or checking topological equivalence of circuits with n
devices are classic examples of exponential algorithms. Constructing a list of
the n-digit palindromes requires exponential time and space. The demands of “2002” is a
an exponential process grow too quickly to make effective use of resources. palindrome.
As a result, we often think of functions with exponential behavior as being
intractable. In the next section we will see that some recursive solutions to
problems are exponential. While these solutions are not directly useful, simple
insights can sometimes make these algorithms efficient.

5.1.2 Examples
A “Difference Table”
Suppose we’re interested in printing a 10 by 10 table of differences between
two integers (row-col) values. Each value in the table corresponds to the result
of subtracting the row number from the column number:

0 -1 -2 -3 -4 -5 -6 -7 -8 -9
1 0 -1 -2 -3 -4 -5 -6 -7 -8
2 1 0 -1 -2 -3 -4 -5 -6 -7 Analysis
3 2 1 0 -1 -2 -3 -4 -5 -6
4 3 2 1 0 -1 -2 -3 -4 -5
5 4 3 2 1 0 -1 -2 -3 -4
6 5 4 3 2 1 0 -1 -2 -3
7 6 5 4 3 2 1 0 -1 -2
8 7 6 5 4 3 2 1 0 -1
9 8 7 6 5 4 3 2 1 0

As with most programs that generate two-dimensional output, we consider the

use of a nested pair of loops:

public static void diffTable(int n)

// pre: n >= 0
// post: print difference table of width n
{
for (int row = 1; row <= n; row++) // 1
{
for (int col = 1; col <= n; col++) // 2
{
System.out.print(row-col+" "); // 3
}
System.out.println(); // 4
}
}

Each of the loops executes n times. Since printing a value (line 3) takes constant
time c1 , the inner loop at line 2 takes c1 n time. If line 4 takes constant time c2 ,
86 Design Fundamentals

then the outer loop at line 1 takes n(c1 n+c2 ) = c1 n2 +c2 n time. This polynomial
is clearly O(n2 ) (take c = c1 + c2 and n0 = 1). Doubling the problem size
approximately quadruples the running time.
As a rule of thumb, each loop that performs n iterations multiplies the com-
plexity of each iteration by a factor of n. Nested loops multiply the complexity
of the most deeply nested code by another power of n. As we have seen, loops
doubly nested around a simple statement often consume quadratic time.
Since there are only three variables in our difference method, it takes con-
stant space—an amount of space that is independent of problem size.

A Multiplication Table
Unlike the difference operator, the multiplication operator is commutative, and
the multiplication table is symmetric. Therefore, when printing a multiplication
table of size n, only the “lower triangular” region is necessary:
1
2 4
3 6 9
4 8 12 16
5 10 15 20 25
6 12 18 24 30 36
7 14 21 28 35 42 49
8 16 24 32 40 48 56 64
9 18 27 36 45 54 63 72 81
10 20 30 40 50 60 70 80 90 100

Here is a Java method to print the above table:

public static void multTable(int n)
// pre: n >= 0
// post: print multiplication table
{
for (int row = 1; row <= n; row++) // 1
{
for (int col = 1; col <= row; col++) // 2
{
System.out.print(row*col+" "); // 3
}
System.out.println(); // 4
}
}

Clearly, this table can be printed at least as fast as our difference table—it has
about half the entries—so it is, similarly, O(n2 ). Can this limit be improved? If
lines 3 and 4 take constant times c1 and c2 , respectively, then the overall time is
approximately
c1 n(n + 1) c1 c1
(1c1 + c2 ) + (2c1 + c2 ) + · · · + (nc1 + c2 ) = + nc2 = n2 + (c2 + )n
2 2 2
5.1 Asymptotic Analysis Tools 87

Clearly, no linear function will bound this function above, so the bound of O(n2 )
is a good estimate. Notice that we have, essentially, used the fastest growing
term of the polynomial—n2 .
Notice that both of these programs print an “area” of values, each of which
can be computed in constant time. Thus, the growth rate of the function is the
growth rate of the area of the output—which is O(n2 ).

Building a Vector of Values

Often, it is useful to build a Vector containing specific values. For the purposes
of this problem, we will assume the values are integers between 0 and n −
1, inclusive. Our first (and best) attempt expands the Vector in the natural
manner:

public static Vector<Integer> buildVector1(int n)

// pre: n >= 0
// post: construct a vector of size n of 1..n
{
Vector<Integer> v = new Vector<Integer>(n); // 1
for (int i = 0; i < n; i++) // 2
{
v.add(i); // 3
}
return v; // 4
}

We will assume (correctly) that lines 1 and 4 take constant time. The loop at
line 2, however, takes n times the length of time it takes to add a single element.
Review of that code will demonstrate that the addition of a new element to a
Vector takes constant time, provided expansion is not necessary. Thus, the total
running time is linear, O(n). Notice that the process of building this Vector
requires space that is linear as well. Clearly, if the method’s purpose is to spend
time initializing the elements of a Vector, it would be difficult for it to consume
space at a faster rate than time.
A slightly different approach is demonstrated by the following code:

public static Vector<Integer> buildVector2(int n)

// pre: n >= 0
// post: construct a vector of size n of 1..n
{
Vector<Integer> v = new Vector<Integer>(n); // 1
for (int i = 0; i < n; i++) // 2
{
v.add(0,i); // 3
}
return v; // 4
}
88 Design Fundamentals

All the assumptions of buildVector1 hold here, except that the cost of inserting
a value at the beginning of a Vector is proportional to the Vector’s current
length. On the first insertion, it takes about 1 unit of time, on the second, 2
units, and so on. The analysis of this method, then, is similar to that of the
triangular multiplication table. Its running time is O(n2 ). Its space utilization,
however, remains linear.

Printing a Table of Factors

Suppose we are interested in storing a table of factors of numbers between 1
and n. The beginning of such a table—the factors of values between 1 and
10—includes the following values:
1
1 2
1 3
1 2 4
1 5
1 2 3 6
1 7
1 2 4 8
1 3 9
1 2 5 10

How much space must be reserved for storing this table? This problem looks a
little daunting because the number of factors associated with each line varies,
but without any obvious pattern. Here’s a program that generates the desired
table:
public static Vector<Vector<Integer>> factTable(int n)
// pre: n > 0
// post: returns a table of factors of values 1 through n
{
Vector<Vector<Integer>> table = new Vector<Vector<Integer>>();
for (int i = 1; i <= n; i++)
{
Vector<Integer> factors = new Vector<Integer>();
for (int f = 1; f <= i; f++)
{
if ((i % f) == 0) {
factors.add(f);
}
}
table.add(factors);
}
return table;
}

To measure the table size we consider those lines that mention f as a factor.
Clearly, f appears on every f th line. Thus, over n lines of the table there are
5.1 Asymptotic Analysis Tools 89

1
1
1 1
2
1
1 1
3 1
4 1 1
5 6 7 8
0
0 1 2 3 4 5 6 7 8 9 10

P8 1
Figure 5.4 Estimating the sum of reciprocal values. Here, x=1 x
≈ 2.72 is no more
R8
than 1 + 1 x1 dx = 1 + ln 8 ≈ 3.08.

n
no more than f lines that include f . Thus, we have as an upper bound on the
table size:
n n n n n
+ + + ··· + +
1 2 3 n−1 n
Factoring out n we have:
 
1 1 1 1 1
n + + + ··· + +
1 2 3 n−1 n

We note that these fractions fall on the curve x1 (see Figure 5.4). We may
compute the area of the curve—an upper bound on the sum—as:

n  Z n 
X 1 1
n ≤ n 1+ dx
x=1
x 1 x
≤ n(1 + ln n − ln 1)
≤ O(n ln n)

The size of the table grows only a little faster than linearly. The time necessary
to create the table, of course, is O(n2 ) since we check n factors for number n.

√
Exercise 5.1 Slightly modify the method to construct the same table, but in O(n n)
time.

Exercise 5.2 Rewrite the method to construct the same table, but in O(n ln n)
time.
90 Design Fundamentals

Finding a Space in a String

Some problems appear to have behavior that is more variable than the examples
we have seen so far. Consider, for example, the code to locate the first space in
a string:
static int findSpace(String s)
// pre: s is a string, possibly containing a space
// post: returns index of first space, or -1 if none found
{
int i;
for (i = 0; i < s.length(); i++)
{
if (' ' == s.charAt(i)) return i;
}
return -1;
}

This simple method checks each of the characters within a string. When one
is found to be a space, the loop is terminated and the index is returned. If, of
course, there is no space within the string, this must be verified by checking
each character. Clearly, the time associated with this method is determined by
the number of loops executed by the method. As a result, the time taken is
linear in the length of the string.
We can, however, be more precise about its behavior using best-, worst-, and
average-case analyses:
Best case. The best-case behavior is an upper bound on the shortest time that
any problem of size n might take. Usually, best cases are associated with
particularly nice arrangements of values—here, perhaps, a string with a
space in the first position. In this case, our method takes at most constant
time! It is important to note that the best case must be a problem of size n.
Worst case. The worst-case behavior is the longest time that any problem of
size n might take. In our string-based procedure, our method will take
the longest when there is no space in the string. In that case, the method
consumes at most linear time. Unless we specify otherwise, we will use
the worst-case consumption of resources to determine the complexity.
Average case. The average-case behavior is the complexity of solving an “av-
erage” problem of size n. Analysis involves computing a weighted sum of
the cost (in time or space) of problems of size n. The weight of each prob-
lem is the probability that the problem would occur. If, in our example,
we knew (somehow) that there was exactly one space in the string, and
that it appears in any of the n positions with equal probability, we would
deduce that, on average,
n
X 1 1 1 1 1 n(n + 1) n+1
i = · 1 + · 2 + ··· + · n = · =
i=1
n n n n n 2 2
5.1 Asymptotic Analysis Tools 91

iterations would be necessary to locate the space. Our method has linear
average-time complexity. If, however, we knew that the string was English
prose of length n, the average complexity would be related to the average
length of the first word, a value easily bounded above by a constant (say,
10). The weights of the first few terms would be large, while the weights
associated with a large number of iterations or more would be zero. The German prose
average complexity would be constant. (In this case, the worst case would may require
be constant as well.) Obviously determining the average-case complexity larger
requires some understanding of the desired distributions of data. constants.

Best-, worst-, and average-case analyses will be important in helping us eval-

uate the theoretical complexities of the structures we develop. Some care, how-
ever, must be used when determining the growth rates of real Java. It is tempt-
ing, for example, to measure the space or time used by a data structure and fit a
curve to it in hopes of getting a handle on its long-term growth. This approach
should be avoided, if possible, as such statements can rarely be made with much
security. Still, such techniques can be fruitfully used to verify that there is no
unexpected behavior.

5.1.3 The Trading of Time and Space

Two resources coveted by programmers are time and space. When programs
are run, the algorithms they incorporate and the data structures they utilize
work together to consume time. This time is directly due to executing machine
instructions. The fewer instructions executed, the faster the program goes.
Most of us have had an opportunity to return to old code and realize that
useless instructions can be removed. For example, when we compute the ta-
ble factors, we realized that we could speed up the process by checking fewer
values for divisibility. Arguably, most programs are susceptible to some of this
“instruction weeding,” or optimization. On the other hand, it is clear that there
must be a limit to the extent that an individual program can be improved. For
some equivalent program, the removal of any statement causes the program to
run incorrectly. This limit, in some sense, is an information theoretic limit: given
the approach of the algorithm and the design of a data structure, no improve-
ments can be made to the program to make it run faster. To be convinced that
there is a firm limit, we would require a formal proof that no operation could be
avoided. Such proofs can be difficult, especially without intimate knowledge of
the language, its compiler, and the architecture that supports the running code.
Nonetheless, the optimization of code is an important feature of making pro-
grams run quickly. Engineers put considerable effort into designing compilers
to make automated optimization decisions. Most compilers, for example, will
not generate instructions for dead code—statements that will never be executed.
In the following Java code, for example, it is clear that the “then” portion of this
code may be removed without fear:
92 Design Fundamentals

if (false)
{
System.out.println("Man in the moon.");
} else {
System.out.println("Pie in the sky.");
}
After compiler optimizations have been employed, though, there is a limit that
can be placed on how fast the code can be made to run. We will assume—
whenever we consider a time–space trade-off—that all reasonable efforts have
been made to optimize the time and space utilization of a particular approach.
Notice, however, that most optimizations performed by a compiler do not sig-
nificantly affect the asymptotic running time of an algorithm. At most, they tend
to speed up an algorithm by a constant factor, an amount that is easily absorbed
in any theoretical analysis using big-O methods.
Appropriately implemented data structures can, however, yield significant
performance improvements. Decisions about data structure design involve weigh-
ing—often using results of big-O analysis—the time and space requirements of
a structure used to solve a problem. For example, in the Vector class, we opted
to maintain a field, elementCount, that kept track of how many elements within
the underlying array are actually being used. This variable became necessary
when we realized that as the Vector expanded, the constant reallocation of the
underlying memory could lead to quadratic time complexity over the life of the
Vector. By storing a little more information (here, elementCount) we reduce
the total complexity of expanding the Vector—our implementation, recall, re-
quires O(1) data-copying operations as the Vector expands. Since Vectors are
very likely to expand in this way, we find it worthwhile to use this extra space.
In other situations we will see that the trade-offs are less obvious and sometimes
lead to the development of several implementations of a single data structure
designed for various uses by the application designer.
The choice between implementations is sometimes difficult and may require
analysis of the application: if Vector’s add method is to be called relatively in-
frequently, the time spent resizing the structure is relatively insignificant. On the
other hand, if elements are to be added frequently, maintaining elementCount
saves time. In any case, the careful analysis of trade-off between time and space
is an important part of good data structure design.

5.1.4 Back-of-the-Envelope Estimations

A skill that is useful to the designer is the ability to develop good estimates
of the time and space necessary to run an algorithm or program. It is one
thing to develop a theoretical analysis of an algorithm, but it is quite another to
develop a sense of the actual performance of a system. One useful technique is
to apply any of a number of back-of-the-envelope approximations to estimating
the performance of an algorithm.
The numbers that programmers work with on a day-to-day basis often vary
in magnitude so much that it is difficult to develop much of a common sense
5.1 Asymptotic Analysis Tools 93

for estimating things. It is useful, then, to keep a store of some simple figures
that may help you to determine the performance—either in time or space—of a
project. Here are some useful rules of thumb:

• Light travels one foot in a nanosecond (one billionth of a second).

• Approximately π (≈ 3.15) hundredths of a second is a nanoyear (one

billionth of a year).

• It takes between 1 and 10 nanoseconds (ns) to store a value in Java. Basic

math operations take a similar length of time.

• An array assignment is approximately twice as slow as a regular assign-

ment.

• A Vector assignment is approximately 50 times slower than a regular

assignment.

• Modern computers execute 1 billion instructions per second.

• A character is represented by 8 bits (approximately 10).

• An Ethernet network can transmit at 100 million bits per second (expected
throughput is nearer 10 million bits).

• Fewer than 100 words made up 50 percent of Shakespeare’s writing; they

have an average length of π. A core of 3000 words makes up 90 percent
of his vocabulary; they have an average of 5.5 letters.

As an informal example of the process, we might attempt to answer the

question: How many books can we store on a 10 gigabyte hard drive? First
we will assume that 1 byte is used to store a character. Next, assuming that an
average word has about 5 characters, and that a typewritten page has about 500
words per typewritten page, we have about 2500 characters per page. Another
approximation might suggest 40 lines per page with 60 characters per line,
or 2400 characters per page. For computational simplicity, we keep the 2500
character estimate. Next, we assume the average book has, say, 300 pages, so
that the result is 0.75 million bytes required to store a text. Call it 1 million. A
10 gigabyte drive contains approximately 10 billion characters; this allows us
to store approximately 10 thousand books.
A dictionary is a collection of approximately 250,000 words. How long
might it take to compute the average length of words appearing in the dic-
tionary? Assume that the dictionary is stored in memory and that the length
of a word can be determined in constant time—perhaps 10 microseconds (µs).
The length must be accumulated in a sum, taking an additional microsecond
per word—let’s ignore that time. The entire summation process takes, then, 2.5
seconds of time. (On the author’s machine, it took 3.2 seconds.)
94 Design Fundamentals

Exercise 5.3 How many dots can be printed on a single sheet of paper? Assume,
for example, your printer prints at 500 dots per inch. If a dot were used to represent
a bit of information, how much text could be encoded on one page?

As you gain experience designing data structures you will also develop a
sense of the commitments necessary to support a structure that takes O(n2 )
space, or an algorithm that uses O(n log n) time.

5.2 Self-Reference
One of the most elegant techniques for constructing algorithms, data structures,
and proofs is to utilize self-reference in the design. In this section we discuss ap-
plications of self-reference in programming—called recursion—and in proofs—
called proof by induction. In both cases the difficulties of solving the problem
outright are circumvented by developing a language that is rich enough to sup-
port the self-reference. The result is a compact technique for solving complex
problems.

5.2.1 Recursion
When faced with a difficult problem of computation or structure, often the best
solution can be specified in a self-referential or recursive manner. Usually, the dif-
ficulty of the problem is one of management of the resources that are to be used
by the program. Recursion helps us tackle the problem by focusing on reducing
the problem to one that is more manageable in size and then building up the
answer. Through multiple, nested, progressive applications of the algorithm, a
solution is constructed from the solutions of smaller problems.

Summing Integers
We first consider a simple, but classic, problem: suppose we are interested in
computing the sum of the numbers from 0 through n.
n
X
i = 0 + 1 + 2 + 3 + ··· + n
i=0

One approach to the problem is to write a simple loop that over n iterations
accumulates the result.

public static int sum1(int n)

// pre: n >= 0
// post: compute the sum of 0..n
Recursion {
int result = 0;
for (int i = 1; i <= n; i++)
{
5.2 Self-Reference 95

result = result + i;
}
return result;
}

The method starts by setting a partial sum to 0. If n is a value that is less than
1, then the loop will never execute. The result (0) is what we expect if n = 0. If
n is greater than 0, then the loop executes and the initial portion of the partial
sum is computed. After n − 1 loops, the sum of the first n − 1 terms is computed.
The nth iteration simply adds in n. When the loop is finished, result holds the
sum of values 1 through n. We see, then, that this method works as advertised
in the postcondition.
Suppose, now, that a second programmer is to solve the same problem. If
the programmer is particularly lazy and has access to the sum1 solution the
following code also solves the problem:

public static int sum2(int n)

// pre: n >= 0
// post: compute the sum of 0..n
{
if (n < 1) return 0;
else return sum1(n-1) + n;
}

For the most trivial problem (any number less than 1), we return 0. For all other
values of n, the programmer turns to sum1 to solve the next simplest problem
(the sum of integers 0 through n − 1) and then adds n. Of course, this algorithm
works as advertised in the postcondition, because it depends on sum1 for all but
the last step, and it then adds in the correct final addend, n.
Actually, if sum2 calls any method that is able to compute the sum of numbers
0 through n−1, sum2 works correctly. But, wait! The sum of integers is precisely
what sum2 is supposed to be computing! We use this observation to derive, then,
the following self-referential method:

public static int sum3(int n)

// pre: n >= 0
// post: compute the sum of 0..n
{
if (n < 1) return 0; // base case
else return sum3(n-1) + n; // reduction, progress, solution
}

This code requires careful inspection (Figure 5.5). First, in the simplest or base
cases (for n < 1), sum3 returns 0. The second line is only executed when n ≥ 1.
It reduces the problem to a simpler problem—the sum of integers between 0 and
n − 1. As with all recursive programs, this requires a little work (a subtraction)
to reduce the problem to one that is closer to the base case. Considering the
problem n + 1 would have been fatal because it doesn’t make suitable progress
96 Design Fundamentals

Compute sum3(100):
1. Compute sum3(99)
2. Add in 100 Progress
Work 3. Return 1+..+98
+99+100
Compute sum3(99):
1. Compute sum3(98)
2. Add in 99
3. Return 1+...+98+99 Base case

Compute sum3(98):
1. Compute sum3(97)
2. Add in 98
3. Return 1+...+98
Compute sum3(0):
Trivially return 0

Figure 5.5 The “unrolling” of a procedure to recursively sum integers. Rightward

arrows break the problem down; leftward arrows build up the solution.

toward the base case. The subproblem is passed off to another invocation of
sum3. Once that procedure computes its result (either immediately or, if nec-
essary, through further recursion), a little more work is necessary to convert
the solution of the problem of size n − 1 into a solution for a problem of size
n. Here, we have simply added in n. Notice the operation involved in build-
ing the answer (addition) opposes the operation used to reduce the problem
N
(subtraction). This is common in recursive procedures.
NW

NE
W

Principle 8 Recursive structures must make “progress” toward a “base case.”

E
SW

SE

We cast this principle in terms of “structures” because much of what we say

about self-referential execution of code can be applied to self-referential struc-
turing of data. Most difficulties with recursive structures (including recursive
methods) stem from either incorrectly stating the base case or failing to make
proper progress.

Inserting a Value into a Vector

Recursion is a natural method for accomplishing many complicated tasks on
Vectors and arrays. For example, the add(index,object) method of the Vector
class discussed on page 51 can be written as a recursive procedure. The essen-
tial concept is to insert the value into the Vector only after having moved the
previous value out of the way. That value is inserted at the next larger location.
This leads us to the following alternative to the standard Vector method:
Vector
5.2 Self-Reference 97

public void add(int index, E value)

// pre: 0 <= index <= size()
// post: inserts new value in vector with desired index
// moving elements from index to size()-1 to right
{
if (index >= size()) {
add(value); // base case: add at end
} else {
E previous = get(index); // work
add(index+1,previous); // progress through recursion
set(index,value); // work
}
}

Note that the base case is identified through the need to apply a trivial operation
rather than, say, the size of the index. Indeed, progress is determined by how
close the index gets to the size of the Vector. Again, this is a linear or O(n)
process.

Printing a Vector of Values

In the previous example, the recursive routine was suitable for direct use by
the user. Often, though, recursion demands additional parameters that encode,
in some way, progress made toward the solution. These parameters can be
confusing to users who, after all, are probably unaware of the details of the
recursion. To avoid this confusion, we “wrap” the call to a protected recursive
method in a public method. This hides the details of the initial recursive method
call. Here, we investigate a printing extension to the Vector class:

public void print()

// post: print the elements of the vector
{
printFrom(0);
}

protected void printFrom(int index)

// pre: index <= size()
// post: print elements indexed between index and size()
{
if (index < size()) {
System.out.println(get(index));
printFrom(index+1);
}
}

The print method wraps or hides the call to the recursive printFrom method.
The recursive method accepts a single parameter that indicates the index of
the first element that should be printed out. As progress is made, the initial
98 Design Fundamentals

index increases, leading to linear performance. To print the entire Vector, the
recursive method is called with a value of zero.
It would appear that the base case is missing. In fact, it is indicated by the
failure of the if statement. Even though the base case is to “do nothing,” the if
statement is absolutely necessary. Every terminating recursive method should
have some conditional statement.
PrintFrom is an example of a tail recursive method. Any recursion happens
just before exiting from the method. Tail recursive methods are particularly nice
because good compilers can translate them into loops. Each iteration of the loop
simulates the computation and return of another of the nested recursive proce-
dure calls. Since there is one call for each of the n values, and the procedure
performs a constant amount of work, the entire process takes O(n) time.

Exercise 5.4 Write a recursive method to print out the characters of a string with
spaces between characters. Make sure your method does not print a leading or
tailing space, unless it is a leading or trailing character of the original string.

Computing Change in Postage Stamps

Suppose, when receiving change at the post office, you wished to be paid your
change in various (useful) stamps. For example, at current rates, you might
be interested in receiving either 39 cent stamps, 24 cent postcards, or penny
stamps (just in case of a postage increase). For a particular amount, what is the
smallest number of stamps necessary to make the change?
This problem is fairly complex because, after all, the minimum number of
stamps needed to make 50 cents involves 4 stamps—two postcard stamps and
two penny stamps—and not 12—a 39 cent stamp and 11 penny stamps. (The
latter solution might be suggested by postal clerks used to dealing with U.S.
coinage, which is fairly easily minimized.) We will initially approach this prob-
lem using recursion. Our solution will only report the minimum number of
stamps returned. We leave it as an exercise to report the number of each type
of stamp (consider Problem 5.22); that solution does not greatly change the
approach of the problem.
If no change is required—a base case—the solution is simple: hand the cus-
tomer zero stamps. If the change is anything more, we’ll have to do some work.
Consider the 70 cent problem. We know that some stamps will have to be given
to the customer, but not the variety. We do know that the last stamp handed to
the customer will either be a penny stamp, a 26 cent step, or a 41 cent stamp.
If we could only solve three smaller minimization problems—the 69 cent prob-
lem, the 34 cent problem, and the 29 cent problem—then our answer would
be one stamp more than the minimum of the answers to those three problems.
(The answers to the three problems are 4, 9, and 4, respectively, so our answer
should be 5.) Of course, we should ignore meaningless reduced problems: the
−6 cent problem results from considering handing a 26 cent stamp over to solve
the 20 cent problem.
Here is the stampCount method that computes the solution:
Recursive-
Postage
5.2 Self-Reference 99

public final static int LETTER=41;

public final static int CARD=26;
public final static int PENNY=1;

public static int stampCount(int amount)

// pre: amount >= 0
// post: return *number* of stamps needed to make change
// (only use letter, card, and penny stamps)
{
int minStamps;
Assert.pre(amount >= 0,"Reasonable amount of change.");
if (amount == 0) return 0;
// consider use of a penny stamp
minStamps = 1+stampCount(amount-PENNY);
// consider use of a post card stamp
if (amount >= CARD) {
int possible = 1+stampCount(amount-CARD);
if (minStamps > possible) minStamps = possible;
}
// consider use of a letter stamp
if (amount >= LETTER) {
int possible = 1+stampCount(amount-LETTER);
if (minStamps > possible) minStamps = possible;
}
return minStamps;
}

For the nontrivial cases, the variable minStamps keeps track of the minimum
number of stamps returned by any of these three subproblems. Since each
method call potentially results in several recursive calls, the method is not tail
recursive. While it is possible to solve this problem using iteration, recursion
presents a very natural solution.

An Efficient Solution to the Postage Stamp Problem

If the same procedure were used to compute the minimum number of stamps Making
to make 70 cents change, the stampCount procedure would be called 2941 currency is
times. This number increases exponentially as the size of the problem in- illegal.
creases (it is O(3n )). Because 2941 is greater than 70—the number of distinct Making change
subproblems—some subproblems are recomputed many times. For example, is not!
the 2 cent problem must be re-solved by every larger problem.
To reduce the number of calls, we can incorporate an array into the method.
Each location n of the array stores either 0 or the answer to the problem of size
n. If, when looking for an answer, the entry is 0, we invest time in computing the
answer and cache it in the array for future use. This technique is called dynamic
programming and yields an efficient linear algorithm. Here is our modified
FullPostage
solution:
100 Design Fundamentals

public static final int LETTER = 41; // letter rate

public static final int CARD = 26; // post card rate
public static final int PENNY = 1; // penny stamp

public static int stampCount(int amount)

// pre: amount >= 0
// post: return *number* of stamps needed to make change
// (only use letter, post card, and penny stamps)
{
return stampCount(amount, new int[amount+1]);
}

protected static int stampCount(int amount, int answer[])

// pre: amount >= 0; answer array has length >= amount
// post: return *number* of stamps needed to make change
// (only use letter, post card, and penny stamps)
{
int minStamps;
Assert.pre(amount >= 0,"Reasonable amount of change.");
if (amount == 0) return 0;
if (answer[amount] != 0) return answer[amount];
// consider use of a penny stamp
minStamps = 1+stampCount(amount-1,answer);
// consider use of a post card stamp
if (amount >= CARD) {
int possible = 1+stampCount(amount-CARD,answer);
if (minStamps > possible) minStamps = possible;
}
// consider use of a letter stamp
if (amount >= LETTER) {
int possible = 1+stampCount(amount-LETTER,answer);
if (minStamps > possible) minStamps = possible;
}
answer[amount] = minStamps;
return minStamps;
}

When we call the method for the first time, we allocate an array of sufficient
size (amount+1 because arrays are indexed beginning at zero) and pass it as
answer in the protected two-parameter version of the method. If the answer
is not found in the array, it is computed using up to three recursive calls that
pass the array of previously computed answers. Just before returning, the newly
computed answer is placed in the appropriate slot. In this way, when solutions
are sought for this problem again, they can be retrieved without the overhead
of redundant computation.
When we seek the solution to the 70 cent problem, 146 calls are made to the
procedure. Only a few of these get past the first few statements to potentially
make recursive calls. The combination of the power recursion and the efficiency
of dynamic programming yields elegant solutions to many seemingly difficult
5.2 Self-Reference 101

problems.

Exercise 5.5 Explain why the dynamic programming approach to the problem
runs in linear time.

In the next section, we consider induction, a recursive proof technique. In-

duction is as elegant a means of proving theorems as recursion is for writing
programs.

5.2.2 Mathematical Induction

The accurate analysis of data structures often requires mathematical proof. An
effective proof technique that designers may apply to many computer science
problems is mathematical induction. The technique is, essentially, the construc-
tion of a recursive proof. Just as we can solve some problems elegantly using
recursion, some properties may be elegantly verified using induction.
A common template for proving statements by mathematical induction is as
follows:
1. Begin your proof with “We will prove this using induction on the size of
the problem.” This informs the reader of your approach.
2. Directly prove whatever base cases are necessary. Strive, whenever possi-
ble to keep the number of cases small and the proofs as simple as possible.
3. State the assumption that the observation holds for all values from the
base case, up to but not including the nth case. Sometimes this assump-
tion can be relaxed in simple inductive proofs.
4. Prove, from simpler cases, that the nth case also holds.
5. Claim that, by mathematical induction on n, the observation is true for all
cases more complex than the base case.
Individual proofs, of course, can deviate from this pattern, but most follow the
given outline.
As an initial example, we construct a formula for computing the sum of
integers between 0 and n ≥ 0 inclusively. Recall that this result was used in
Section 3.5 when we considered the cost of extending Vectors, and earlier, in
Section 5.1.2, when we analyzed buildVector2. Proof of this statement also
yields a constant-time method for implementing sum3.
Pn n(n+1)
Observation 5.1 i=0 i = 2 .

Proof: We prove this by induction. First, consider the simplest case, or base case.
If n = 0, then the sum is 0. The formula gives us 0(0+1)
2 = 0. The observation
appears to hold for the base case.
Now, suppose we know—for some reason—that our closed-form formula
holds for all values between 0 (our base case) and n − 1. This knowledge may
102 Design Fundamentals

help us solve a more complex problem, namely, the sum of integers between 0
and n. The sum
0 + 1 + 2 + · · · + (n − 1) + n
conveniently contains the sum of the first n − 1 integers, so we rewrite it as

[0 + 1 + 2 + · · · + (n − 1)] + n

Because we have assumed that the sum of the natural numbers to n − 1 can be
computed by the formula, we may rewrite the sum as
 
(n − 1)n
+n
2

The terms of this expression may be simplified and reorganized:

(n − 1)n + 2n n(n + 1)
=
2 2
Thus given only the knowledge that the formula worked for n − 1, we have
been able to extend it to n. It is not hard to convince yourself, then, that the
observation holds for any nonnegative value of n. Our base case was for n = 0,
so it must hold as well for n = 1. Since it holds for n = 1, it must hold for
n = 2. In fact, it holds for any value of n ≥ 0 by simply proving it holds for
values 0, 1, 2, . . . , n − 1 and then observing it can be extended to n.
The induction can be viewed as a recursively constructed proof (consider
Figure 5.6). Suppose we wish to see if our observation holds for n = 100. Our
99 cases left to method requires us to show it holds for n = 99. Given that, it is a simple matter
prove! Take one to extend the result to 100. Proving the result for n = 99, however, is almost2
down, pass it as difficult as it is for n = 100. We need to prove it for n = 98, and extend
around, 98 that result. This process of developing the proof for 100 eventually unravels
cases left to into a recursive construction of a (very long) proof that demonstrates that the
prove! . . .
observation holds for values 0 through 99, and then 100.
The whole process, like recursion, depends critically on the proof of appro-
priate base cases. In our proof of Observation 5.1, for example, we proved that
the observation held for n = 0. If we do not prove this simple case, then our
recursive construction of the proof for any value of n ≥ 0 does not terminate:
when we try to prove it holds for n = 0, we have no base case, and therefore
must prove it holds for n = −1, and in proving that, we prove that it holds for
−2, −3, . . . , ad infinitum. The proof construction never terminates!
Our next example of proof by induction is a correctness proof . Our intent is
to show that a piece of code runs as advertised. In this case, we reinvestigate
sum3 from page 95:

2 It is important, of course, to base your inductive step on simpler problems—problems that take
Recursion you closer to your base case. If you avoid basing it on simpler cases, then the recursive proof will
never be completely constructed, and the induction will fail.
5.2 Self-Reference 103

Proof for 100:

* It works for 99.
* Extend to 100.
Q.E.D.

Proof for 99:

* It works for 98.
* Extend to 99.
Q.E.D.

Proof for 98:

* It works for 97.
* Extend to 98.
Q.E.D. Proof for 0:
* Trivial proof.
Q.E.D.

Figure 5.6 The process of proof by induction simulates the recursive construction of a
proof. Compare with Figure 5.5.

public static int sum3(int n)

// pre: n >= 0
// post: compute the sum of 0..n
{
if (n < 1) return 0; // 1
else return // 2
sum3( // 3
n-1 // 4
) + n; // 5
}

(The code has been reformatted to allow discussion of portions of the computa-
tion.) As with our mathematical proofs, we state our result formally:

Observation 5.2 Given that n ≥ 0, the method sum3 computes the sum of the
integers 0 through n, inclusive.

Proof: Our proof is by induction, based on the parameter n. First, consider the
action of sum3 when it is passed the parameter 0. The if statement of line 1 is
true, and the program returns 0, the desired result.
We now consider n>0 and assume that the method computes the correct
result for all values less that n. We extend our proof of correctness to the pa-
rameter value of n. Since n is greater than 0, the if of line 1 fails, and the else
beginning on line 2 is considered. On line 4, the parameter is decremented,
and on line 3, the recursion takes place. By our assumption, this recursive
104 Design Fundamentals

1111111111
0000000000
0000000000
1111111111
0000000000
1111111111
n-1 others

0000000000
1111111111
0000000000
1111111111
Alice

0000000000
1111111111
0000000000
1111111111
Figure 5.7 A group of n computer scientists composed of Alice and n − 1 others.

call returns the correct result—the sum of values between 0 and n-1, inclusive.
Line 5 adds in the final value, and the entire result is returned. The program
works correctly for a parameter n greater than 0. By induction on n, the method
computes the correct result for all n>=0.
Proofs of correctness are important steps in the process of verifying that code
works as desired. Clearly, since induction and recursion have similar forms, the
application of inductive proof techniques to recursive methods often leads to
straightforward proofs. Even when iteration is used, however, induction can be
used to demonstrate assumptions made about loops, no matter the number of
iterations.
We state here an important result that gives us a closed-form expression for
computing the sum of powers of 2.
Pn
Observation 5.3 i=0 2i = 2n+1 − 1.

Exercise 5.6 Prove Observation 5.3.

There are, of course, ways that the inductive proof can go awry. Not proving
the appropriate base cases is the most common mistake and can lead to some
interesting results. Here we prove what few have suspected all along:

Observation 5.4 All computer scientists are good programmers.

Warning: bad Proof: We prove the observation is true, using mathematical induction. First,
proof! we use traditional techniques (examinations, etc.) to demonstrate that Alice is
a good programmer.
Now, assume that our observation is true of any group of fewer than n com-
puter scientists. Let’s extend our result: select n computer scientists, including
Alice (see Figure 5.7). Clearly, the subgroup consisting of all computer scien-
tists that are “not Alice” is a group of n − 1 computer scientists. Our assumption
states that this group of n − 1 computer scientists is made up of good program-
mers. So Alice and all the other computer scientists are good programmers.
By induction on n, we have demonstrated that all computer scientists are good
programmers.
5.2 Self-Reference 105

1111111111111
0000000000000
0000
1111
0000000000000
1111111111111
Alice

0000
1111 0000
1111
0000000000000
1111111111111
0000
1111 0000
1111
0000000000000
1111111111111
00000
11111 0000
1111
0000000000000
1111111111111
00000
11111
Carol

00000 1111
0000
0000000000000
1111111111111
11111
0000000000000
1111111111111
0000000000000
1111111111111
Bob

Figure 5.8 A group of n computer scientists, including Alice, Bob, and Carol.

This is a very interesting result, especially since it is not true. (Among other
things, some computer scientists do not program computers!) How, then, were
we successful in proving it? If you look carefully, our base case is Alice. The
assumption, on the other hand, is based on any group of n − 1 programmers.
Unfortunately, since our only solid proof of quality programming is Alice, and
non-Alice programmers cannot be reduced to cases involving Alice, our proof is
fatally flawed.
Still, a slight reworking of the logic might make the proof of this observa-
tion possible. Since Alice is a computer scientist, we can attempt to prove the
observation by induction on groups of computer scientists that include Alice:
Proof: We prove the observation by induction. First, as our base case, consider Warning: bad
Alice. Alice is well known for being a good programmer. Now, assume that for proof, take 2!
any group of fewer than n computer scientists that includes Alice, the members
are excellent programmers. Take n computer scientists, including Alice (see
Figure 5.8). Select a non-Alice programmer. Call him Bob. If we consider all
non-Bob computer scientists, we have a group of n − 1 computer scientists—
including Alice. By our assumption, they must all be good. What about Bob?
Select another non-Alice, non-Bob computer scientist from the group of n. Call
her Carol. Carol must be a good programmer, because she was a member of the
n − 1 non-Bob programmers. If we consider the n − 1 non-Carol programmers,
the group includes both Alice and Bob. Because it includes Alice, the non-
Carol programmers must all be good. Since Carol is a good programmer, then
all n must program well. By induction on n, all groups of computer scientists
that include Alice must be good programmers. Since the group of all computer
scientists is finite, and it includes Alice, the entire population must program
well. The observation holds!
This proof looks pretty solid—until you consider that in order for it to work,
you must be able to distinguish between Alice, Bob, and Carol. There are three
people. The proof of the three-person case depends directly on the observation
holding for just two people. But we have not considered the two-person case!
In fact, that is the hole in the argument. If we know of a bad programmer, Ted,
we can say nothing about the group consisting of Alice and Ted (see Figure 5.9).
106 Design Fundamentals

Ted
Alice

Figure 5.9 The proof does not hold for the simplest nontrivial case: Alice and any bad
programmer.

As a result, we have a worrisome hole in the proof of the group consisting of

Alice, Bob, and Ted. In the end, the attempt at a complete proof unravels.
Lesson: What have we learned from this discussion? For an inductive proof, the base
it’s hard to find cases must be carefully enumerated and proved. When proving the inductive
good step, the step must be made upon a proved foundation. If not, the entire state-
programmers. ment collapses. The subtlety of this difficulty should put us on alert: even the
most thoughtful proofs can go awry if the base case is not well considered.
We can now make a similar statement about recursion: it is important to
identify and correctly code the base cases you need. If you don’t, you run the
risk that your method will fail to stop or will compute the wrong answer. One
of the most difficult debugging situations occurs when multiple base cases are
to be considered and only a few are actually programmed.
Our final investigation considers the implementation of a Java method to
compute the following sequence of values:

0, 1, 1, 2, 3, 5, 8, 13, 21, . . .

These values are the first of the sequence of Fibonacci numbers. Each value is
the sum of the two values that fall before it. We should be careful—especially
given our last discussion—that we have the base cases carefully considered. In
this particular case, we must specify two initial values: 0 and 1.
This sequence may be familiar to you. If it is, you may have seen the defini-
tion of Fn , the nth value of the sequence as

n n = 0 or n = 1
Fn =
Fn−2 + Fn−1 n > 1

The translation of this type of equation into Java is fairly straightforward. We

make the following attempt:

static public int fibo(int n)

// pre: n is a nonnegative integer
// post: result is the ith term from the sequence
Fibo // 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, . . .
5.2 Self-Reference 107

{
Assert.pre(n >= 0, "Index is nonnegative.");
// when n < 2, return n
if (n == 0) return 0; // line 1
else if (n == 1) return 1; // line 2
// complex, self-referential case:
else return fibo(n-2)+fibo(n-1); // line 3
}
We now seek to prove that the recursive method computes and returns the nth
member of the sequence.
Proof: First, suppose n = 0: the method returns 0, on line 1. Next, suppose
that n = 1: the method returns 1, on line 2. So, for the two very simplest
cases, the method computes the correct values. Now, suppose that n > 1, and
furthermore, assume that fibo returns the correct value for all terms with index
less than n. Since n > 1, lines 1 and 2 have no effect. Instead, the method
resorts to using line 3 to compute the value. Since the method works for all
values less than n, it specifically computes the two previous terms—Fn−2 and
Fn−1 —correctly. The sum of these two values (Fn ) is therefore computed and
immediately returned on line 3. We have, then, by mathematical induction on
n proved that f ibo(n) computes Fn for all n ≥ 0.
Another approach to computing Fibonacci numbers, of course, would be to
use an iterative method:
static public int fibo2(int n)
// pre: n is a nonnegative integer
// post: result is the ith term from the sequence
// 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, . . .
{
Assert.pre(n >= 0, "Index is nonnegative.");
int a = 0;
int b = 1;
if (n == 0) return a; // line 1
if (n == 1) return b; // line 2
// for large values of n, iteratively compute sequence
int i=2,F;
do
{
// Assertion: b is the i-1st member of the sequence
// a is the i-2nd member
F = a + b; // line 3
// Assertion: F is the ith member
// update previous two values:
a = b; // line 4
b = F; // line 5
i++; // line 6
} while (i <= n); // line 7
return F; // line 8
}
108 Design Fundamentals

To demonstrate that such a program works, we perform a step-wise analysis of

the method as it computes Fn .
Proof: Suppose n = 0. The condition in the if statement on line 1 is true and
the value a (0) is returned. If n = 1, the condition on line 1 is false, but the
if statement on line 2 is true and b (1) is returned. In both of these cases the
correct value is returned.
We now investigate the loop. We notice that when the loop starts (it is a do
loop, it must execute at least once if n > 1), a and b contain the values F0 and
F1 , and i is 2. Thus, the loop invariant before line 3 holds on the first iteration.
Now, assume that i ≥ 2 and the loop invariant before line 3 holds. The
effect of line 3 is to compute Fi from Fi−1 and Fi−2 . The result is placed in F ,
and the loop invariant after line 3 is met. The remaining statements, on lines 4
through 6 result in Fi−2 in a and Fi−1 in b. If the condition on line 7 should be
true, we meet the loop invariant for the next iteration.
If the condition on line 7 should be false, then we note that this value of i is
the first that is greater than n, so F = Fi−1 = Fn , and the result returned is the
correct result. 
It is interesting to note that the initial values of the sequence are rather arbi-
trary, and that different natural phenomena related to Fibonacci numbers can
be modeled by sequences that begin with different initial values.

5.3 Properties of Design

This section is dedicated to two informal properties of design that are referenced
elsewhere within this text. The property of symmetry describes the predictability
of a design, while friction describes the difficulty of moving a data structure from
one state to another. Both terms extend the vocabulary of implementors when
discussing design decisions.

5.3.1 Symmetry
For the most part, our instruction of computers occurs through programs. As
a result, programs can be nonintuitive and hard to understand if they are not
designed with human-readability in mind. On the other hand, a well-designed
program can be used by a novice without a significant learning curve. Systems
that are easy to use tend to survive longer.
The programmer, as a designer of a data structure, is responsible for deliv-
ering a usable implementation of an abstract data structure. For an implemen-
tation to be usable, it should provide access to the structure with methods that
are predictable and easy to use. The notion of predictability is particularly dif-
ficult for designers of data structures to understand, and it is something often
overlooked by novice programmers.
When designing a system (here, a program or data structure) a useful princi-
ple is to make its interface symmetric. What is symmetry? Symmetry allows one
5.3 Properties of Design 109

to view a system from different points of view and see similarities. Mathemati-
cians would say that a system exhibits a symmetry if “it looks like itself under
a nontrivial transformation.” Given this, programmers consider asymmetries in
transformed programs to be early warning signs of errors in logic.
Consider the following method (you will see this as part of the swap proce-
dure of page 120). It exchanges two object references—data[i] and data[j].
int temp;
temp = data[i];
data[i] = data[j];
data[j] = temp;

Close inspection of this code demonstrates that it does what it claims to do.
Even if we stand back, not thinking so much about the actual workings of the
code, we can see that the code is pretty symmetric. For example, if we squint
our eyes and look at the code from the standpoint of variable data[i], we see
it as:
... = data[i];
data[i] = ...;

Here, data[i] is assigned to a variable, and a value is assigned to data[i]. We

see a similar pattern with data[j]:
... = data[j];
data[j] = ...;

While this is not direct proof that the code works, it is an indication that the
code is, in some way, “symmetric,” and that helps make the argument that it is
well designed.
Not everything we do is symmetric. If we consider the Association class,
for example, the key and value components of the Association are different.
The value, of course, has two associated methods, getValue and setValue.
The first of the methods reads and returns a value, while the second method
consumes and sets a value. Everything is in balance, and so we are hopeful that
the design of the structure is correct. On the other hand, the key can only be
read: while there is a getKey method, there is no setKey. We have suggested
good reasons for doing this. As long as you can make a good argument for
asymmetry in design, the breaking of symmetry can be useful. Unreasoned
asymmetry, however, is a sign of poor and unpredictable design.
Here are various ways that one can look at a system to evaluate it for sym-
metry:
1. Compare methods that extend the structure with methods that trim the
structure. Do they have similar approaches? Are they similar in number?
2. Consider methods that read and write values. Can the input methods read
what is written by the output methods? Can the writing methods write all
values that can be read?
110 Design Fundamentals

3. Are procedures that consume parameters matched by functions that de-

liver values?

4. Can points of potential garbage collection be equally balanced by new in-

vocations?

5. In linked structures, does unlinking a value from the structure appear to

be the reverse of linking a new value into the structure?

When asymmetries are found, it is important to consider why they occur. Argu-
ments such as “I can’t imagine that anyone would need an opposite method!”
are usually unconvincing. Many methods are added to the structures, not be-
cause they are obviously necessary, but because there is no good argument
against them. Sometimes, of course, the language or underlying system forces
an asymmetry. In Java, for example, every Object has a toString method that
converts an internal representation of an object to a human-readable form, but
there’s no fromString required method that reads the value of an Object from
Should 6= will. a String. There should be, but there isn’t.

5.3.2 Friction
One of the obvious benefits of a data structure is that it provides a means of
storing information. The ease with which the structure accepts and provides in-
formation about its contents can often be determined by its interface. Likewise,
the difficulty of moving a data structure from one state to another determines,
in some way, its “stiffness” or the amount of friction the structure provides when
the state of the structure is to be modified.
One way that we might measure friction is to determine a sequence of logical
states for the structure, and then determine the number of operations that are
necessary to move the structure from each state to the next. If the number
of operations is high, we imagine a certain degree of friction; if the operation
count is low, the structure moves forward with relative ease.
Often we see that the less space provided to the structure, the more friction
appears to be inherent in its structure. This friction can be good—it may make
it less possible to get our structure into states that are inconsistent with the
definition of the structure, or it may be bad—it may make it difficult to get
something done.

5.4 Conclusions
Several formal concepts play an important role in modern data structure des-
ign—the use of big-O analysis to support claims of efficiency, the use of recur-
sion to develop concise but powerful structures, and the use of induction to
prove statements made about both data structures and algorithms. Mastery of
these concepts improves one’s approach to solving problems of data structure
design.
5.4 Conclusions 111

The purpose of big-O analysis is to demonstrate upper bounds on the growth

of functions that describe behavior of the structures we use. Since these are
upper bounds, the tightest bounds provide the most information. Still, it is
often not very difficult to identify the fastest-growing component of a function—
analysis of that component is likely to lead to fairly tight bounds and useful
results.
Self-reference is a powerful concept. When used to develop methods, we call
this recursion. Recursion allows us to break down large problems into smaller
problems whose solutions can be brought together to solve the original prob-
lem. Interestingly, recursion is often a suitable substitute for loops as a means of
progressing through the problem solution, but compilers can often convert tail
recursive code back into loops, for better performance. All terminating recur-
sive methods involve at least one test that distinguishes the base case from the
recursive, and every recursive program must eventually make progress toward
a base case to construct a solution.
Mathematical induction provides a means of recursively generating proofs.
Perhaps more than most other proof mechanisms, mathematical induction is
a useful method for demonstrating a bound on a function, or the correct ter-
mination of a method. Since computers are not (yet) able to verify everyday
inductive proofs, it is important that they be constructed with appropriate care.
Knowing how to correctly base induction on special cases can be tricky and, as
we have recently seen, difficult to verify.
In all these areas, practice makes perfect.

Self Check Problems

Solutions to these problems begin on page 444.
5.1 Suppose f (x) = x. What is its best growth rate, in big-O notation?
5.2 Suppose f (x) = 3x. What is its growth rate?
5.3 What is the growth rate of f (x) = x + 900?
5.4 How fast does f (x) grow if f (x) = x for odd integers and f (x) = 900
for even integers?
√
5.5 Evaluate and order the functions log2 x, x, x, 30x, x2 , 2x , and x! at
x = 2, 4, 16, and 64. For each value of x, which is largest?
5.6 What are three features of recursive programs?
5.7 The latest Harry Potter book may be read by as much as 75 percent of
the reading child population in the United States. Approximately how many
child-years of reading time does this represent?
5.8 Given an infinite supply of 37 cent stamps, 21 cent stamps, and penny
stamps a postmaster returns a minimum number of stamps composed of c37 (x),
c21 (x), and c1 (x) stamps for x dollars in change. What are the growth rates of
these functions?
112 Design Fundamentals

Problems
Solutions to the odd-numbered problems begin on page 462.
5.1 What is the time complexity associated with accessing a single value in
an array? The Vector class is clearly more complex than the array. What is the
time complexity of accessing an element with the get method?
5.2 What is the worst-case time complexity of the index-based remove code
in the Vector class? What is the best-case time complexity? (You may assume
the Vector does not get resized during this operation.)
5.3 What is the running time of the following method?
public static int reduce(int n)
{
int result = 0;
while (n > 1)
{
n = n/2;
result = result+1;
}
return result;
}

5.4 What is the time complexity of determining the length of an n-character

null-terminated string? What is the time complexity of determining the length
of an n-character counted string?
5.5 What is the running time of the following matrix multiplication method?
// square matrix multiplication
// m1, m2, and result are n by n arrays
for (int row = 0; row < n; row++)
{
for (int col = 0; col < n; col++)
{
int sum = 0;
for (int entry = 0; entry < n; entry++)
{
sum = sum + m1[row][entry]*m2[entry][col];
}
result[row][col] = sum;
}
}

5.6 In Definition 5.1 we see what it means for a function to be an upper

bound. An alternative definition provides a lower bound for a function:
Definition 5.2 A function f (n) is Ω(g(n)) (read “big-omega of g” or “at least
order g”), if and only if there exist two positive constants, c and n0 , such that
f (n) ≥ c · g(n)
for all n ≥ n0 .
5.4 Conclusions 113

What is a lower bound on the time it takes to remove a value from a Vector by
index?
5.7 What is a lower bound on adding a value to the end of a Vector? Does
it matter that sometimes we may have to spend time doubling the size of the
underlying array?
5.8 When discussing symmetry, we investigated a procedure that swapped
two values within an array. Is it possible to write a routine that swaps two
integer values? If so, provide the code; if not, indicate why.
5.9 For subtle reasons String objects cannot be modified. Instead, Strings
are used as parameters to functions that build new Strings. Suppose that a is
an n-character String. What is the time complexity of performing a=a+"!"?
5.10 Read Problem 5.9. Suppose that a and b are n-character Strings. What
is the complexity of performing a=a+b?
5.11 What is the rate of growth (using big-O analysis) of the function f (n) =
n + log n? Justify your answer.
5.12 In this text, logarithms are assumed to be in base 2. Does it make a
difference, from a complexity viewpoint?
1
5.13 What is the rate of growth of the function n + 12? Justify your answer.
sin n
5.14 What is the rate of growth of the function n ? Justify your answer.
5.15 Trick question: What is the rate of growth of tan n?
5.16 Suppose n integers between 1 and 366 are presented as input, and you
want to know if there are any duplicates. How would you solve this problem?
What is the rate of growth of the function T (n), describing the time it takes for
you to determine if there are duplicates? (Hint: Pick an appropriate n0 .)
5.17 The first element of a Syracuse sequence is a positive integer s0 . The
value si (for i > 0) is defined to be si−1 /2 if si−1 is even, or 3si−1 + 1 if si−1
is odd. The sequence is finished when a 1 is encountered. Write a procedure to
print the Syracuse sequence for any integer s0 . (It is not immediately obvious
that this method should always terminate.)
5.18 Rewrite the sqrt function of Section 2.1 as a recursive procedure.
5.19 Write a recursive procedure to draw a line segment between (x0 , y0 )
and (x1 , y1 ) on a screen of pixels with integer coordinates. (Hint: The pixel
closest to the midpoint is not far off the line segment.)
5.20 Rewrite the reduce method of Problem 5.3 as a recursive method.
5.21 One day you notice that integer multiplication no longer works. Write
a recursive procedure to multiply two values a and b using only addition. What
is the complexity of this function?
5.22 Modify the “stamp change” problem of Section 5.2.1 to report the num-
ber of each type of stamp to be found in the minimum stamp change.
5.23 Prove that 5n − 4n − 1 is divisible by 16 for all n ≥ 0.
Pn
5.24 Prove Observation 5.3, that i=0 2i = 2n+1 − 1 for n ≥ 0.
114 Design Fundamentals

5.25 Prove that a function nc is O(nd ) for any d ≥ c.

Pn
5.26 Prove that i=1 2i = n(n + 1).
Pn
5.27 Prove that i=1 (2i − 1) = n2 .
Pn n+1
5.28 Show that for c ≥ 2 and n ≥ 0, i=0 ci = c c−1 +(c−2)
− 1.
Pn
5.29 Prove that i=1 log i ≤ n log n.
5.30 Some artists seek asymmetry. Physicists tell us the universe doesn’t
always appear symmetric. Why are we unfazed?
5.31 With a colleague, implement a fresh version of Lists. First, agree on
the types and names of private fields. Then, going down the list of methods
required by the List interface, split methods to be implemented between you
by assigning every other method to your colleague. Bring the code together
and compile it. What types of bugs occur? Did you depend on your colleague’s
code?
5.32 Consider the implementation of a Ratio data type. How does symmetry
appear in this implementation?
5.33 In the Vector class, we extend by doubling, but we never discuss re-
ducing by a similar technique. What is a good strategy?
5.34 Consider the following Java method:
static public int fido(int n)
// pre: n is a positive integer
// post: result is the nth term from the sequence
// 1, 3, 7, 15, 31, 63, 127, ...
{
int result = 1;
if (n > 1) result = 1+fido(n-1)+fido(n-1);
// assertion: the above if condition was tested
// fido(n) times while computing result
return result;
}

a. What does it compute?

b. Prove or disprove the informal assertion following the if statement.
c. What is the time complexity of the method?
d. Why is fido an appropriate name for this method?
5.5 Laboratory: How Fast Is Java?

Objective. To develop an appreciation for the speed of basic Java operations

including assignment of value to variables, arrays, and Vectors.
Discussion. How long does it take to add two integers in Java? How long does
it take to assign a value to an entry in an array? The answers to these questions
depend heavily on the type of environment a programmer is using and yet play
an important role in evaluating the trade-offs in performance between different
implementations of data structures.
If we are interested in estimating the time associated with an operation,
it is difficult to measure it accurately with clocks available on most modern
machines. If an operation takes 100 ns (nanoseconds, or billionths of a second),
10,000 of these operations can be performed within a single millisecond clock
tick. It is unlikely that we would see a change in the millisecond clock while the
operation is being performed.
One approach is to measure, say, the time it takes to perform a million of
these operations, and divide that portion of the time associated with the opera-
tion by a million. The result can be a very accurate measurement of the time it
takes to perform the operation. Several important things must be kept in mind:

• Different runs of the experiment can generate different times. This vari-
ation is unlikely to be due to significant differences in the speed of the
operation, but instead to various interruptions that regularly occur when
a program is running. Instead of computing the average of the running
times, it is best to compute the minimum of the experiment’s elapsed
times. It’s unlikely that this is much of an underestimate!

• Never perform input or output while you are timing an experiment. These
operations are very expensive and variable. When reading or writing,
make sure these operations appear before or after the experiment being
timed.

• On modern systems there are many things happening concurrently with

your program. Clocks tick forward, printer queues manage printers, net-
work cards are accepting viruses. If you can keep your total experiment
time below, say, a tenth of a second, it is likely that you will eliminate
many of these distractions.

• The process of repeating an operation takes time. One of our tasks will be
to measure the time it takes to execute an empty for loop. The loop, of
course, is not really empty: it performs a test at the top of the loop and an
increment at the bottom. Failing to account for the overhead of a for loop
makes it impossible to measure any operation that is significantly faster.

• Good compilers can recognize certain operations that can be performed

more efficiently in a different way. For example, traditional computers
116 Design Fundamentals

can assign a value of 0 much faster than the assignment of a value of 42.
If an experiment yields an unexpectedly short operation time, change the
Java to obscure any easy optimizations that may be performed. Don’t
forget to subtract the overhead of these obscuring operations!
Keeping a mindful eye on your experimental data will allow you to effectively
measure very, very short events accurate to nanoseconds. In one nanosecond,
light travels 11.80 inches!
Procedure. The ultimate goal of this experiment is a formally written lab report
presenting your results. Carefully design your experiment, and be prepared to
defend your approach. The data you collect here is experimental, and necessar-
ily involves error. To reduce the errors described above, perform multiple runs
of each experiment, and carefully document your findings. Your report should
include results from the following experiments:
1. A description of the machine you are using. Make sure you use this ma-
chine for all of your experiments.
2. Write a short program to measure the time that elapses, say, when an
empty for loop counts to one million. Print out the elapsed time, as well
as the per-iteration elapsed time. Adjust the number of loops so that the
total elapsed time falls between, say, one-hundredth and one-tenth of a
second.
Recall that we can measure times in nanoseconds (as accurately as possi-
ble, given your machine) using System.nanoTime():

int i, loops;
double speed;
loops = 10000000;
long start,stop,duration;

start = System.nanoTime();
for (i = 0; i < loops; i++)
{
// code to be timed goes here
}
stop = System.nanoTime();

duration = stop-start;
System.out.println("# Elapsed time: "+duration+"ns");
System.out.println("# Mean time: "+
(((double)duration)/loops)+
"nanoseconds");

3. Measure the time it takes to do a single integer assignment (e.g., i=42;).

Do not forget to subtract the time associated with executing the for loop.
4. Measure the time it takes to assign an integer to an array entry. Make sure
that the array has been allocated before starting the timing loop.
5.5 Laboratory: How Fast Is Java? 117

5. Measure the time it takes to assign a String reference to an array.

6. Measure the length of time it takes to assign a String to a Vector. (Note
that it is not possible to directly assign an int to a Vector class.)
7. Copy one Vector to another, manually, using set. Carefully watch the
elapsed time and do not include the time it takes to construct the two
Vectors! Measure the time it takes to perform the copy for Vectors of
different lengths. Does this appear to grow linearly?
Formally present your results in a write-up of your experiments.
Thought Questions. Consider the following questions as you complete the lab:
1. Your Java compiler and environment may have several switches that affect
the performance of your program. For example, some environments allow
the use of just-in-time (jit) compilers, that compile frequently used pieces
of code (like your timing loop) into machine-specific instructions that are
likely to execute faster. How does this affect your experiment?
2. How might you automatically guarantee that your total experiment time
lasts between, say, 10 and 100 milliseconds?
3. It is, of course, possible for a timer to underestimate the running time of
an instruction. For example, if you time a single assignment, it is certainly
possible to get an elapsed time of 0—an impossibility. To what extent
would a timing underestimate affect your results?

Notes:
Chapter 6
Sorting

Concepts: “Come along, children. Follow me.”

. Natural sorting techniques Before you could wink an eyelash
. Recursive sorting techniques Jack, Knak, Lack, Mack,
. Vector sorting Nack, Ouack, Pack, and Quack
. Use of compareTo methods fell into line, just as they had been taught.
. Comparator techniques —Robert McCloskey

C OMPUTERS SPEND A CONSIDERABLE AMOUNT of their time keeping data in or-

der. When we view a directory or folder, the items are sorted by name or type
or modification date. When we search the Web, the results are returned sorted
by “applicability.” At the end of the month, our checks come back from the bank
sorted by number, and our deposits are sorted by date. Clearly, in the grand
scheme of things, sorting is an important function of computers. Not surpris-
ingly, data structures can play a significant role in making sorts run quickly. This
chapter begins an investigation of sorting methods.

6.1 Approaching the Problem

For the moment we assume that we will be sorting an unordered array of in-
tegers (see Figure 6.1a).1 The problem is to arrange the integers so that every
adjacent pair of values is in the correct order (see Figure 6.1b). A simple tech-
nique to sort the array is to pass through the array from left to right, swapping
adjacent values that are out of order (see Figure 6.2). The exchange of values
is accomplished with a utility method:

public static void swap(int data[], int i, int j)

// pre: 0 <= i,j < data.length
// post: data[i] and data[j] are exchanged
{ BubbleSort
int temp;

1 We focus on arrays of integers to maintain a simple approach. These techniques, of course, can
be applied to vectors of objects, provided that some relative comparison can be made between two
elements. This is discussed in Section 6.7.
120 Sorting

40 2 1 43 3 65 0 −1 58 3 42 4
0 1 2 3 4 5 6 7 8 9 10 11

(a) Unordered

−1 0 1 2 3 3 4 40 42 43 58 65
0 1 2 3 4 5 6 7 8 9 10 11

(b) Sorted

Figure 6.1 The relations between entries in unordered and sorted arrays of integers.

temp = data[i];
data[i] = data[j];
data[j] = temp;
}

After a single pass the largest value will end up “bubbling” up to the high-
indexed side of the array. The next pass will, at least, bubble up the next largest
value, and so forth. The sort—called bubble sort—must be finished after n − 1
passes. Here is how we might write bubble sort in Java:

public static void bubbleSort(int data[], int n)

// pre: 0 <= n <= data.length
// post: values in data[0..n-1] in ascending order
{
int numSorted = 0; // number of values in order
int index; // general index
while (numSorted < n)
{
// bubble a large element to higher array index
for (index = 1; index < n-numSorted; index++)
{
if (data[index-1] > data[index])
swap(data,index-1,index);
}
// at least one more value in place
numSorted++;
}
}

Observe that the only potentially time-consuming operations that occur in this
sort are comparisons and exchanges. While the cost of comparing integers is rel-
6.1 Approaching the Problem 121

Bubble
40 2 1 43 3 65 0 −1 58 3 42 4

2 1 40 3 43 0 −1 58 3 42 4 65

1 2 3 40 0 −1 43 3 42 4 58 65

1 2 3 0 −1 40 3 42 4 43 58 65

1 2 0 −1 3 3 40 4 42 43 58 65

1 0 −1 2 3 3 4 40 42 43 58 65

0 −1 1 2 3 3 4 40 42 43 58 65

−1 0 1 2 3 3 4 40 42 43 58 65
Detectable finish
−1 0 1 2 3 3 4 40 42 43 58 65

−1 0 1 2 3 3 4 40 42 43 58 65

−1 0 1 2 3 3 4 40 42 43 58 65

−1 0 1 2 3 3 4 40 42 43 58 65

Figure 6.2 The passes of bubble sort: hops indicate “bubbling up” of large values.
Shaded values are in sorted order. A pass with no exchanges indicates sorted data.
122 Sorting

atively small, if each element of the array were to contain a long string (for ex-
ample, a DNA sequence) or a complex object (for example, a Library of Congress
entry), then the comparison of two values might be a computationally intensive
operation. Similarly, the cost of performing an exchange is to be avoided.2 We
can, therefore, restrict our attention to the number of comparison and exchange
operations that occur in sorts in order to adequately evaluate their performance.
In bubble sort each pass of the bubbling phase performs n − 1 comparisons
and as many as n − 1 exchanges. Thus the worst-case cost of performing bubble
sort is O((n−1)2 ) or O(n2 ) operations. In the best case, none of the comparisons
leads to an exchange. Even then, though, the algorithm has quadratic behavior.3
Most of us are inefficient sorters. Anyone having to sort a deck of cards or a
stack of checks is familiar with the feeling that there must be a better way to do
this. As we shall see, there probably is: most common sorting techniques used in
day-to-day life run in O(n2 ) time, whereas the best single processor comparison-
based sorting techniques are expected to run in only O(n log n) time. (If multi-
ple processors are used, we can reduce this to O(log n) time, but that algorithm
is beyond the scope of this text.) We shall investigate two sorting techniques
that run in O(n2 ) time, on average, and two that run in O(n log n) time. In the
end we will attempt to understand what makes the successful sorts successful.
Our first two sorting techniques are based on natural analogies.

6.2 Selection Sort

Children are perhaps the greatest advocates of selection sort. Every October,
Halloween candies are consumed from best to worst. Whether daily sampling
is limited or not, it is clear that choices of the next treat consumed are based
on “the next biggest piece” or “the next-most favorite,” and so on. Children
consume treats in decreasing order of acceptability. Similarly, when we select
plants from a greenhouse, check produce in the store, or pick strawberries from
the farm we seek the best items first.
This selection process can be applied to an array of integers. Our goal is
to identify the index of the largest element of the array. We begin by assuming
that the first element is the largest, and then form a competition among all the
remaining values. As we come across larger values, we update the index of the
current maximum value. In the end, the index must point to the largest value.
This code is idiomatic, so we isolate it here:

int index; // general index

int max; // index of largest value
// determine maximum value in array
SelectionSort
2 In languages like Java, where large objects are manipulated through references, the cost of an
exchange is usually fairly trivial. In many languages, however, the cost of exchanging large values
stored directly in the array is a real concern.
3 If, as we noted in Figure 6.2, we detected the lack of exchanges, bubble sort would run in O(n)

time on data that were already sorted. Still, the average case would be quadratic.
6.2 Selection Sort 123

max = 0;
for (index = 1; index < numUnsorted; index++)
{
if (data[max] < data[index]) max = index;
}

(Notice that the maximum is not updated unless a larger value is found.) Now,
consider where this maximum value would be found if the data were sorted:
it should be clear to the right, in the highest indexed location. This is easily
accomplished: we simply swap the last element of the unordered array with the
maximum. Once this swap is completed, we know that at least that one value is
in the correct location, and we logically reduce the size of the problem by one.
If we remove the n − 1 largest values in successive passes (see Figure 6.3), we
have selection sort. Here is how the entire method appears in Java:

public static void selectionSort(int data[], int n)

// pre: 0 <= n <= data.length
// post: values in data[0..n-1] are in ascending order
{
int numUnsorted = n;
int index; // general index
int max; // index of largest value
while (numUnsorted > 0)
{
// determine maximum value in array
max = 0;
for (index = 1; index < numUnsorted; index++)
{
if (data[max] < data[index]) max = index;
}
swap(data,max,numUnsorted-1);
numUnsorted--;
}
}

Selection sort potentially performs far fewer exchanges than bubble sort: se-
lection sort performs exactly one per pass, while bubble sort performs as many
as n − 1. Like bubble sort, however, selection sort demands O(n2 ) time for
comparisons.
Interestingly, the performance of selection sort is independent of the order
of the data: if the data are already sorted, it takes selection sort just as long to
sort as if the data were unsorted. We can improve on this behavior through a
slightly different analogy.
124 Sorting

Select & exchange

40 2 1 43 3 65 0 −1 58 3 42 4

40 2 1 43 3 4 0 −1 58 3 42 65

40 2 1 43 3 4 0 −1 42 3 58 65

40 2 1 3 3 4 0 −1 42 43 58 65

40 2 1 3 3 4 0 −1 42 43 58 65

−1 2 1 3 3 4 0 40 42 43 58 65

−1 2 1 3 3 0 4 40 42 43 58 65

−1 2 1 0 3 3 4 40 42 43 58 65

−1 2 1 0 3 3 4 40 42 43 58 65

−1 0 1 2 3 3 4 40 42 43 58 65

−1 0 1 2 3 3 4 40 42 43 58 65

−1 0 1 2 3 3 4 40 42 43 58 65

Figure 6.3 Profile of the passes of selection sort: shaded values are sorted. Circled
values are maximum among unsorted values and are moved to the low end of sorted
values on each pass.
6.3 Insertion Sort 125

6.3 Insertion Sort

Card players, when collecting a hand, often consider cards one at a time, in-
serting each into its sorted location. If we consider the “hand” to be the sorted
portion of the array, and the “table” to be the unsorted portion, we develop a
new sorting technique called insertion sort.
In the following Java implementation of insertion sort, the sorted values are
kept in the low end of the array, and the unsorted values are found at the high
end (see Figure 6.4). The algorithm consists of several “passes” of inserting the
lowest-indexed unsorted value into the list of sorted values. Once this is done,
of course, the list of sorted values increases by one. This process continues until
each of the unsorted values has been incorporated into the sorted portion of the
array. Here is the code:
InsertionSort
public static void insertionSort(int data[], int n)
// pre: 0 <= n <= data.length
// post: values in data[0..n-1] are in ascending order
{
int numSorted = 1; // number of values in place
int index; // general index
while (numSorted < n)
{
// take the first unsorted value
int temp = data[numSorted];
// ...and insert it among the sorted:
for (index = numSorted; index > 0; index--)
{
if (temp < data[index-1])
{
data[index] = data[index-1];
} else {
break;
}
}
// reinsert value
data[index] = temp;
numSorted++;
}
}
A total of n − 1 passes are made over the array, with a new unsorted value
inserted each time. The value inserted may not be a new minimum or maximum
value. Indeed, if the array was initially unordered, the value will, on average,
end up near the middle of the previously sorted values. On random data the
running time of insertion sort is expected to be dominated by O(n2 ) compares
and data movements (most of the compares will lead to the movement of a data
value).
If the array is initially in order, one compare is needed at every pass to
determine that the value is already in the correct location. Thus, the inner loop
126 Sorting

Insert
40 2 1 43 3 65 0 −1 58 3 42 4

2 40 1 43 3 65 0 −1 58 3 42 4

1 2 40 43 3 65 0 −1 58 3 42 4

1 2 40 43 3 65 0 −1 58 3 42 4

1 2 3 40 43 65 0 −1 58 3 42 4

1 2 3 40 43 65 0 −1 58 3 42 4

0 1 2 3 40 43 65 −1 58 3 42 4

−1 0 1 2 3 40 43 65 58 3 42 4

−1 0 1 2 3 40 43 58 65 3 42 4

−1 0 1 2 3 3 40 43 58 65 42 4

−1 0 1 2 3 3 40 42 43 58 65 4

−1 0 1 2 3 3 4 40 42 43 58 65

Figure 6.4 Profile of the passes of insertion sort: shaded values form a “hand” of sorted
values. Circled values are successively inserted into the hand.
6.4 Mergesort 127

is executed exactly once for each of n − 1 passes. The best-case running time
performance of the sort is therefore dominated by O(n) comparisons (there are
no movements of data within the array). Because of this characteristic, insertion
sort is often used when data are very nearly ordered (imagine sorting a phone
book after a month of new customers has been appended).
In contrast, if the array was previously in reverse order, the value must be
compared with every sorted value to find the correct location. As the compar-
isons are made, the larger values are moved to the right to make room for the
new value. The result is that each of O(n2 ) compares leads to a data movement,
and the worst-case running time of the algorithm is O(n2 ).
Note that each of these sorts uses a linear number of data cells. Not every
sorting technique is able to live within this constraint.

6.4 Mergesort
Suppose that two friends are to sort an array of values. One approach might be
to divide the deck in half. Each person then sorts one of two half-decks. The
sorted deck is then easily constructed by combining the two sorted half-decks.
This careful interleaving of sorted values is called a merge.
It is straightforward to see that a merge takes at least O(n) time, because
every value has to be moved into the destination deck. Still, within n − 1 com-
parisons, the merge must be finished. Since each of the n − 1 comparisons
(and potential movements of data) takes at most constant time, the merge is no
worse than linear.
There are, of course, some tricky aspects to the merge operation—for exam-
ple, it is possible that all the cards in one half-deck are smaller than all the cards
in the other. Still, the performance of the following merge code is O(n):

private static void merge(int data[], int temp[],

int low, int middle, int high)
// pre: data[middle..high] are ascending
// temp[low..middle-1] are ascending MergeSort
// post: data[low..high] contains all values in ascending order
{
int ri = low; // result index
int ti = low; // temp index
int di = middle; // destination index
// while two lists are not empty merge smaller value
while (ti < middle && di <= high)
{
if (data[di] < temp[ti]) {
data[ri++] = data[di++]; // smaller is in high data
} else {
data[ri++] = temp[ti++]; // smaller is in temp
}
}
// possibly some values left in temp array
128 Sorting

while (ti < middle)

{
data[ri++] = temp[ti++];
}
// ...or some values left (in correct place) in data array
}

This code is fairly general, but a little tricky to understand (see Figure 6.5). We
assume that the data from the two lists are located in the two arrays—in the
lower half of the range in temp and in the upper half of the range in data (see
Figure 6.5a). The first loop compares the first remaining element of each list to
determine which should be copied over to the result list first (Figure 6.5b). That
loop continues until one list is emptied (Figure 6.5c). If data is the emptied list,
the remainder of the temp list is transferred (Figure 6.5d). If the temp list was
emptied, the remainder of the data list is already located in the correct place!
Returning to our two friends, we note that before the two lists are merged
each of the two friends is faced with sorting half the cards. How should this be
done? If a deck contains fewer than two cards, it’s already sorted. Otherwise,
each person could recursively hand off half of his or her respective deck (now
one-fourth of the entire deck) to a new individual. Once these small sorts are
finished, the quarter decks are merged, finishing the sort of the half decks, and
the two half decks are merged to construct a completely sorted deck. Thus,
we might consider a new sort, called mergesort, that recursively splits, sorts,
and reconstructs, through merging, a deck of cards. The logical “phases” of
mergesort are depicted in Figure 6.6.
private static void mergeSortRecursive(int data[],
int temp[],
int low, int high)
// pre: 0 <= low <= high < data.length
// post: values in data[low..high] are in ascending order
{
int n = high-low+1;
int middle = low + n/2;
int i;

if (n < 2) return;
// move lower half of data into temporary storage
for (i = low; i < middle; i++)
{
temp[i] = data[i];
}
// sort lower half of array
mergeSortRecursive(temp,data,low,middle-1);
// sort upper half of array
mergeSortRecursive(data,temp,middle,high);
// merge halves together
merge(data,temp,low,middle,high);
}
6.4 Mergesort 129

data −1 0 3 4 42 58
(a) 0 1 2 3 4 5 6 7 8 9 10 11 12 13

temp 1 2 3 40 43 65

di 6 ti 0 ri 0

data −1 0 1 2 3 3 4 42 58
(b) 0 1 2 3 4 5 6 7 8 9 10 11 12 13
temp 40 43 65

di 8 ti 3 ri 5

data −1 0 1 2 3 3 4 40 42 43 58
(c) 0 1 2 3 4 5 6 7 8 9 10 11 12 13
temp 65

di 12 ti 5 ri 11

data −1 0 1 2 3 3 4 40 42 43 58 65
(d) 0 1 2 3 4 5 6 7 8 9 10 11 12 13
temp

di 12 ti 6 ri 12

Figure 6.5 Four stages of a merge of two six element lists (shaded entries are partic-
ipating values): (a) the initial location of data; (b) the merge of several values; (c) the
point at which a list is emptied; and (d) the final result.
130 Sorting

40 2 1 43 3 65 0 −1 58 3 42 4 Split

40 2 1 43 3 65 0 −1 58 3 42 4

40 2 1 43 3 65 0 −1 58 3 42 4

40 2 1 43 3 65 0 −1 58 3 42 4

2 1 3 65 −1 58 42 4
Merge

40 1 2 43 3 65 0 −1 58 3 4 42

1 2 40 3 43 65 −1 0 58 3 4 42

1 2 3 40 43 65 −1 0 3 4 42 58

−1 0 1 2 3 3 4 40 42 43 58 65

Figure 6.6 Profile of mergesort: values are recursively split into unsorted lists that are
then recursively merged into ascending order.

Note that this sort requires a temporary array to perform the merging. This
temporary array is only used by a single merge at a time, so it is allocated once
and garbage collected after the sort. We hide this detail with a public wrapper
procedure that allocates the array and calls the recursive sort:

public static void mergeSort(int data[], int n)

// pre: 0 <= n <= data.length
// post: values in data[0..n-1] are in ascending order
{
mergeSortRecursive(data,new int[n],0,n-1);
}

Clearly, the depth of the splitting is determined by the number of times that n
can be divided in two and still have a value of 1 or greater: log2 n. At each
level of splitting, every value must be merged into its respective subarray. It
follows that at each logical level, there are O(n) compares over all the merges.
Since there are log2 n levels, we have O(n · log n) units of work in performing a
mergesort.
Mergesort is a common technique for sorting large sets of data that do not
fit completely in fast memory. Instead, the data are saved in temporary files that
are merged together. When the recursion splits the collection into subsets of a
manageable size, they can be sorted using other techniques, if desired.
6.5 Quicksort 131

One of the unappealing aspects of mergesort is that it is difficult to merge

two lists without significant extra memory. If we could avoid the use of this extra
space without significant increases in the number of comparisons or data move-
ments, then we would have an excellent sorting technique. Our next method
demonstrates an O(n log n) method that requires significantly less space.

6.5 Quicksort
Since the process of sorting numbers consists of moving each value to its ul-
timate location in the sorted array, we might make some progress toward a
solution if we could move a single value to its ultimate location. This idea forms
the basis of a fast sorting technique called quicksort.
One way to find the correct location of, say, the leftmost value—called a
pivot—in an unsorted array is to rearrange the values so that all the smaller
values appear to the left of the pivot, and all the larger values appear to the
right. One method of partitioning the data is shown here. It returns the final
location for what was originally the leftmost value:

private static int partition(int data[], int left, int right)

// pre: left <= right
// post: data[left] placed in the correct (returned) location
{ QuickSort
while (true)
{
// move right "pointer" toward left
while (left < right && data[left] < data[right]) right--;
if (left < right) swap(data,left++,right);
else return left;
// move left pointer toward right
while (left < right && data[left] < data[right]) left++;
if (left < right) swap(data,left,right--);
else return right;
}
}

The indices left and right start at the two ends of the array (see Figure 6.7)
and move toward each other until they coincide. The pivot value, being leftmost
in the array, is indexed by left. Everything to the left of left is smaller than the
pivot, while everything to the right of right is larger. Each step of the main loop
compares the left and right values and, if they’re out of order, exchanges them.
Every time an exchange occurs the index (left or right) that references the
pivot value is alternated. In any case, the nonpivot variable is moved toward
the other. Since, at each step, left and right move one step closer to each
other, within n steps, left and right are equal, and they point to the current
location of the pivot value. Since only smaller values are to the left of the pivot,
and larger values are to the right, the pivot must be located in its final location.
Values correctly located are shaded in Figure 6.8.
132 Sorting

40 2 1 43 3 65 0 −1 58 3 42 4

left right
4 2 1 43 3 65 0 −1 58 3 42 40

4 2 1 40 3 65 0 −1 58 3 42 43

4 2 1 3 3 65 0 −1 58 40 42 43

4 2 1 3 3 40 0 −1 58 65 42 43

4 2 1 3 3 −1 0 40 58 65 42 43

4 2 1 3 3 −1 0 40 58 65 42 43

left right

Figure 6.7 The partitioning of an array’s values based on the (shaded) pivot value 40.
Snapshots depict the state of the data after the if statements of the partition method.
6.5 Quicksort 133

40 2 1 43 3 65 0 −1 58 3 42 4
partition
4 2 1 3 3 −1 0 40 58 65 42 43

0 2 1 3 3 −1 4 43 42 58 65

−1 0 1 3 3 2 42 43 65

−1 1 3 3 2 42

2 3 3

2 3

−1 0 1 2 3 3 4 40 42 43 58 65

Figure 6.8 Profile of quicksort: leftmost value (the circled pivot) is used to position
value in final location (indicated by shaded) and partition array into relatively smaller
and larger values. Recursive application of partitioning leads to quicksort.

Because the pivot segregates the larger and smaller values, we know that
none of these values will appear on the opposite side of the pivot in the final
arrangement. This suggests that we can reduce the sorting of a problem of size
n to two problems of size approximately n2 . To finish the sort, we need only
recursively sort the values to the left and right of the pivot:

public static void quickSort(int data[], int n)

// post: the values in data[0..n-1] are in ascending order
{
quickSortRecursive(data,0,n-1);
}

private static void quickSortRecursive(int data[],int left,int right)

// pre: left <= right
// post: data[left..right] in ascending order
{
int pivot; // the final location of the leftmost value
if (left >= right) return;
pivot = partition(data,left,right); /* 1 - place pivot */
quickSortRecursive(data,left,pivot-1); /* 2 - sort small */
quickSortRecursive(data,pivot+1,right);/* 3 - sort large */
/* done! */
}
134 Sorting

In practice, of course, the splitting of the values is not always optimal (see the
placement of the value 4 in Figure 6.8), but a careful analysis suggests that even
with these “tough breaks” quicksort takes only O(n log n) time.
When either sorted or reverse-sorted data are to be sorted by quicksort, the
results are disappointing. This is because the pivot value selected (here, the
leftmost value) finds its ultimate location at one end of the array or the other.
This reduces the sort of n values to n − 1 values (and not n/2), and the sort
requires O(n) passes of an O(n) step partition. The result is an O(n2 ) sort.
Since nearly sorted data are fairly common, this result is to be avoided.
Notice that picking the leftmost value is not special. If, instead, we attempt
to find the correct location for the middle value, then other arrangements of
data will cause the degenerate behavior. In short, for any specific or determin-
istic partitioning technique, a degenerate arrangement exists. The key to more
consistent performance, then, is a nondeterministic partitioning that correctly
places a value selected at random (see Problem 6.15). There is, of course, a
very unlikely chance that the data are in order and the positions selected in-
duce a degenerate behavior, but that chance is small and successive runs of
the sorting algorithm on the same data are exceedingly unlikely to exhibit the
same behavior. So, although the worst-case behavior is still O(n2 ), its expected
behavior is O(n log n).
Quicksort is an excellent sort when data are to be sorted with little extra
space. Because the speed of partitioning depends on the random access nature
of arrays or Vectors, quicksort is not suitable when not used with random access
structures. In these cases, however, other fast sorts are often possible.

6.6 Radix Sort

After investigating a number of algorithms that sort in O(n2 ) or O(n log n) time,
one might wonder if it is possible to sort in linear time. If the right conditions
hold, we can sort certain types of data in linear time. First, we must investigate
a pseudogame, 52 pickup!
Suppose we drop a deck of 52 cards on the floor, and we want to not only
pick them up, but we wish to sort them at the same time. It might be most
natural to use an insertion sort: we keep a pile of sorted cards and, as we pick
up new cards, we insert them in the deck in the appropriate position. A more
efficient approach makes use of the fact that we know what the sorted deck
looks like. We simply lay out the cards in a row, with each position in the row
reserved for the particular card. As we pick up a card, we place it in its reserved
location. In the end, all the cards are in their correct location and we collect
them from left to right.
Exercise 6.1 Explain why this sorting technique always takes O(n) time for a
deck of n cards.
Such an approach is the basis for a general sorting technique called bucket sort.
By quickly inspecting values (perhaps a word) we can approximately sort them
6.6 Radix Sort 135

into different buckets (perhaps based on the first letter). In a subsequent pass
we can sort the values in each bucket with, perhaps a different sort. The buck-
ets of sorted values are then accumulated, carefully maintaining the order of
the buckets, and the result is completely sorted. Unfortunately, the worst-case
behavior of this sorting technique is determined by the performance of the al-
gorithm we use to sort each bucket of values.

Exercise 6.2 Suppose we have n values and m buckets and we use insertion sort
to perform the sort of each bucket. What is the worst-case time complexity of this
sort?

Such a technique can be used to sort integers, especially if we can partially sort
the values based on a single digit. For example, we might develop a support
function, digit, that, given a number n and a decimal place d, returns the
value of the digit in the particular decimal place. If d was 0, it would return the
units digit of n. Here is a recursive implementation:

public static int digit(int n, int d)

// pre: n >= 0 and d >= 0
// post: returns the value of the dth decimal place of n
// where the units place has position 0 RadixSort
{
if (d == 0) return n % 10;
else return digit(n/10,d-1);
}

Here is the code for placing an array of integer values among 10 buckets, based
on the value of digit d. For example, if we have numbers between 1 and 52 and
we set d to 2, this code almost sorts the values based on their 10’s digit.

public static void bucketPass(int data[], int d)

// pre: data is an array of data values, and d >= 0
// post: data is sorted by the digit found in location d;
// if two values have the same digit in location d, their
// relative positions do not change; i.e., they are not swapped
{
int i,j;
int value;
// allocate some buckets
Vector<Vector<Integer>> bucket = new Vector<Vector<Integer>>(10);
bucket.setSize(10);
// allocate Vectors to hold values in each bucket
for (j = 0; j < 10; j++) bucket.set(j,new Vector<Integer>());
// distribute the data among buckets
int n = data.length;
for (i = 0; i < n; i++)
{
value = data[i];
// determine the d'th digit of value
136 Sorting

j = digit(value,d);
// add data value to end of vector; keeps values in order
bucket.get(j).add(value);
}
// collect data from buckets back into array
// collect in reverse order to unload Vectors
// in linear time
i = n;
for (j = 9; j >= 0; j--)
{
// unload all values in bucket j
while (!bucket.get(j).isEmpty())
{
i--;
value = bucket.get(j).remove();
data[i] = value;
}
}
}

We now have the tools to support a new sort, radix sort. The approach is to
use the bucketPass code to sort all the values based on the units place. Next,
all the values are sorted based on their 10’s digit. The process continues until
enough passes have been made to consider all the digits. If it is known that
values are bounded above, then we can also bound the number of passes as
well. Here is the code to perform a radix sort of values under 1 million (six
passes):

public static void radixSort(int data[])

// pre: data is array of values; each is less than 1,000,000
// post: data in the array are sorted into increasing order
{
for (int i = 0; i < 6; i++)
{
bucketPass(data,i);
}
}

After the first bucketPass, the values are ordered, based on their units digit. All
values that end in 0 are placed near the front of data (see Figure 6.9), all the
values that end in 9 appear near the end. Among those values that end in 0, the
values appear in the order they originally appeared in the array. In this regard,
we can say that bucketPass is a stable sorting technique. All other things being
equal, the values appear in their original order.
During the second pass, the values are sorted, based on their 10’s digit.
Again, if two values have the same 10’s digit, the relative order of the values is
maintained. That means, for example, that 140 will appear before 42, because
after the first pass, the 140 appeared before the 42. The process continues, until
6.6 Radix Sort 137

Start

140 2 1 43 3 65 0 11 58 3 42 4
Digit 0
140 0 1 11 2 42 43 3 3 4 65 58
Digit 1
0 1 2 3 3 4 11 140 42 43 58 65
Digit 2
0 1 2 3 3 4 11 42 43 58 65 140
Digit 3
0 1 2 3 3 4 11 42 43 58 65 140
Digit 4
0 1 2 3 3 4 11 42 43 58 65 140
Digit 6
0 1 2 3 3 4 11 42 43 58 65 140

Finish

Figure 6.9 The state of the data array between the six passes of radixSort. The
boundaries of the buckets are identified by vertical lines; bold lines indicate empty buck-
ets. Since, on every pass, paths of incoming values to a bucket do not cross, the sort
is stable. Notice that after three passes, the radixSort is finished. The same would be
true, no matter the number of values, as long as they were all under 1000.
138 Sorting

all digits are considered. Here, six passes are performed, but only three are
necessary (see Problem 6.9).
There are several important things to remember about the construction of
this sort. First, bucketPass is stable. That condition is necessary if the work
of previous passes is not to be undone. Secondly, the sort is unlikely to work if
the passes are performed from the most significant digit toward the units digit.
Finally, since the number of passes is independent of the size of the data array,
the speed of the entire sort is proportional to the speed of a single pass. Careful
design allows the bucketPass to be accomplished in O(n) time. We see, then,
that radixSort is a O(n) sorting method.
While, theoretically, radixSort can be accomplished in linear time, practi-
cally, the constant of proportionality associated with the bound is large com-
pared to the other sorts we have seen in this chapter. In practice, radixSort is
inefficient compared to most other sorts.

6.7 Sorting Objects

Sorting arrays of integers is suitable for understanding the performance of vari-
ous sorts, but it is hardly a real-world problem. Frequently, the object that needs
to be sorted is an Object with many fields, only some of which are actually used
in making a comparison.
Let’s consider the problem of sorting the entries associated with an electronic
phone book. The first step is to identify the structure of a single entry in the
phone book. Perhaps it has the following form:

class PhoneEntry
{
String name; // person's name
PhoneBook String title; // person's title
int extension; // telephone number
int room; // number of room
String building; // office building

public PhoneEntry(String n, String t, int e,

String b, int r)
// post: construct a new phone entry
{
...
}

public int compareTo(PhoneEntry other)

// pre: other is non-null
// post: returns integer representing relation between values
{
return this.extension - other.extension;
}
}
6.7 Sorting Objects 139

0 Blumenauer, Earl Rep. 54881 1406 Longworth

1 DeFazio, Peter Rep. 56416 2134 Rayburn

2 Hooley, Darlene Rep. 55711 1130 Longworth

3 Smith, Gordon Senator 43753 404 Russell

4 Walden, Greg Rep. 56730 1404 Longworth

5 Wu, David Rep. 50855 1023 Longworth

6 Wyden, Ron Senator 45244 516 Hart

Data before sorting

0 Smith, Gordon Senator 43753 404 Russell

1 Wyden, Ron Senator 45244 516 Hart

2 Wu, David Rep. 50855 1023 Longworth
3 Blumenauer, Earl Rep. 54881 1406 Longworth
4 Hooley, Darlene Rep. 55711 1130 Longworth

5 DeFazio, Peter Rep. 56416 2134 Rayburn

6 Walden, Greg Rep. 56730 1404 Longworth

Data after sorting by telephone

Figure 6.10 An array of phone entries for the 107th Congressional Delegation from
Oregon State, before and after sorting by telephone (shaded).

We have added the compareTo method to describe the relation between two
entries in the phone book (the shaded fields of Figure 6.10). The compareTo
method returns an integer that is less than, equal to, or greater than 0 when
this is logically less than, equal to, or greater than other. We can now modify
any of the sort techniques provided in the previous section to sort an array of
phone entries:

public static void insertionSort(PhoneEntry data[], int n)

// pre: n <= data.length
// post: values in data[0..n-1] are in ascending order
{
int numSorted = 1; // number of values in place
int index; // general index
while (numSorted < n)
{
// take the first unsorted value
PhoneEntry temp = data[numSorted];
// ...and insert it among the sorted:
140 Sorting

for (index = numSorted; index > 0; index--)

{
if (temp.compareTo(data[index-1]) < 0)
{
data[index] = data[index-1];
} else {
break;
}
}
// reinsert value
data[index] = temp;
numSorted++;
}
}

Careful review of this insertion sort routine shows that all the < operators have
been replaced by checks for negative compareTo values. The result is that the
phone entries in the array are ordered by increasing phone number.
If two or more people use the same extension, then the order of the resulting
entries depends on the stability of the sort. If the sort is stable, then the relative
order of the phone entries with identical extensions in the sorted array is the
same as their relative order in the unordered array. If the sort is not stable, no
guarantee can be made. To ensure that entries are, say, sorted in increasing
order by extension and, in case of shared phones, sorted by increasing name,
the following compareTo method might be used:

public int compareTo(PhoneEntry other)

// pre: other is non-null
// post: returns integer representing relation between values
{
if (this.extension != other.extension)
return this.extension - other.extension;
else return this.name.compareTo(other.name);
}

Correctly specifying the relation between two objects with the compareTo meth-
od can be difficult when the objects cannot be totally ordered. Is it always possi-
ble that one athletic team is strictly less than another? Is it always the case that
one set contains another? No. These are examples of domains that are partially
ordered. Usually, however, most types may be totally ordered, and imagining
how one might sort a collection of objects forces a suitable relation between
any pair.

6.8 Ordering Objects Using Comparators

The definition of the compareTo method for an object should define, in a sense,
the natural ordering of the objects. So, for example, in the case of a phone
6.8 Ordering Objects Using Comparators 141

book, the entries would ideally be ordered based on the name associated with
the entry. Sometimes, however, the compareTo method does not provide the
ordering desired, or worse, the compareTo method has not been defined for an
object. In these cases, the programmer turns to a simple method for specifing an
external comparison method called a comparator. A comparator is an object that
contains a method that is capable of comparing two objects. Sorting methods,
then, can be developed to apply a comparator to two objects when a comparison
is to be performed. The beauty of this mechanism is that different comparators
can be applied to the same data to sort in different orders or on different keys.
In Java a comparator is any class that implements the java.util.Comparator
interface. This interface provides the following method:
package java.util;
public interface Comparator
{
public abstract int compare(Object a, Object b); Comparator
// pre: a and b are valid objects, likely of similar type
// post: returns a value less than, equal to, or greater than 0
// if a is less than, equal to, or greater than b
}

Like the compareTo method we have seen earlier, the compare method re-
turns an integer that identifies the relationship between two values. Unlike
the compareTo method, however, the compare method is not associated with
the compared objects. As a result, the comparator is not privy to the implemen-
tation of the objects; it must perform the comparison based on information that
is gained from accessor methods.
As an example of the implementation of a Comparator, we consider the
implementation of a case-insensitive comparison of Strings, called Caseless-
Comparator. This comparison method converts both String objects to upper-
case and then performs the standard String comparison:
public class CaselessComparator implements java.util.Comparator<String>
{
public int compare(String a, String b)
// pre: a and b are valid Strings Caseless-
// post: returns a value less than, equal to, or greater than 0 Comparator
// if a is less than, equal to, or greater than b, without
// consideration of case
{
String upperA = ((String)a).toUpperCase();
String upperB = ((String)b).toUpperCase();
return upperA.compareTo(upperB);
}
}

The result of the comparison is that strings that are spelled similarly in differ-
ent cases appear together. For example, if an array contains the words of the
children’s tongue twister:
142 Sorting

Fuzzy Wuzzy was a bear.

Fuzzy Wuzzy had no hair.
Fuzzy Wuzzy wasn't fuzzy, wuzzy?

we would expect the words to be sorted into the following order:

a bear. Fuzzy Fuzzy Fuzzy fuzzy, had hair.

no was wasn't Wuzzy Wuzzy Wuzzy wuzzy?

This should be compared with the standard ordering of String values, which
would generate the following output:

Fuzzy Fuzzy Fuzzy Wuzzy Wuzzy Wuzzy a bear.

fuzzy, had hair. no was wasn't wuzzy?

To use a Comparator in a sorting technique, we need only replace the use

of compareTo methods with compare methods from a Comparator. Here, for
example, is an insertion sort that makes use of a Comparator to order the values
in an array of Objects:

public static <T> void insertionSort(T data[], Comparator<T> c)

// pre: c compares objects found in data
// post: values in data[0..n-1] are in ascending order
CompInsSort {
int numSorted = 1; // number of values in place
int index; // general index
int n = data.length; // length of the array
while (numSorted < n)
{
// take the first unsorted value
T temp = data[numSorted];
// ...and insert it among the sorted:
for (index = numSorted; index > 0; index--)
{
if (c.compare(temp,data[index-1]) < 0)
{
data[index] = data[index-1];
} else {
break;
}
}
// reinsert value
data[index] = temp;
numSorted++;
}
}

Note that in this description we don’t see the particulars of the types involved.
Instead, all data are manipulated as Objects, which are specifically manipulated
by the compare method of the provided Comparator.
6.9 Vector-Based Sorting 143

6.9 Vector-Based Sorting

We extend the phone book example one more time, by allowing the PhoneEntrys
to be stored in a Vector. There are, of course, good reasons to use Vector over
arrays, but there are some added complexities that should be considered. Here
is an alternative Java implementation of insertionSort that is dedicated to the
sorting of a Vector of PhoneEntrys:
protected void swap(int i, int j)
// pre: 0 <= i,j < this.size
// post: elements i and j are exchanged within the vector
{
PhoneEntry temp; PhoneBook
temp = get(i);
set(i,get(j));
set(j,temp);
}

public void insertionSort()

// post: values of vector are in ascending order
{
int numSorted = 0; // number of values in place
int index; // general index
while (numSorted < size())
{
// take the first unsorted value
PhoneEntry temp = (PhoneEntry)get(numSorted);
// ...and insert it among the sorted:
for (index = numSorted; index > 0; index--)
{
if (temp.compareTo((PhoneEntry)get(index-1)) < 0)
{
set(index,get(index-1));
} else {
break;
}
}
// reinsert value
set(index,temp);
numSorted++;
}
}
Recall that, for Vectors, we use the get method to fetch a value and set to
store. Since any type of object may be referenced by a vector entry, we verify the
type expected when a value is retrieved from the vector. This is accomplished
through a parenthesized cast. If the type of the fetched value doesn’t match
the type of the cast, the program throws a class cast exception. Here, we cast
the result of get in the compareTo method to indicate that we are comparing
PhoneEntrys.
144 Sorting

It is unfortunate that the insertionSort has to be specially coded for use

with the PhoneEntry objects.

Exercise 6.3 Write an insertionSort that uses a Comparator to sort a Vector

of objects.

6.10 Conclusions
Sorting is an important and common process on computers. In this chapter we
considered several sorting techniques with quadratic running times. Bubble sort
approaches the problem by checking and rechecking the relationships between
elements. Selection and insertion sorts are based on techniques that people
commonly use. Of these, insertion sort is most frequently used; it is easily
coded and provides excellent performance when data are nearly sorted.
Two recursive sorting techniques, mergesort and quicksort, use recursion
to achieve O(n log n) running times, which are optimal for comparison-based
techniques on single processors. Mergesort works well in a variety of situations,
but often requires significant extra memory. Quicksort requires a random access
structure, but runs with little space overhead. Quicksort is not a stable sort
because it has the potential to swap two values with equivalent keys.
We have seen with radix sort, it is possible to have a linear sorting algorithm,
but it cannot be based on compares. Instead, the technique involves carefully
ordering values based on looking at portions of the key. The technique is, practi-
cally, not useful for general-purpose sorting, although for many years, punched
cards were efficiently sorted using precisely the method described here.
Sorting is, arguably, the most frequently executed algorithm on computers
today. When we consider the notion of an ordered structure, we will find that
algorithms and structures work hand in hand to help keep data in the correct
order.

Self Check Problems

Solutions to these problems begin on page 445.
6.1 Why does it facilitate the swap method to have a temporary reference?
6.2 Cover the numbers below with your hand. Now, moving your hand to
the right, expose each number in turn. On a separate sheet of paper, keep the
list of values you have encounted in order. At the end you have sorted all of the
values. Which sorting technique are you using?
296 457 -95 39 21 12 3.1 64 998 989
6.3 Copy the above table onto a piece of scrap paper. Start a column of
numbers: write down the smallest table value you see into your column, cross-
ing it out of the table. Continue until you have considered each of the values.
What sorting technique are you using?
6.10 Conclusions 145

6.4 During spring cleaning, you decide to sort four months of checks re-
turned with your bank statements. You decide to sort each month separately
and go from there. Is this valid? If not, why. If it is, what happens next?
6.5 A postal employee approximately sorts mail into, say, 10 piles based
on the magnitude of the street number of each address, pile 1 has 1-10, pile
2 has 11-20, etc. The letters are then collected together by increasing pile
number. She then sorts them into a delivery crate with dividers labeled with
street names. The order of streets corresponds to the order they appear on her
mail route. What type of sort is she performing?
6.6 What is the purpose of the compareTo method?

Problems
Solutions to the odd-numbered problems begin on page 464.
6.1 Show that to exchange two integer values it is not strictly necessary to
use a third, temporary integer variable. (Hint: Use addition and/or subtrac-
tion.)
6.2 We demonstrated that, in the worst case, bubble sort performs O(n2 )
operations. We assumed, however, that each pass performed approximately
O(n) operations. In fact, pass i performs as many as O(n − i) operations, for
1 ≤ i ≤ n − 1. Show that bubble sort still takes O(n2 ) time.
6.3 How does bubbleSort (as presented) perform in the best and average
cases?
6.4 On any pass of bubble sort, if no exchanges are made, then the rela-
tions between all the values are those desired, and the sort is done. Using this
information, how fast will bubble sort run in worst, best, and average cases?
6.5 How fast does selection sort run in the best, worst, and average cases?
6.6 How fast does insertion sort run in the best, worst, and average cases?
Give examples of best- and worst-case input for insertion sort.
6.7 Running an actual program, count the number of compares needed to
sort n values using insertion sort, where n varies (e.g., powers of 2). Plot your
data. Do the same thing for quicksort. Do the curves appear as theoretically
expected? Does insertion sort ever run faster than quicksort? If so, at what
point does it run slower?
6.8 Comparing insertion sort to quicksort, it appears that quicksort sorts
more quickly without any increase in space. Is that true?
6.9 At the end of the discussion on radix sort, we pointed out that the digit
sorting passes must occur from right to left. Give an example of an array of 5
two-digit values that do not sort properly if you perform the passes left to right.
6.10 In radix sort, it might be useful to terminate the sorting process when
numbers do not change position during a call to bucketPass. Should this mod-
ification be adopted or not?
146 Sorting

6.11 Using the millisecond timer, determine the length of time it takes to
perform an assignment of a nonzero value to an int. (Hint: It will take less
than a millisecond, so you will have to design several experiments that measure
thousands or millions of assignments; see the previous lab, on page 115, for
details.)
6.12 Running an actual program, and using the millisecond timer, System.-
currentTimeMillis, measure the length of time needed to sort arrays of data
of various sizes using a sort of your choice. Repeat the experiment but use
Vectors. Is there a difference? In either case, explain why. (Hint: You may
have to develop code along the lines of Problem 6.11.)
6.13 A sort is said to be stable if the order of equal values is maintained
throughout the sort. Bubble sort is stable, because whenever two equal val-
ues are compared, no exchange occurs. Which other sorts are stable (consider
insertion sort, selection sort, mergesort, and quicksort)?
6.14 The partition function of quicksort could be changed as follows: To
place the leftmost value in the correct location, count the number of values that
are strictly less than the leftmost value. The resulting number is the correct
index for the desired value. Exchange the leftmost value for the value at the
indexed location. With all other code left as it is, does this support a correctly
functioning quicksort? If not, explain why.
6.15 Modify the partition method used by quicksort so that the pivot is
randomly selected. (Hint: Before partitioning, consider placing the randomly
selected value at the left side of the array.)
6.16 Write a recursive selectionSort algorithm. (Hint: Each level of recur-
sion positions a value in the correct location.)
6.17 Write a recursive insertionSort algorithm.
6.18 Some of the best-performing sorts depend on the best-performing shuf-
fles. A good shuffling technique rearranges data into any arrangement with
equal probability. Design the most efficient shuffling mechanism you can, and
argue its quality. What is its performance?
6.19 Write a program called shuffleSort. It first checks to see if the data are
in order. If they are, the sort is finished. If they aren’t, the data are shuffled and
the process repeats. What is the best-case running time? Is there a worst-case
running time? Why or why not? If each time the data were shuffled they were
arranged in a never-seen-before configuration, would this change your answer?
6.20 Write a program to sort a list of unique integers between 0 and 1 million,
but only using 1000 32-bit integers of space. The integers are read from a file.
6.11 Laboratory: Sorting with Comparators

Objective. To gain experience with Java’s java.util.Comparator interface.

Discussion. In Chapter 6 we have seen a number of different sorting techniques.
Each of the techniques demonstrated was based on the fixed, natural ordering
of values found in an array. In this lab we will modify the Vector class so that it
provides a method, sort, that can be used—with the help of a Comparator—to
order the elements of the Vector in any of a number of different ways.
Procedure. Develop an extension of structure.Vector, called MyVector, that
includes a new method, sort.
Here are some steps toward implementing this new class:
1. Create a new class, MyVector, which is declared to be an extension of the
structure.Vector class. You should write a default constructor for this
class that simply calls super();. This will force the structure.Vector
constructor to be called. This, in turn, will initialize the protected fields of
the Vector class.
2. Construct a new Vector method called sort. It should have the following
declaration:

public void sort(Comparator<T> c)

// pre: c is a valid comparator
// post: sorts this vector in order determined by c

This method uses a Comparator type object to actually perform a sort of

the values in MyVector. You may use any sort that you like.
3. Write an application that reads in a data file with several fields, and, de-
pending on the Comparator used, sorts and prints the data in different
orders.

Thought Questions. Consider the following questions as you complete the lab:
1. Suppose we write the following Comparator:

import structure5.*;
import java.util.Iterator;
import java.util.Comparator;
import java.util.Scanner;
public class RevComparator<T> implements Comparator<T>
{
protected Comparator<T> base;

public RevComparator(Comparator<T> baseCompare)

{
base = baseCompare;
148 Sorting

public int compare(T a, T b)

{
return -base.compare(a,b);
}
}

What happens when we construct:

MyVector<Integer> v = new MyVector<Integer>();

Scanner s = new Scanner(System.in);

while (s.hasNextInt())
{
v.add(s.nextInt());
}

Comparator<Integer> c = new RevComparator<Integer>(new IntegerComparator());

v.sort(c);

2. In our examples, here, a new Comparator is necessary for each sorting

order. How might it be possible to add state information (protected
data) to the Comparator to allow it to sort in a variety of different ways?
One might imagine, for example, a method called ascending that sets the
Comparator to sort into increasing order. The descending method would
set the Comparator to sort in reverse order.

Notes:
Chapter 7
A Design Method

Concepts:
. Signatures But, luckily, he kept his wits and his purple crayon.
. Interface design —Crockett Johnson
. Abstract base classes

T HROUGHOUT THE REST of this book we consider a number of data structures–

first from an abstract viewpoint and then as more detailed implementations. In
the process of considering these implementations, we will use a simple design
method that focuses on the staged development of interfaces and abstract base
classes. Here, we outline the design method. In the first section we describe the
process. The remaining sections are dedicated to developing several examples.

7.1 The Interface-Based Approach

As we have seen in our discussion of abstract data types, the public aspect of
the data type—that part that users depend on—is almost entirely incorporated
in the interface. In Java the interface is a formal feature of the language. Inter-
faces allow the programmer of an abstract data type to specify the signatures of
each of the externally visible methods, as well as any constants that might be
associated with implementations.
The development and adherence to the interface is the most important part
of the development of an implementation. The process can be outlined as fol-
lows:

1. Design of the interface. The interface describes the common external fea-
tures of all implementations.

2. An abstract implementation. The abstract implementation describes the

common internal features of all implementations.

3. Extension of the abstract class. Each implementation suggests an indepen-

dent approach to writing code that extends the abstract implementation
and supports the required elements of the interface.
150 A Design Method

7.1.1 Design of the Interface

The designer first considers, in as much detail as possible, an abstract data
structure’s various internal states. For example, if we are to consider a Vector
abstractly, we pull out a napkin, and draw an abstract Vector and we consider
the various effects that Vector operations might have on its structure. In our
napkin-as-design-tool strategy, we might find ourselves using ellipses to suggest
that we expect the Vector to be unbounded in size; we might use outward
arrows to suggest the effect of accessor methods or methods that remove values;
and we might blot out old Vector values in favor of new values when mutators
are used. The designer must develop, from these free-flowing abstract notions
of a structure, a collection of precise notions of how structures are accessed and
mutated. It is also important to understand which states of the abstract structure
are valid, and how the various methods ensure that the structure moves from
one valid state to the next.
Armed with this information, the designer develops the interface—the exter-
nal description of how users of the structure can interact with it. This consists
of

1. A list of constant (final static) values that help provide meaning to

values associated with the abstract structure. For example, any models of
an atom might provide constants for the masses of electrons, protons, and
neutrons. Each of these constants is declared within the atom interface
and becomes part of any implementation.

2. Implementation-independent publicly accessible methods that access or

modify data. For example, if we described an interface for a time-of-day
clock, methods for reading and setting the current time would be declared
part of the public interface. A method that made the clock “tick,” caus-
ing time to move forward, would not be declared as part of the interface
because it would not be a feature visible to the user. From the user’s stand-
point, the clock ticks on its own. How the clock ticks is not an abstract
feature of the clock.

3. If an interface appears to be a refinement of another interface, it is com-

mon practice to have the one extend the other. This is useful if the new
objects should be usable wherever the previously declared values are used.

Once the interface has been defined, it can be put to immediate use. Potential
users of the class can be asked to review it. In fact, application code can be
written to make use of the new interface. Later, if particular implementations
are developed, the application code can be put to use. It is important to remem-
ber, however, that the development of the application and the implementation
of the data structure may both proceed at the same time.
7.1 The Interface-Based Approach 151

7.1.2 Development of an Abstract Implementation

Once the interface has been outlined, it is useful for the designer to consider
those functions of the structure that are implementation independent. These
pieces are gathered together in a partial or abstract implementation of the in-
terface called an abstract base class. Since some parts of the interface may not
be implemented in the abstract base class—perhaps they require a commitment
to a particular implementation approach—it is necessary for the class to be de-
clared abstract. Once the abstract class is implemented, it may be used as a
basis for developing extensions that describe particular implementations.
Some structures may have some built-in redundancy in their public methods.
An interface supporting trigonometric calculations might, for example, have a
method tan which computes its result from sin and cos. No matter how sin
and cos are actually implemented, the tan method can be implemented in this
manner. On the other hand, if a tan function can be computed in a more di-
rect manner—one not dependent on sin and cos—a particular implementation
might override the method outlined in the abstract base class.
A similar approach is taken in Vector-like classes that implement a backward-
compatible setElementAt method based on the more recently added set method.
Such a method might appear in an abstract base class as

public void setElementAt(E obj, int index)

// pre: 0 <= index && index < size()
// post: element value is changed to obj Vector
{
set(index,obj);
}

Because such code cannot be included in any interface that might describe a
Vector, we place the code in the abstract class.
Implementors of other abstract objects may find it useful to develop a com-
mon library of methods that support all implementations. These methods—
often declared privately—are only made available to the implementor of the
class. If they are utility methods (like sin and sqrt) that are not associated
with a particular object, we also declare them static.
Thus the abstract base class provides the basis for all implementations of
an interface. This includes implementation-independent code that need not be
rewritten for each implementation. Even if an abstract base class is empty, it is
useful to declare the class to facilitate the implementation of implementation-
independent development later in the life of the data structure. It is frequently
the case, for example, that code that appears in several implementations is re-
moved from the specific implementations and shared from the abstract base
class. When implementations are actually developed, they extend the associ-
ated abstract base class.
152 A Design Method

7.1.3 Implementation
When the abstract base class is finished, it is then possible for one or more im-
plementations to be developed. Usually each of these implementations extends
the work that was started in the abstract base class. For example, a Fraction
interface might be implemented as the ratio of two values (as in the Ratio
class we saw in Chapter 1), or it might be implemented as a double. In the
latter case, the double is converted to an approximate ratio of two integers,
the numerator and denominator. In both cases, it might be useful to declare an
AbstractFraction class that includes a greatest common divisor (gcd) method.
Such a method would be declared protected and static.

7.2 Example: Development of Generators

As an example, we develop several implementations of an object that gener-
ates a sequence of values—an object we will call a generator. Such an object
might generate randomly selected values, or it might generate, incrementally, a
sequence of primes.
We imagine the interface would include the following methods:

public interface Generator

{
public void reset();
Generator // post: the generator is reset to the beginning of the sequence;
// the current value can be immediately retrieved with get.

public int next();

// post: returns true iff more elements are to be generated.

public int get();

// post: returns the current value of the generator.
}

The Generator is constructed and the get method can be used to get its initial
value. When necessary, the next routine generates, one at a time, a sequence of
integer values. Each call to next returns the next value in the sequence, a value
that can be recalled using the get method. If necessary, the reset method can
be used to restart the sequence of generated values.
The next step is to generate an abstract base class that implements the inter-
face. For the AbstractGenerator we implement any of the methods that can
be implemented in a general manner. We choose, here, for example, to provide
a mechanism for the next method to save the current value:

abstract public class AbstractGenerator

implements Generator
Abstract- {
Generator protected int current; // the last value saved
7.2 Example: Development of Generators 153

public AbstractGenerator(int initial)

// post: initialize the current value to initial
{
current = initial;
}

public AbstractGenerator()
// post: initialize the current value to zero
{
this(0);
}

protected int set(Integer next)

// post: sets the current value to next, and extends the sequence
{
int result = current;
current = next;
return result;
}

public int get()

// post: returns the current value of the sequence
{
return current;
}

public void reset()

// post: resets the Generator (by default, does nothing)
{
}
}

The current variable keeps track of a single integer—ideally the last value gen-
erated. This value is the value returned by the get method. A hidden method—
set—allows any implementation to set the value of current. It is expected
that this is called by the next method of the particular implementation. By pro-
viding this code in the abstract base class, individual implementations needn’t
repeatedly reimplement this common code. By default, the reset method does
nothing. If a particular generator does not require a reset method, the default
method does nothing.
Here is a simple implementation of a Generator that generates a constant
value. The value is provided in the constructor:

public class ConstantGenerator extends AbstractGenerator

{
public ConstantGenerator(int c)
// pre: c is the value to be generated. Constant-
// post: constructs a generator that returns a constant value Generator
154 A Design Method

{
set(c);
}

public int next()

// post: returns the constant value
{
return get();
}
}

The set method of the AbstractGenerator is called from the constructor, record-
ing the constant value to be returned. This effectively implements the get
method—that code was provided in the AbstractGenerator class. The next
method simply returns the value available from the get method.
Another implementation of a Generator returns a sequence of prime num-
bers. In this case, the constructor sets the current value of the generator to
2—the first prime. The next method searches for the next prime and returns
that value after it has been saved. Here, the private set and the public get
methods from the AbstractGenerator class help to develop the state of the
Generator:

public class PrimeGenerator extends AbstractGenerator

{
public PrimeGenerator()
PrimeGenerator // post: construct a generator that delivers primes starting at 2.
{
reset();
}

public void reset()

// post: reset the generator to return primes starting at 2
{
set(2);
}

public int next()

// post: generate the next prime
{
int f,n = get();
do
{
if (n == 2) n = 3;
else n += 2;

// check the next value

for (f = 2; f*f <= n; f++)
{
if (0 ==(n % f)) break;
7.3 Example: Playing Cards 155

}
} while (f*f <= n);
set(n);
return n;
}
}

Clearly, the reset method is responsible for restarting the sequence at 2. While
it would be possible for each Generator to keep track of its current value in its
own manner, placing that general code in the AbstractGenerator reduces the
overall cost of keeping track of this information for each of the many implemen-
tations.

Exercise 7.1 Implement a Generator that provides a stream of random integers.

After a call to reset, the random sequence is “rewound” to return the same se-
quence again. Different generators should probably generate different sequences.
(Hint: You may find it useful to use the setSeed method of java.util.Random.)

7.3 Example: Playing Cards

Many games involve the use of playing cards. Not all decks of cards are the
same. For example, a deck of bridge cards has four suits with thirteen cards in
each suit. There are no jokers. Poker has a similar deck of cards, but various
games include special joker or wild cards. A pinochle deck has 48 cards con-
sisting of two copies of 9, jack, queen, king, 10, and ace in each of four suits.
The ranking of cards places 10 between king and ace. A baccarat deck is as in
bridge, except that face cards are worth nothing. Cribbage uses a standard deck
of cards, with aces low.
While there are many differences among these card decks, there are some
common features. In each, cards have a suit and a face (e.g., ace, king, 5). Most
decks assign a value or rank to each of the cards. In many games it is desirable
to be able to compare the relative values of two cards. With these features in
mind, we can develop the following Card interface:

public interface Card

{
public static final int ACE = 1;
public static final int JACK = 11; Card
public static final int QUEEN = 12;
public static final int KING = 13;
public static final int JOKER = 14;
public static final int CLUBS = 0;
public static final int DIAMONDS = 1;
public static final int HEARTS = 2;
public static final int SPADES = 3;
public int suit();
156 A Design Method

// post: returns the suit of the card

public int face();

// post: returns the face of the card, e.g., ACE, 3, JACK

public boolean isWild();

// post: returns true iff this card is a wild card

public int value();

// post: return the point value of the card

public int compareTo(Object other);

// pre: other is valid Card
// post: returns int <,==,> 0 if this card is <,==,> other

public String toString();

// post: returns a printable version of this card
}

The card interface provides all the public methods that we need to have in our
card games, but it does not provide any hints at how the cards are implemented.
The interface also provides standard names for faces and suits that are passed
to and returned from the various card methods.
In the expectation that most card implementations are similar to a stan-
dard deck of cards, we provide an AbstractCard class that keeps track of an
integer—a card index—that may be changed with set or retrieved with get
(both are protected methods):
import java.util.Random;
public abstract class AbstractCard implements Card
{
AbstractCard protected int cardIndex;
protected static Random gen = new Random();

public AbstractCard()
// post: constructs a random card in a standard deck
{
set(randomIndex(52));
}

protected static int randomIndex(int max)

// pre: max > 0
// post: returns a random number n, 0 <= n < max
{
return Math.abs(gen.nextInt()) % max;
}

protected void set(int index)

// post: this card has cardIndex index
{
7.3 Example: Playing Cards 157

cardIndex = index;
}

protected int get()

// post: returns this card's card index
{
return cardIndex;
}

public int suit()

// post: returns the suit of the card
{
return cardIndex / 13;
}

public int face()

// post: returns the face of the card, e.g. ACE, 3, JACK
{
return (cardIndex % 13)+1;
}

public boolean isWild()

// post: returns true iff this card is a wild card
// (default is false)
{
return false;
}

public int value()

// post: return the point value of the card, Ace..King
{
return face();
}

public String toString()

// post: returns a printable version of this card
{
String cardName = "";
switch (face())
{
case ACE: cardName = "Ace"; break;
case JACK: cardName = "Jack"; break;
case QUEEN: cardName = "Queen"; break;
case KING: cardName = "King"; break;
default: cardName = cardName + face(); break;
}
switch (suit())
{
case HEARTS: cardName += " of Hearts"; break;
case DIAMONDS: cardName += " of Diamonds"; break;
158 A Design Method

case CLUBS: cardName += " of Clubs"; break;

case SPADES: cardName += " of Spades"; break;
}
return cardName;
}
}

Our abstract base class also provides a protected random number generator that
returns values from 0 to max-1. We make use of this in the default constructor
for a standard deck; it picks a random card from the usual 52. The cards are
indexed from the ace of clubs through the king of spades. Thus, the face and
suit methods must use division and modulo operators to split the card index
into the two constituent parts. By default, the value method returns the face of
the card as its value. This is likely to be different for different implementations
of cards, as the face values of cards in different games vary considerably.
We also provide a standard toString method that allows us to easily print
out a card. We do not provide a compareTo method because there are complex-
ities with comparing cards that cannot be predicted at this stage. For example,
in bridge, suits play a predominant role in comparing cards. In baccarat they do
not.
Since a poker deck is very similar to our standard implementation, we find
the PokerCard implementation is very short. All that is important is that we
allow aces to have high values:
public class PokerCard extends AbstractCard
{
public PokerCard(int face, int suit)
PokerCard // pre: face and suit have valid values
// post: constructs a card with the particular face value
{
set(suit*13+face-1);
}

public PokerCard()
// post: construct a random poker card.
{
// by default, calls the AbstractCard constructor
}

public int value()

// post: returns rank of card - aces are high
{
if (face() == ACE) return KING+1;
else return face();
}

public int compareTo(Object other)

// pre: other is valid PokerCard
// post: returns relationship between this card and other
7.3 Example: Playing Cards 159

{
PokerCard that = (PokerCard)other;
return value()-that.value();
}
}

Exercise 7.2 Write the value and compareTo methods for a pair of cards where
suits play an important role. Aces are high, and assume that suits are ranked clubs
(low), diamonds, hearts, and spades (high). Assume that face values are only
considered if the suits are the same; otherwise ranking of cards depends on their
suits alone.
The implementation of a pinochle card is particularly difficult. We are inter-
ested in providing the standard interface for a pinochle card, but we are faced
with the fact that there are two copies each of the six cards 9, jack, queen, king,
10, and ace, in each of the four suits. Furthermore we assume that 10 has the
unusual ranking between king and ace. Here’s one approach:
public class PinochleCard extends AbstractCard
{
// cardIndex face suit
// 0 9 clubs PinochleCard
// 1 9 clubs (duplicate)
// ...
// 10 ACE clubs
// 11 ACE clubs (duplicate)
// 12 9 diamonds
// 13 9 diamonds (duplicate)
// ...
// 47 ACE spades (duplicate)

public PinochleCard(int face, int suit, int copy)

// pre: face and suit have valid values
// post: constructs a card with the particular face value
{
if (face == ACE) face = KING+1;
set((suit*2+copy)*6+face-9);
}

public PinochleCard()
// post: construct a random Pinochle card.
{
set(randomIndex(48));
}

public int face()

// post: returns the face value of the card (9 thru Ace)
{
int result = get()%6 + 9;
if (result == 14) result = ACE;
160 A Design Method

return result;
}

public int suit()

// post: returns the suit of the card (there are duplicates!)
{
// this is tricky; we divide by 12 cards (including duplicates)
// per suit, and again by 2 to remove the duplicate
return cardIndex / 12 / 2;
}

public int value()

// post: returns rank of card - aces are high
{
if (face() == ACE) return KING+2;
else if (face() == 10) return KING+1;
else return face();
}

public int compareTo(Object other)

// pre: other is valid PinochleCard
// post: returns relationship between this card and other
{
PinochleCard that = (PinochleCard)other;
return value()-that.value();
}
}

The difficulty is that there is more than one copy of a card. We choose to keep
track of the extra copy, in case we need to distinguish between them at some
point, but we treat duplicates the same in determining face value, suit, and
relative rankings.

7.4 Conclusions
Throughout the remainder of this book we will find it useful to approach each
type of data structure first in an abstract manner, and then provide the details of
various implementations. While each implementation tends to have a distinct
approach to supporting the abstract structure, many features are common to all
implementations. The basic interface, for example, is a shared concept of the
methods that are used to access the data structure. Other features—including
common private methods and shared utility methods—are provided in a basic
implementation called the abstract base class. This incomplete class serves as
a single point of extension for many implementations; the public and private
features of the abstract base class are shared (and possibly overridden) by the
varied approaches to solving the problem.
Chapter 8
Iterators

Concepts:
. Iterators One potato, two potato, three potato, four,
. The AbstractIterator class five potato, six potato, seven potato, more.
. Vector iterators —A child’s iterator
. Numeric iteration

P ROGRAMS MOVE FROM ONE STATE TO ANOTHER . As we have seen, this “state” Ah! Interstate
is composed of the current value of user variables as well as some notion of programs!
“where” the computer is executing the program. This chapter discusses enumer-
ations and iterators—objects that hide the complexities of maintaining the state
of a traversal of a data structure.
Consider a program that prints each of the values in a list. It is important
to maintain enough information to know exactly “where we are” at all times.
This might correspond to a reference to the current value. In other structures
it may be less clear how the state of a traversal is maintained. Iterators help us
hide these complexities. The careful design of these control structures involves,
as always, the development of a useful interface that avoids compromising the
iterator’s implementation or harming the object it traverses.

8.1 Java’s Enumeration Interface

Java defines an interface called an Enumeration that provides the user indirect,
iterative access to each of the elements of an associated data structure, exactly
once. The Enumeration is returned as the result of calling the elements method
of various container classes. Every Enumeration provides two methods:
public interface java.util.Enumeration
{
public abstract boolean hasMoreElements();
// post: returns true iff enumeration has outstanding elements Enumeration
public abstract java.lang.Object nextElement();
// pre: hasMoreElements
// post: returns the next element to be visited in the traversal
}
162 Iterators

The hasMoreElements method returns true if there are unvisited elements of

the associated structure. When hasMoreElements returns false, the traversal
is finished and the Enumeration expires. To access an element of the under-
lying structure, nextElement must be called. This method does two things:
it returns a reference to the current element and then marks it visited. Typi-
cally hasMoreElements is the predicate of a while loop whose body processes
a single element using nextElement. Clearly, hasMoreElements is an impor-
tant method, as it provides a test to see if the precondition for the nextElement
method is met.
The following code prints out a catchy phrase using a Vector enumeration:

public static void main(String args[])

{
// construct a vector containing two strings:
HelloWorld Vector<String> v = new Vector<String>();
v.add("Hello");
v.add("world!");

// construct an enumeration to view values of v

Enumeration i = (Enumeration)v.elements();
while (i.hasMoreElements())
{
// SILLY: v.add(1,"silly");
System.out.print(i.nextElement()+" ");
}
System.out.println();
}

When run, the following immortal words are printed:

Hello world!

There are some important caveats that come with the use of Java’s Enumera-
tion construct. First, it is important to avoid modifying the associated structure
while the Enumeration is active or live. Uncommenting the line marked SILLY
causes the following infinite output to begin:

Hello silly silly silly silly silly silly

A silly virus Inserting the string "silly" as the new second element of the Vector causes it
vector! to expand each iteration of the loop, making it difficult for the Enumeration to
detect the end of the Vector.

Principle 9 Never modify a data structure while an associated Enumeration is

N
NW

NE

live.
W

E
SW

SE

Modifying the structure behind an Enumeration can lead to unpredictable re-

sults. Clearly, if the designer has done a good job, the implementations of both
8.2 The Iterator Interface 163

the Enumeration and its associated structure are hidden. Making assumptions
about their interaction can be dangerous.
Another subtle aspect of Enumerations is that they do not guarantee a par-
ticular traversal order. All that is known is that each element will be visited
exactly once before hasMoreElements becomes false. While we assume that
our first example above will print out Hello world!, the opposite order may
also be possible.
Presently, we develop the concept of an iterator.

8.2 The Iterator Interface

An Iterator is similar to an Enumerator except that the Iterator traverses
an associated data structure in a predictable order. Since this is a behavior and
not necessarily a characteristic of its interface, it cannot be controlled or verified
by a Java compiler. Instead, we must assume that developers of Iterators
will implement and document their structures in a manner consistent with the
following interface:

public interface java.util.Iterator

{
public abstract boolean hasNext();
// post: returns true if there is at least one more value to visit Iterator

public abstract java.lang.Object next();

// pre: hasNext()
// post: returns the next value to be visited
}

While the Iterator is a feature built into the Java language, we will choose to
implement our own AbstractIterator class.

public abstract class AbstractIterator<E>

implements Enumeration<E>, Iterator<E>, Iterable<E>
{
public abstract void reset(); Abstract-
// pre: iterator may be initialized or even amid-traversal Iterator
// post: reset iterator to the beginning of the structure

public abstract boolean hasNext();

// post: true iff the iterator has more elements to visit

public abstract E get();

// pre: there are more elements to be considered; hasNext()
// post: returns current value; ie. value next() will return

public abstract E next();

// pre: hasNext()
// post: returns current value, and then increments iterator
164 Iterators

public void remove()

// pre: hasNext() is true and get() has not been called
// post: the value has been removed from the structure
{
Assert.fail("Remove not implemented.");
}

final public boolean hasMoreElements()

// post: returns true iff there are more elements
{
return hasNext();
}

final public E nextElement()

// pre: hasNext()
// post: returns the current value and "increments" the iterator
{
return next();
}

final public Iterator<E> iterator()

// post: returns this iterator as a subject for a for-loop
{
return this;
}

This abstract base class not only meets the Iterator interface, but also im-
plements the Enumeration interface by recasting the Enumeration methods in
terms of Iterator methods. We also provide some important methods that are
not part of general Iterators: reset and get. The reset method reinitializes
the AbstractIterator for another traversal. The ability to traverse a structure
multiple times can be useful when an algorithm makes multiple passes through
a structure to perform a single logical operation. The same functionality can be
achieved by constructing a new AbstractIterator between passes. The get
method of the AbstractIterator retrieves a reference to the current element of
the traversal. The same reference will be returned by the call to next. Unlike
next, however, get does not push the traversal forward. This is useful when
the current value of an AbstractIterator is needed at a point logically distant
from the call to next.
The use of an AbstractIterator leads to the following idiomatic loop for
traversing a structure:

public static void main(String args[])

{
// construct a vector containing two strings:
HelloWorld
8.3 Example: Vector Iterators 165

Vector<String> v = new Vector<String>();

AbstractIterator<String> i;
v.add("Hello");
v.add("world!");

// construct an iterator to view values of v

for (i = (AbstractIterator<String>)v.iterator(); i.hasNext(); i.next())
{
System.out.print(i.get()+" ");
}
System.out.println();
}

The result is the expected Hello world!

In Java 5 any type that has a method iterator that returns an Iterator<T>
for traversing an object meets the requirements of the Iterable<T> interface.
These classes can make use of a new form of the for loop that simplifies the
previous idiom to:

Vector<String> v = new Vector<String>();

...
for (String word : v)
{
System.out.print(word+" ");
}
System.out.println();

We will see this form of for loop used on many structure classes.

8.3 Example: Vector Iterators

For our first example, we design an Iterator to traverse a Vector called, not
surprisingly, a VectorIterator. We do not expect the user to construct Vector-
Iterators directly—instead the Vector hides the construction and returns the
new structure as a generic Iterator, as was seen in the HelloWorld example.
Here is the iterator method:

public Iterator<E> iterator()

// post: returns an iterator allowing one to
// view elements of vector Vector
{
return new VectorIterator<E>(this);
}

When a Vector constructs an Iterator, it provides a reference to itself (this)

as a parameter. This reference is used by the VectorIterator to recall which
Vector it is traversing.
We now consider the interface for a VectorIterator:

Vector-
Iterator
166 Iterators

class VectorIterator<E> extends AbstractIterator<E>

{
public VectorIterator(Vector<E> v)
// post: constructs an initialized iterator associated with v

public void reset()

// post: the iterator is reset to the beginning of the traversal

public boolean hasNext()

// post: returns true if there is more structure to be traversed

public E get()
// pre: traversal has more elements
// post: returns the current value referenced by the iterator

public E next()
// pre: traversal has more elements
// post: increments the iterated traversal
}
As is usually the case, the nonconstructor methods of VectorIterator exactly
match those required by the Iterator interface. Here is how the VectorIter-
ator is constructed and initialized:
protected Vector<E> theVector;
protected int current;

public VectorIterator(Vector<E> v)
// post: constructs an initialized iterator associated with v
{
theVector = v;
reset();
}

public void reset()

// post: the iterator is reset to the beginning of the traversal
{
current = 0;
}
The constructor saves a reference to the associated Vector and calls reset. This
logically attaches the Iterator to the Vector and makes the first element (if
one exists) current. Calling the reset method allows us to place all the resetting
code in one location.
To see if the traversal is finished, we invoke hasNext:
public boolean hasNext()
// post: returns true if there is more structure to be traversed
{
return current < theVector.size();
}
8.4 Example: Rethinking Generators 167

This routine simply checks to see if the current index is valid. If the index is less
than the size of the Vector, then it can be used to retrieve a current element
from the Vector. The two value-returning methods are get and next:
public E get()
// pre: traversal has more elements
// post: returns the current value referenced by the iterator
{
return theVector.get(current);
}

public E next()
// pre: traversal has more elements
// post: increments the iterated traversal
{
return theVector.get(current++);
}

The get method simply returns the current element. It may be called arbitrarily
many times without pushing the traversal along. The next method, on the other
hand, returns the same reference, but only after having incremented current.
The next value in the Vector (again, if there is one) becomes the current value.
Since all the Iterator methods have been implemented, Java will allow a
VectorIterator to be used anywhere an Iterator is required. In particular, it
can now be returned from the iterator method of the Vector class.
Observe that while the user cannot directly construct a VectorIterator (it
is a nonpublic class), the Vector can construct one on the user’s behalf. This
allows measured control over the agents that access data within the Vector.
Also, an Iterator is a Java interface. It is not possible to directly construct an
Iterator. We can, however, construct any class that implements the Iterator
interface and use that as we would any instance of an Iterator.
Since an AbstractIterator implements the Enumeration interface, we may
use the value returned by Vector’s iterator method as an Enumeration to
access the data contained within the Vector. Of course, treating the Vector-
Iterator as an Enumeration makes it difficult to call the AbstractIterator
methods reset and get.

8.4 Example: Rethinking Generators

In Section 7.2 we discussed the construction of a class of objects that gener-
ated numeric values. These Generator objects are very similar to Abstract-
Iterators—they have next, get, and reset methods. They lack, however, a
hasNext method, mainly because of a lack of foresight, and because many se-
quences of integers are infinite—their hasNext would, essentially, always return
true.
Generators are different from Iterators in another important way: Gen-
erators return the int type, while Iterators return Objects. Because of this,
168 Iterators

the Iterator interface is more general. Any Object, including Integer values,
may be returned from an Iterator.
In this section we experiment with the construction of a numeric iterator—a
Generator-like class that meets the Iterator interface. In particular, we are
interested in constructing an Iterator that generates prime factors of a specific
integer. The PFIterator accepts the integer to be factored as the sole parameter
on the constructor:

import structure5.AbstractIterator;
public class PFGenerator extends AbstractIterator<Integer>
{
PFGenerator // the original number to be factored
protected int base;

public PFGenerator(int value)

// post: an iterator is constructed that factors numbers
{
base = value;
reset();
}
}

The process of determining the prime factor involves reducing the number by a
factor. Initially, the factor f starts at 2. It remains 2 as long as the reduced value
is even. At that point, all the prime factors of 2 have been determined, and we
next try 3. This process continues until the reduced value becomes 1.
Because we reduce the number at each step, we must keep a copy of the
original value to support the reset method. When the iterator is reset, the
original number is restored, and the current prime factor is set to 2.

// base, reduced by the prime factors discovered

protected int n;
// the current prime factor
protected int f;

public void reset()

// post: the iterator is reset to factoring the original value
{
n = base;
// initial guess at prime factor
f = 2;
}

If, at any point, the number n has not been reduced to 1, prime factors
remain undiscovered. When we need to find the current prime factor, we first
check to see if f divides n—if it does, then f is a factor. If it does not, we simply
increase f until it divides n. The next method is responsible for reducing n by a
factor of f.
8.4 Example: Rethinking Generators 169

public boolean hasNext()

// post: returns true iff there are more prime factors to be considered
{
return f <= n; // there is a factor <= n
}

public Integer next()

// post: returns the current prime factor and "increments" the iterator
{
Integer result = get(); // factor to return
n /= f; // reduce n by factor
return result;
}

public Integer get()

// pre: hasNext()
// post: returns the current prime factor
{
// make sure f is a factor of n
while (f <= n && n%f != 0) f++;
return f;
}

We can now write a program that uses the iterator to print out the prime
factors of the values presented on the command line of the Java program as it
is run:
public static void main(String[]args)
{
// for each of the command line arguments
for (int i = 0; i < args.length; i++)
{
// determine the value
int n = Integer.parseInt(args[i]);
PFGenerator g = new PFGenerator(n);
System.out.print(n+": ");
// and print the prime factors of n
while (g.hasNext()) System.out.print(g.next()+" ");
System.out.println();
}
}

For those programmers that prefer to use the hasMoreElements and next-
Element methods of the Enumeration interface, those methods are automat-
ically provided by the AbstractIterator base class, which PFGenerator ex-
tends.

Exercise 8.1 The 3n + 1 sequence is computed in the following manner. Given a

seed n, the next element of the sequence is 3n + 1 if n is odd, or n/2 if n is even.
This sequence of values stops whenever a 1 is encountered; this happens for all
170 Iterators

seeds ever tested. Write an Iterator that, given a seed, generates the sequence of
values that ends with 1.

8.5 Example: Filtering Iterators

We now consider the construction of a filtering iterator. Instead of traversing
structures, a filtering iterator traverses another iterator! As an example, we
construct an iterator that returns the unique values of a structure.
Before we consider the implementation, we demonstrate its use with a sim-
ple example. In the following code, suppose that data is a Vector of Strings,
some of which may be duplicates. For example, the Vector could represent the
text of the Gettysburg Address. The iterator method of data is used to con-
struct a VectorIterator. This is, in turn, used as a parameter to the construc-
tion of a UniqueFilter. Once constructed, the filter can be used as a standard
Iterator, but it only returns the first instance of each String appearing in the
Vector:
Vector<String> data = new Vector<String>(1000);
...
UniqueFilter AbstractIterator<String> dataIterator =
(AbstractIterator<String>)data.iterator();
AbstractIterator<String> ui = new UniqueFilter(dataIterator);
int count=0;

for (ui.reset(); ui.hasNext(); ui.next())

{
System.out.print(ui.get()+" ");
if (++count%7==0) System.out.println();
}
System.out.println();

The result of the program, when run on the Gettysburg Address, is the follow-
ing output, which helps increase the vocabulary of this textbook by nearly 139
words:

four score and seven years ago our

fathers brought forth on this continent a
new nation conceived in liberty dedicated to
the proposition that all men are created
equal now we engaged great civil war
testing whether or any so can long
endure met battlefield of have come dedicate
portion field as final resting place for
those who here gave their lives might
live it is altogether fitting proper should
do but larger sense cannot consecrate hallow
ground brave living dead struggled consecrated far
8.5 Example: Filtering Iterators 171

above poor power add detract world will

little note nor remember what say itcan
never forget they did us rather be
unfinished work which fought thus nobly advanced
task remaining before from these honored take
increased devotion cause last full measure highly
resolve shall not died vain under God
birth freedom government people by perish earth

Fans of compact writing will find this unique.

The UniqueFilter provides the same interface as other iterators. Its con-
structor, however, takes a “base” Iterator as its parameter:

protected AbstractIterator<T> base; // slave iterator

protected List<T> observed; // list of previous values

public UniqueFilter(AbstractIterator<T> baseIterator)

// pre: baseIterator is a non-null iterator
// post: constructs unique-value filter
// host iterator is reset
{
base = baseIterator;
reset();
}

public void reset()

// post: master and base iterators are reset
{
base.reset();
observed = new SinglyLinkedList<T>();
}

When the filter is reset using the reset method, the base iterator is reset as
well. We then construct an empty List of words previously observed. As the
filter progresses, words encountered are incorporated into the observed list.
The current value is fetched by the get method. It just passes the request
along to the base iterator. A similar technique is used with the hasNext method:

public boolean hasNext()

// post: returns true if there are more values available
// from base stream
{
return base.hasNext();
}

public T get()
// pre: traversal has more elements
// post: returns the current value referenced by the iterator
{
172 Iterators

return base.get();
}

Finally, the substance of the iterator is found in the remaining method, next:

public T next()
// pre: traversal has more elements
// post: returns current value and increments the iterator
{
T current = base.next();
// record observation of current value
observed.add(current);
// now seek next new value
while (base.hasNext())
{
T possible = base.get();
if (!observed.contains(possible))
{ // new value found! leave
break;
} else {
// old value, continue
base.next();
}
}
return current;
}

Because this routine can only be called if there is a current value, we record the
current value in the observed list. The method then increments the base iterator
until a new, previously unobserved value is produced, or the base iterator runs
dry.
Some subtle details are worth noting here. First, while we have used a
VectorIterator on a Vector of Strings, the UniqueFilter can be applied, as
is, to any type of iterator and can deliver any type of value. All that is required
is that the base type support the equals method. Secondly, as the filter iterator
progresses, it forces the base iterator to progress, too. Because of this, two filters
are usually not applied to the same base iterator, and the base iterator should
never be modified while the filter is running.

8.6 Conclusions
We have seen that data structures can sometimes be used to control the way
programs focus on and access data. This is made very explicit with Java’s
Enumeration construct that facilitates visiting all the elements of a structure.
When we wish to traverse the elements of a data structure in a predeter-
mined order, we use an Iterator. The Iterator provides access to the ele-
ments of a structure using an interface that is similar to that of an Enumeration.
8.6 Conclusions 173

The abstract base class AbstractIterator implements both the Iterator and
Enumeration interfaces, and provides two new methods—get and reset—as
well. We have also seen that there are weaknesses in the concept of both of
these constructs, because they surrender some of the data hiding and access
controls that are provided by the associated structure. Careful use of these con-
trolling structures, however, can yield useful tools to make traversal of struc-
tures simpler.

Self Check Problems

Solutions to these problems begin on page 445.
8.1 Suppose e is an Enumeration over some data structure. Write a loop
using e to print all the values of the data structure.
8.2 Suppose i is an Iterator over some data structure. Write a loop using
i to print all the values of the data structure.
8.3 Suppose that v is a Vector of Integer values. Write a loop that will use
an Iterator to print those Integer values that are even.
8.4 It is possible to write down the integers 1 through 15 in an order such
that each adjacent pair of integers sums to a perfect square. Write a loop that
prints Perfect! only if the adjacent Integer values generated by the Iterator
g sum to perfect squares. (You needn’t verify the number or range of values.)

Problems
Solutions to the odd-numbered problems begin on page 467.
8.1 Since the get method is available to the AbstractIterator, the next
method does not appear to need to return a value. Why does our implementa-
tion return the value?
8.2 Write an Iterator that works on Strings. Each value returned should
be an object of type Character.
8.3 Write an Iterator that returns a stream of Integers that are prime.
How close is it to the Generator implementation of Section 7.2?
8.4 Write a filtering iterator, ReverseIterator, that reverses the stream of
values produced by another Iterator. You may assume that the base Iterator
will eventually have no more elements, but you may not bound the number.
8.5 Write a filtering iterator, OrderedIterator, that sorts the stream of
values produced by another Iterator. You may assume that the base Iterator
will eventually have no more elements, but you may not bound the number.
8.6 Write a filtering iterator, ShuffleIterator, that shuffles the stream of
values produced by another Iterator. You may assume that the base Iterator
will eventually have no more elements, but you may not bound the number.
174 Iterators

8.7 Write a filtering iterator that takes a base iterator and an Object (called
predicate) with a static select method defined. This iterator passes along
only those values that generate true when passed to the select method of the
predicate Object.
8.7 Laboratory: The Two-Towers Problem

Objective. To investigate a difficult problem using Iterators.

Discussion. Suppose that we are given n uniquely sized cubic blocks and that
each block has a face area between 1 and n. Build two towers by stacking these
blocks. How close can we get the heights of the two towers? The following
two towers built by stacking 15 blocks, for example, differ in height by only 129
millions of an inch (each unit is one-tenth of an inch):
1 2
4 3
5 8
6
11
7
9 12
10 13
14 15

Still, this stacking is only the second-best solution! To find the best stacking, we
could consider all the possible configurations.
We do know one thing: the total height of the two towers is computed by
summing the heights of all the blocks:
n
X √
h= i
i=1

If we consider all the subsets of the n blocks, we can think of the subset as the
set of blocks that make up, say, the left tower. We need only keep track of that
subset that comes closest to h/2 without exceeding it.
In this lab, we will represent a set of n distinct objects by a Vector, and we
will construct an Iterator that returns each of the 2n subsets.
Procedure. The trick to understanding how to generate a subset of n values
from a Vector is to first consider how to generate a subset of indices of elements
from 0 to n − 1. Once this simpler problem is solved, we can use the indices to
help us build a Vector (or subset) of values identified by the indices.
There are exactly 2n subsets of values 0 to n−1. We can see this by imagining
that a coin is tossed n times—once for each value—and the value is added to
the subset if the coin flip shows a head. Since there are 2 × 2 × · · · × 2 = 2n
different sequences of coin tosses, there are 2n different sets.
We can also think of the coin tosses as determining the place values for n
different digits in a binary number. The 2n different sequences generate binary
numbers in the range 0 through 2n − 1. Given this, we can see a line of attack:
176 Iterators

count from 0 to 2n −1 and use the binary digits (bits) of the number to determine
which of the original values of the Vector are to be included in a subset.
Computer scientists work with binary numbers frequently, so there are a
number of useful things to remember:

• An int type is represented by 32 bits. A long is represented by 64 bits. For

maximum flexibility, it would be useful to use long integers to represent
sets of up to 64 elements.

• The arithmetic shift operator (<<) can be used to quickly compute powers
of 2. The value 2i can be computed by shifting a unit bit (1) i places to the
left. In Java we write this 1<<i. This works only for nonnegative, integral
powers. (For long integers, use 1L<<i.)

• The bitwise and of two integers can be used to determine the value of
a single bit in a number’s binary representation. To retrieve bit i of an
integer m we need only compute m & (1<<i).

Armed with this information, the process of generating subsets is fairly straight-
forward. One line of attack is the following:

1. Construct a new extension to the AbstractIterator class. (By extending

the AbstractIterator we support both the Iterator and Enumeration
interfaces.) This new class should have a constructor that takes a Vector
as its sole argument. Subsets of this Vector will be returned as the
Iterator progresses.
2. Internally, a long value is used to represent the current subset. This value
increases from 0 (the empty set) to 2n − 1 (the entire set of values) as the
Iterator progresses. Write a reset method that resets the subset counter
to 0.

3. Write a hasNext method that returns true if the current value is a reason-
able representation of a subset.

4. Write a get method that returns a new Vector of values that are part of
the current subset. If bit i of the current counter is 1, element i of the
Vector is included in the resulting subset Vector.
5. Write a next method. Remember it returns the current subset before in-
crementing the counter.

6. For an Iterator you would normally have to write a remove method. If

you extend the AbstractIterator class, this method is provided and will
do nothing (this is reasonable).

You can now test your new SubsetIterator by having it print all the subsets
of a Vector of values. Remember to keep the Vector small. If the original values
are all distinct, the subsets should all have different values.
8.7 Laboratory: The Two-Towers Problem 177

√ To√solve the√ two-towers problem, write a main method that inserts the values
1, 2,. . . , n as Double objects into a Vector. A SubsetIterator is then
used to construct 2n subsets of these values. The values of each subset are
summed, and the sum that comes closest to, but does not exceed, the value
h/2 is remembered. After all the subsets have been considered, print the best
solution.
Thought Questions. Consider the following questions as you complete the lab:

1. What is the best solution to the 15-block problem?

2. This method of exhaustively checking the subsets of blocks will not work
for very large problems. Consider, for example, the problem with 50
blocks: there are 250 different subsets. One approach is to repeatedly
pick and evaluate random subsets of blocks (stop the computation after
1 second of elapsed time, printing the best subset found). How would you
implement randomSubset, a new SubsetIterator method that returns a
random subset?

Notes:
Chapter 9
Lists

Concepts:
. The list abstraction
He’s makin’ a list
. Singly linked lists
and checkin’ it twice!
. Doubly linked lists
—Haven Gillespie
. Circular lists
. Vectors as lists

I MAGINE YOU ARE TO WRITE A ROBUST PROGRAM to handle varying amounts of

data. An inventory program is a classic example. The same inventory program
might be used to keep track of either tens of items, or millions. To support such
applications, Vectors and arrays are not ideal. As they reach their capacity they
must be expanded. Either this happens manually, as with arrays, or automati-
cally, as with Vectors. In either case the penalty for growing the structure is the
same over the growth of the structure. With a Vector, for example, when the
structure must double in size, the cost of adding an element is proportional to
the size of the Vector.
In this chapter, we develop the concept of a linked list. A linked list is a
dynamic structure that grows and shrinks exactly when necessary and whose
elements may be added in constant time. There is some cost for this dynamic
behavior, however. As with Vectors and arrays, each of the elements of a linked-
list has an associated index, but the elements of many linked list implementa-
tions cannot be efficiently accessed out of order or accessed randomly. Despite
this one inefficiency, linked lists provide an important building block for the
design of many effective data structures.
An analogy for linked lists is a child’s string of snap-together beads. As we
grow the string of beads, we attach and detach new beads on either the front
(head) or rear (tail). Since there are two modifying operations that we can per-
form (add or remove) and two ends (at the location of the first or last element)
there are four operations that change the length of the structure at the end.
We may also wish to perform operations on the internal portion of the list.
For example, we may want to test for inclusion (Is there a red bead?) or extract
an element (Remove a red bead!). These operations require a traversal of the
linked list from one of the two ends.

If you have
never seen
these, visit your
niece.
180 Lists

Now, let’s see what the Java description of a list looks like:

public interface List<E> extends Structure<E>

{
List public int size();
// post: returns number of elements in list

public boolean isEmpty();

// post: returns true iff list has no elements

public void clear();

// post: empties list

public void addFirst(E value);

// post: value is added to beginning of list

public void addLast(E value);

// post: value is added to end of list

public E getFirst();
// pre: list is not empty
// post: returns first value in list

public E getLast();
// pre: list is not empty
// post: returns last value in list

public E removeFirst();
// pre: list is not empty
// post: removes first value from list

public E removeLast();
// pre: list is not empty
// post: removes last value from list

public E remove(E value);

// post: removes and returns element equal to value
// otherwise returns null

public void add(E value);

// post: value is added to tail of list

public E remove();
// pre: list has at least one element
// post: removes last value found in list

public E get();
// pre: list has at least one element
// post: returns last value found in list
 181

public boolean contains(E value);

// pre: value is not null
// post: returns true iff list contains an object equal to value

public int indexOf(E value);

// pre: value is not null
// post: returns (0-origin) index of value,
// or -1 if value is not found

public int lastIndexOf(E value);

// pre: value is not null
// post: returns (0-origin) index of value,
// or -1 if value is not found

public E get(int i);

// pre: 0 <= i < size()
// post: returns object found at that location

public E set(int i, E o);

// pre: 0 <= i < size()
// post: sets ith entry of list to value o;
// returns old value

public void add(int i, E o);

// pre: 0 <= i <= size()
// post: adds ith entry of list to value o

public E remove(int i);

// pre: 0 <= i < size()
// post: removes and returns object found at that location

public Iterator<E> iterator();

// post: returns an iterator allowing
// ordered traversal of elements in list
}

Again, because this structure is described as an interface (as opposed to a

class) Java understands this to be a contract describing the methods that are
required of lists. We might think of an interface as being a “structural precondi-
tion” describing the outward appearance of any “listlike” class. If we write our
code in terms of this interface, we may only invoke methods specified within
the contract.
Note that the List interface is an extension of the Structure interface that
we have seen earlier, in Section 1.8. Thus, every List is also a Structure—a
structure that supports operations like add and remove as well as other size-
related methods. We will see, over the course of this text, several abstract types
that may serve as Structures.
The interface, along with pre- and postconditions, makes many of the imple-
mentation-independent decisions about the semantics of associated structures.
182 Lists

When we develop specific implementations, we determine the implementation-

specific features of the structure, including its performance. When we compare
specific implementations, we compare their performance in terms of space and
time. Often, performance can be used to help us select among different imple-
mentations for a specific use.

9.1 Example: A Unique Program

As an example of how we might use lists, we write a program that writes out
the input with duplicate lines removed. The approach is to store each of the
unique lines in a structure (lines) as they are printed out. When new lines are
read in, they are compared against the existing list of unique, printed lines. If
the current line (current) is not in the list, it is added. If the current line is in
the list, it is ignored.

public static void main(String[] args)

{
Unique // input is read from System.in
Scanner s = new Scanner(System.in);
String current; // current line
// list of unique lines
List<String> lines = new SinglyLinkedList<String>();
// read a list of possibly duplicated lines
while (s.hasNextLine()) {
current = s.nextLine();
// check to see if we need to add it
if (!lines.contains(current)) {
System.out.println(current);
lines.add(current);
}
}
}

In this example we actually construct a particular type of list, a SinglyLinked-

List. The details of that implementation, discussed in the next section, are
not important to us because lines is declared to be a generic interface, a List.
Accessing data through the lines variable, we are only allowed to invoke meth-
ods found in the List interface. On the other hand, if we are able to cast our
algorithms in terms of Lists, any implementation of a List will support our
program.
When given input

madam
I'm
Adam!
...
Adam!
9.2 Example: Free Lists 183

I'm
Ada!
...
mad
am I...
madam

the program generates the following output:

madam
I'm
Adam!
...
Ada!
mad
am I...

Because there is no practical limit (other than the amount of memory available)
on the length of a list, there is no practical limit on the size of the input that
can be fed to the program. The list interface does not provide any hint of how
the list is actually implemented, so it is difficult to estimate the performance of
the program. It is likely, however, that the contains method—which is likely
to have to consider every existing element of the list—and the add method—
which might have to pass over every element to find its correct position—will
govern the complexity of the management of this List. As we consider imple-
mentations of Lists, we should keep the performance of programs like Unique
in mind.

9.2 Example: Free Lists

In situations where a pool of resources is to be managed, it is often convenient
to allocate a large number and keep track of those that have not been allocated.
This technique is often used to allocate chunks of physical memory that might
eventually be allocated to individual applications or printers from a pool that
might be used to service a particular type of printing request.
The following application maintains rental contracts for a small parking lot.
We maintain each parking space using a simple class, Space:

class Space
{ // structure describing parking space
public final static int COMPACT = 0; // small space ParkingLot
public final static int MINIVAN = 1; // medium space
public final static int TRUCK = 2; // large space
protected int number; // address in parking lot
protected int size; // size of space
public Space(int n, int s)
// post: construct parking space #n, size s
{
184 Lists

number = n;
size = s;
}
public boolean equals(Object other)
// pre: other is not null
// post: true iff spaces are equivalent size
{
Space that = (Space)other;
return this.size == that.size;
}
}

The lot consists of 10 spaces of various sizes: one large, six medium, and three
small. Renters may rent a space if one of appropriate size can be found on
the free list. The equals method of the Space class determines an appropriate
match. The rented list maintains Associations between names and space de-
scriptions. The following code initializes the free list so that it contains all the
parking spaces, while the rented list is initially empty:

List<Space> free = new SinglyLinkedList<Space>(); // available

List<Association<String,Space>> rented =
new SinglyLinkedList<Association<String,Space>>(); // rented spaces
for (int number = 0; number < 10; number++)
{
if (number < 3) // three small spaces
free.add(new Space(number,Space.COMPACT));
else if (number < 9) // six medium spaces
free.add(new Space(number,Space.MINIVAN));
else // one large space
free.add(new Space(number,Space.TRUCK));
}

The main loop of our program reads in commands from the keyboard—either
rent or return:
Scanner s = new Scanner(System.in);
while (s.hasNext())
{
String command = s.next(); // rent/return
...
}
System.out.println(free.size()+" slots remain available.");

Within the loop, when the rent command is entered, it is followed by the size
of the space needed and the name of the renter. This information is used to
construct a contract:

Space location;
if (command.equals("rent"))
{ // attempt to rent a parking space
9.2 Example: Free Lists 185

String size = s.next();

Space request;
if (size.equals("small"))
request = new Space(0,Space.COMPACT);
else if (size.equals("medium"))
request = new Space(0,Space.MINIVAN);
else request = new Space(0,Space.TRUCK);
// check free list for appropriate-sized space
if (free.contains(request))
{ // a space is available
location = free.remove(request);
String renter = s.next(); // to whom?
// link renter with space description
rented.add(new Association<String,Space>(renter,location));
System.out.println("Space "+location.number+" rented.");
} else {
System.out.println("No space available. Sorry.");
}
}

Notice that when the contains method is called on a List, a dummy element is
constructed to specify the type of object sought. When the dummy item is used
in the remove command, the actual item removed is returned. This allows us to
maintain a single copy of the object that describes a single parking space.
When the spaces are returned, they are returned by name. The contract is
looked up and the associated space is returned to the free list:

Space location;
if (command.equals("return")){
String renter = s.next(); // from whom?
// template for finding "rental contract"
Association<String,Space> query = new Association<String,Space>(renter);
if (rented.contains(query))
{ // contract found
Association<String,Space> contract =
rented.remove(query);
location = contract.getValue(); // where?
free.add(location); // put in free list
System.out.println("Space "+location.number+" is now free.");
} else {
System.out.println("No space rented to "+renter);
}
}

Here is a run of the program:

rent small Alice

Space 0 rented.
rent large Bob
Space 9 rented.
186 Lists

rent small Carol

Space 1 rented.
return Alice
Space 0 is now free.
return David
No space rented to David
rent small David
Space 2 rented.
rent small Eva
Space 0 rented.
quit
6 slots remain available.

Notice that when Alice’s space is returned, it is not immediately reused because
the free list contains other small, free spaces. The use of addLast instead of
addFirst (or the equivalent method, add) would change the reallocation policy
of the parking lot.
We now consider an abstract base class implementation of the List inter-
face.

9.3 Partial Implementation: Abstract Lists

Although we don’t have in mind any particular implementation, there are some
pieces of code that may be written, given the little experience we already have
with the use of Lists.
For example, we realize that it is useful to have a number of synonym meth-
ods for common operations that we perform on Lists. We have seen, for ex-
ample, that the add method is another way of indicating we want to add a new
value to one end of the List. Similarly, the parameterless remove method per-
forms a removeLast. In turn removeLast is simply a shorthand for removing
the value found at location size()-1.
public abstract class AbstractList<E>
extends AbstractStructure<E> implements List<E>
{
AbstractList public AbstractList()
// post: does nothing
{
}

public boolean isEmpty()

// post: returns true iff list has no elements
{
return size() == 0;
}

public void addFirst(E value)

// post: value is added to beginning of list
9.3 Partial Implementation: Abstract Lists 187

{
add(0,value);
}

public void addLast(E value)

// post: value is added to end of list
{
add(size(),value);
}

public E getFirst()
// pre: list is not empty
// post: returns first value in list
{
return get(0);
}

public E getLast()
// pre: list is not empty
// post: returns last value in list
{
return get(size()-1);
}

public E removeFirst()
// pre: list is not empty
// post: removes first value from list
{
return remove(0);
}

public E removeLast()
// pre: list is not empty
// post: removes last value from list
{
return remove(size()-1);
}

public void add(E value)

// post: value is added to tail of list
{
addLast(value);
}

public E remove()
// pre: list has at least one element
// post: removes last value found in list
{
return removeLast();
}
188 Lists

public E get()
// pre: list has at least one element
// post: returns last value found in list
{
return getLast();
}

public boolean contains(E value)

// pre: value is not null
// post: returns true iff list contains an object equal to value
{
return -1 != indexOf(value);
}
}
Position-independent operations, like contains, can be written in an implemen-
tation-independent manner. To see if a value is contained in a List we could
simply determine its index with the indexOf method. If the value returned
is −1, it was not in the list, otherwise the list contains the value. This approach
to the implementation does not reduce the cost of performing the contains
operation, but it does reduce the cost of implementing the contains operation:
once the indexOf method is written, the contains method will be complete.
When we expect that there will be multiple implementations of a class, sup-
porting the implementations in the abstract base class can be cost effective. If
improvements can be made on the generic code, each implementation has the
option of providing an alternative version of the method.
Notice that we provide a parameterless constructor for AbstractList ob-
jects. Since the class is declared abstract, the constructor does not seem nec-
essary. If, however, we write an implementation that extends the AbstractList
class, the constructors for the implementation implicitly call the parameterless
constructor for the AbstractList class. That constructor would be responsible
for initializing any data associated with the AbstractList portion of the imple-
mentation. In the examples of the last chapter, we saw the AbstractGenerator
initialized the current variable. Even if there is no class-specific data—as is
true with the AbstractList class—it is good to get in the habit of writing these
simple constructors.
We now consider a number of implementations of the List type. Each of
these implementations is an extension of the AbstractList class. Some inherit
the methods provided, while others override the selected method definitions to
provide more efficient implementation.

9.4 Implementation: Singly Linked Lists

Dynamic memory is allocated using the new operator. Java programmers are
accustomed to using the new operator whenever classes or arrays are to be allo-
cated. The value returned from the new operator is a reference to the new object.
9.4 Implementation: Singly Linked Lists 189

A B

Figure 9.1 Pictures of a null reference (left) and a non-null reference to an instance
of a class (right).

Thus, whenever we declare an instance of a class, we are actually declaring a

reference to one of those objects. Assignment of references provides multiple
variables with access to a single, shared instance of an object.
An instance of a class is like a helium-filled balloon. The balloon is the object
being allocated. The string on the balloon is a convenient handle that we can
use to hold onto with a hand. Anything that holds onto the string is a reference.
Assignment of references is similar to asking another hand to “hold the balloon
I’m holding.” To not reference anything (to let go of the balloon) we can assign
the reference the value null. If nothing references the balloon, then it floats
away and we can no longer get access to the instance. When memory is not
referenced in any way, it is recycled automatically by a garbage collector.
N

NW

NE
Principle 10 When manipulating references, draw pictures.

E
SW

SE
S

In this text, we will draw references as arrows pointing to their respective ob-
jects (Figure 9.1). When a reference is not referencing anything, we draw it as
a dot. Since references can only be in one of two states—pointing to nothing or
pointing to an object—these are the only pictures we will ever draw.
One approach to keeping track of arbitrarily large collections of objects is to
use a singly linked list to dynamically allocate each chunk of memory “on the
fly.” As the chunks of memory are allocated, they are linked together to form First garbage,
the entire structure. This is accomplished by packaging with each user object a now flies!
reference to the next object in the chain. Thus, a list of 10 items contains 10
elements, each of which contains a value as well as another element reference.
Each element references the next, and the final element does not reference
anything: it is assigned null (see Figure 9.2). Here, an implementation of a
Node contains an additional reference, nextElement:

public class Node<E>

{
protected E data; // value stored in this element
protected Node<E> nextElement; // ref to next Node
190 Lists

public Node(E v, Node<E> next)

// pre: v is a value, next is a reference to remainder of list
// post: an element is constructed as the new head of list
{
data = v;
nextElement = next;
}

public Node(E v)
// post: constructs a new tail of a list with value v
{
this(v,null);
}

public Node<E> next()

// post: returns reference to next value in list
{
return nextElement;
}

public void setNext(Node<E> next)

// post: sets reference to new next value
{
nextElement = next;
}

public E value()
// post: returns value associated with this element
{
return data;
}

public void setValue(E value)

// post: sets value associated with this element
{
data = value;
}
}

When a list element is constructed, the value provided is stored away in the ob-
ject. Here, nextElement is a reference to the next element in the list. We access
the nextElement and data fields through public methods to avoid accessing
protected fields. Notice that, for the first time, we see a self-referential data
structure: the Node object has a reference to a Node. This is a feature common
to structures whose size can increase dynamically. This class is declared public
so that anyone can construct Nodes.
We now construct a new class that implements the List interface by extend-
ing the AbstractList base class. For that relation to be complete, it is necessary
to provide a complete implementation of each of the methods promised by the
9.4 Implementation: Singly Linked Lists 191

count head

3 Life

on

Mars

Figure 9.2 A nonempty singly linked list.

count head

Figure 9.3 An empty singly linked list.

interface. Failure to implement any of the methods leaves the implementation

incomplete, leaving the class abstract.
Our approach will be to maintain, in head, a reference to the first element
of the list in a protected field (Figure 9.2). This initial element references the
second element, and so on. The final element has a null-valued next reference.
If there are no elements, head contains a null reference (Figure 9.3). We also
maintain an integer that keeps track of the number of elements in the list. First,
as with all classes, we need to specify protected data and a constructor:
protected int count; // list size
protected Node<E> head; // ref. to first element

public SinglyLinkedList() SinglyLinked-

// post: generates an empty list List
{
head = null;
count = 0;
}

This code sets the head reference to null and the count field to 0. Notice that,
by the end of the constructor, the list is in a consistent state. N
NW

NE
W

Principle 11 Every public method of an object should leave the object in a consis-
E
SW

SE

tent state. S
192 Lists

What constitutes a “consistent state” depends on the particular structure, but

in most cases the concept is reasonably clear. In the SinglyLinkedList, the
constructor constructs a list that is empty.
The size-oriented methods are simply written in terms of the count identi-
fier. The size method returns the number of elements in the list.
public int size()
// post: returns number of elements in list
{
return count;
}

Recall that the isEmpty method described in the AbstractList class simply
returns whether or not the size method would return 0. There’s a great advan-
tage to calling the size method to implement isEmpty: if we ever change the
implementation, we need only change the implementation of size.
Both of these methods could avoid referencing the count field, by travers-
ing each of the next references. In this alternative code we use the analogy
of a finger referencing each of the elements in the list. Every time the finger
references a new element, we increment a counter. The result is the number of
elements. This time-consuming process is equivalent to constructing the infor-
mation stored explicitly in the count field.
public int size()
// post: returns number of elements in list
{
// number of elements we've seen in list
int elementCount = 0;
// reference to potential first element
Node<E> finger = head;

while (finger != null) {

// finger references a new element, count it
elementCount++;
// reference possible next element
finger = finger.next();
}
return elementCount;
}

Note that isEmpty does not need to change.1 It is early verification that the
interface for size helps to hide the implementation.
The decision between the two implementations has little impact on the user
of the class, as long as both implementations meet the postconditions. Since
the user is insulated from the details of the implementation, the decision can
be made even after applications have been written. If, for example, an environ-
ment is memory-poor, it might be wise to avoid the use of the count field and

1 In either case, the method isEmpty could be written more efficiently, checking a null head
reference.
9.4 Implementation: Singly Linked Lists 193

4 Yes!
3 Life
Life
on
on
Mars
Mars

Figure 9.4 A singly linked list before and after the call to addFirst. Shaded value is
added to the list. The removeFirst method reverses this process and returns value.

instead traverse the list to determine the number of elements by counting them.
If, however, a machine is slow but memory-rich, then the first implementation
would be preferred. Bot