Competitive Programming 4 Book 1 4th Edition

Steven Halim install download

https://ebookmeta.com/product/competitive-
programming-4-book-1-4th-edition-steven-halim/

Download more ebook from https://ebookmeta.com

We believe these products will be a great fit for you. Click
the link to download now, or visit ebookmeta.com
to discover even more!

Competitive Programming 4 Book 1 Steven Halim

https://ebookmeta.com/product/competitive-
programming-4-book-1-steven-halim/

Competitive Programming 4 The Lower Bound of

Programming Contests in the 2020s 4th Edition Steven
Halim

https://ebookmeta.com/product/competitive-programming-4-the-
lower-bound-of-programming-contests-in-the-2020s-4th-edition-
steven-halim-2/

Competitive Programming 4 The Lower Bound of

Programming Contests in the 2020s 4th Edition Steven
Halim

https://ebookmeta.com/product/competitive-programming-4-the-
lower-bound-of-programming-contests-in-the-2020s-4th-edition-
steven-halim/

Love Other Inconveniences 1st Edition Catherine Cloud

https://ebookmeta.com/product/love-other-inconveniences-1st-
edition-catherine-cloud/
Collapsing Structures and Public Mismanagement 1st
Edition Wolfgang Seibel

https://ebookmeta.com/product/collapsing-structures-and-public-
mismanagement-1st-edition-wolfgang-seibel/

Ethos Logos and Perspective Studies in Late Byzantine

Rhetoric First Edition Florin Leonte

https://ebookmeta.com/product/ethos-logos-and-perspective-
studies-in-late-byzantine-rhetoric-first-edition-florin-leonte/

Advanced Deep Learning for Engineers and Scientists: A

Practical Approach (EAI/Springer Innovations in
Communication and Computing) Kolla Bhanu Prakash
(Editor)
https://ebookmeta.com/product/advanced-deep-learning-for-
engineers-and-scientists-a-practical-approach-eai-springer-
innovations-in-communication-and-computing-kolla-bhanu-prakash-
editor/

Ride Me A Curvy Girl Military MC Romance Men of Valor

MC 1st Edition Fern Fraser

https://ebookmeta.com/product/ride-me-a-curvy-girl-military-mc-
romance-men-of-valor-mc-1st-edition-fern-fraser-2/

Applied Mathematics Class XI 3rd Edition Neeraj Raj

Jain M L Aggarwal

https://ebookmeta.com/product/applied-mathematics-class-xi-3rd-
edition-neeraj-raj-jain-m-l-aggarwal/
CC Certified in Cybersecurity Study Guide Sybex Study
Guide 1st Edition Chapple

https://ebookmeta.com/product/cc-certified-in-cybersecurity-
study-guide-sybex-study-guide-1st-edition-chapple/
This is the 100% identical eBook (PDF) version of CP4 Book 1
that was released on 19 July 2020
Please read https://cpbook.net/errata
for the latest known updates to this PDF
 c Steven, Felix, Suhendry

ii
Contents

Forewords for CP4 vii

Testimonials of CP1/2/3 xiii

Preface for CP4 xv

Authors’ Profiles xxvii

Abbreviations xxix

1 Introduction 1
1.1 Competitive Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 The Competitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 International Olympiad in Informatics (IOI) . . . . . . . . . . . . . . 3
1.2.2 International Collegiate Programming Contests (ICPC) . . . . . . . . 4
1.2.3 Other Programming Contests . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Tips to be Competitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Tip 1: Type Code Faster! . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Tip 2: Quickly Identify Problem Types . . . . . . . . . . . . . . . . . 8
1.3.3 Tip 3: Do Algorithm Analysis . . . . . . . . . . . . . . . . . . . . . . 10
1.3.4 Tip 4: Master Programming Languages . . . . . . . . . . . . . . . . . 15
1.3.5 Tip 5: Master the Art of Testing Code . . . . . . . . . . . . . . . . . 18
1.3.6 Tip 6: Practice and More Practice . . . . . . . . . . . . . . . . . . . 21
1.3.7 Tip 7: Team Work (for ICPC) . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Getting Started: The Easy Problems . . . . . . . . . . . . . . . . . . . . . . 23
1.4.1 Anatomy of a Programming Contest Problem . . . . . . . . . . . . . 23
1.4.2 Typical Input/Output Routines . . . . . . . . . . . . . . . . . . . . . 23
1.4.3 Time to Start the Journey . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.4 Getting Our First Accepted (AC) Verdict . . . . . . . . . . . . . . . 27
1.5 Basic String Processing Skills . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.6 The Ad Hoc Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7 Solutions to Non-Starred Exercises . . . . . . . . . . . . . . . . . . . . . . . 41
1.8 Chapter Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2 Data Structures and Libraries 53

2.1 Overview and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.2 Linear DS with Built-in Libraries . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2.1 Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.2.2 Special Sorting Problems . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.2.3 Bitmask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.2.4 Big Integer (Python & Java) . . . . . . . . . . . . . . . . . . . . . . . 66

iii
CONTENTS c Steven, Felix, Suhendry

2.2.5 Linked Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . 69

2.2.6 Special Stack-based Problems . . . . . . . . . . . . . . . . . . . . . . 71
2.3 Non-Linear DS with Built-in Libraries . . . . . . . . . . . . . . . . . . . . . 78
2.3.1 Binary Heap (Priority Queue) . . . . . . . . . . . . . . . . . . . . . . 78
2.3.2 Hash Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.3.3 Balanced Binary Search Tree (bBST) . . . . . . . . . . . . . . . . . . 84
2.3.4 Order Statistics Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
2.4 DS with Our Own Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2.4.1 Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
2.4.2 Union-Find Disjoint Sets . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.4.3 Fenwick (Binary Indexed) Tree . . . . . . . . . . . . . . . . . . . . . 104
2.4.4 Segment Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
2.5 Solution to Non-Starred Exercises . . . . . . . . . . . . . . . . . . . . . . . . 124
2.6 Chapter Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

3 Problem Solving Paradigms 129

3.1 Overview and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3.2 Complete Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3.2.1 Iterative Complete Search . . . . . . . . . . . . . . . . . . . . . . . . 131
3.2.2 Recursive Complete Search . . . . . . . . . . . . . . . . . . . . . . . . 135
3.2.3 Complete Search Tips . . . . . . . . . . . . . . . . . . . . . . . . . . 139
3.2.4 Complete Search in Programming Contests . . . . . . . . . . . . . . . 143
3.3 Divide and Conquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
3.3.1 Interesting Usages of Binary Search . . . . . . . . . . . . . . . . . . . 148
3.3.2 Ternary Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
3.3.3 Divide and Conquer in Programming Contests . . . . . . . . . . . . . 153
3.4 Greedy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
3.4.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
3.4.2 Greedy Algorithm in Programming Contests . . . . . . . . . . . . . . 161
3.5 Dynamic Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
3.5.1 DP Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
3.5.2 Classical Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
3.5.3 Non-Classical Examples . . . . . . . . . . . . . . . . . . . . . . . . . 184
3.5.4 Dynamic Programming in Programming Contests . . . . . . . . . . . 187
3.6 Solution to Non-Starred Exercises . . . . . . . . . . . . . . . . . . . . . . . . 190
3.7 Chapter Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

4 Graph 193
4.1 Overview and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
4.2 Graph Traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
4.2.1 Overview and Motivation . . . . . . . . . . . . . . . . . . . . . . . . 195
4.2.2 Depth First Search (DFS) . . . . . . . . . . . . . . . . . . . . . . . . 195
4.2.3 Breadth First Search (BFS) . . . . . . . . . . . . . . . . . . . . . . . 197
4.2.4 Finding Connected Components (Undirected Graph) . . . . . . . . . 198
4.2.5 Flood Fill (Implicit 2D Grid Graph) . . . . . . . . . . . . . . . . . . 199
4.2.6 Topological Sort (Directed Acyclic Graph) . . . . . . . . . . . . . . . 200
4.2.7 Bipartite Graph Check (Undirected Graph) . . . . . . . . . . . . . . 202
4.2.8 Cycle Check (Directed Graph) . . . . . . . . . . . . . . . . . . . . . . 203
4.2.9 Finding Articulation Points and Bridges (Undirected Graph) . . . . . 205
4.2.10 Finding Strongly Connected Components (Directed Graph) . . . . . . 208

iv
CONTENTS c Steven, Felix, Suhendry

4.2.11 Graph Traversal in Programming Contests . . . . . . . . . . . . . . . 211

4.3 Minimum Spanning Tree (MST) . . . . . . . . . . . . . . . . . . . . . . . . . 215
4.3.1 Overview and Motivation . . . . . . . . . . . . . . . . . . . . . . . . 215
4.3.2 Kruskal’s Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
4.3.3 Prim’s Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
4.3.4 Other Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
4.3.5 MST in Programming Contests . . . . . . . . . . . . . . . . . . . . . 221
4.4 Single-Source Shortest Paths (SSSP) . . . . . . . . . . . . . . . . . . . . . . 223
4.4.1 Overview and Motivation . . . . . . . . . . . . . . . . . . . . . . . . 223
4.4.2 On Unweighted Graph: BFS . . . . . . . . . . . . . . . . . . . . . . . 223
4.4.3 On Weighted Graph: Dijkstra’s . . . . . . . . . . . . . . . . . . . . . 227
4.4.4 On Small Graph (with Negative Cycle): Bellman-Ford . . . . . . . . 234
4.4.5 SSSP in Programming Contests . . . . . . . . . . . . . . . . . . . . . 237
4.5 All-Pairs Shortest Paths (APSP) . . . . . . . . . . . . . . . . . . . . . . . . 241
4.5.1 Overview and Motivation . . . . . . . . . . . . . . . . . . . . . . . . 241
4.5.2 Floyd-Warshall Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 242
4.5.3 Other Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
4.5.4 APSP in Programming Contests . . . . . . . . . . . . . . . . . . . . . 246
4.6 Special Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
4.6.1 Directed Acyclic Graph . . . . . . . . . . . . . . . . . . . . . . . . . . 249
4.6.2 Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
4.6.3 Bipartite Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
4.6.4 Eulerian Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
4.6.5 Special Graphs in Programming Contests . . . . . . . . . . . . . . . . 263
4.7 Solution to Non-Starred Exercises . . . . . . . . . . . . . . . . . . . . . . . . 267
4.8 Chapter Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Bibliography 276

v
CONTENTS c Steven, Felix, Suhendry

vi
Forewords for CP4

Bill Poucher
Introduction
In 1970, the Texas A&M UPE Honor Society hosted the first university competitive pro-
gramming competition in the history of the ICPC. The first Finals was held in 1977 in
Atlanta in conjunction with the Winter Meeting of the ACM Computer Science Conference.
The ICPC International Collegiate Programming Contest hosted regional competitions at
643 sites in 104 countries for 59 000 team members and their 5043 coaches from over 3400
universities that span the globe. The top 135 teams of three will advance to the ICPC World
Finals in Moscow hosted by MIPT scheduled for June 2021.
ICPC alumni number over 400,000 worldwide, many playing key roles in building the
global digital community for many decades. The ICPC is the root of competitive program-
ming that reaches out through the global digital community to persons from all cultures and
in increasingly-younger generations.
The UVa Online Judge opened the doors for online competition and access to ICPC prob-
lems under the direction of Professor Miguel Ángel Revilla. Three of the star-studded team
are Steven Halim, Felix Halim, and Suhendry E↵endy, authors of Competitive Programming
4, Book 1 and Book 2. Their work will be honored at the ICPC World Finals in Moscow
hosted by MIPT with a special award from the ICPC Foundation.

Competitive Programming
What is competitive programming and why should you get involved? First and foremost, it’s
a mind sport. It more fully develops your algorithmic reasoning skills and bridges the gap
between theory and application in bite-sized chunks. Full participation develops problem-
solving intuition and competence. Get ready for the Digital Renaissance that will shape
your world in the coming decades. To understand the landscape, it is important to shape
your mind beyond a swarm of buzzwords. Do it as a team sport.

How do we get started?

Start with Competitive Programming 4, Book 1 and Book 2. Start with Book 1 first :). The
authors are seasoned competitive programming experts who have dedicated decades of work
to help at all levels of the sport.
In parallel, engage in a culture that develops habits excellence. You are the first genera-
tion that has never been disconnected. Being connected is best when we bind our strengths
together in common cause. Do that and prepare to meet the challenges that will define your
generation.
Life needs you. We are born to compete. We compete best when we compete together, in
good faith, in goodwill, and with good deeds. When you come to college, consider the ICPC

vii
FOREWORDS Bill Poucher

and the new program ICPC University Commons that will provide a spectrum of activities
that happen outside of the classroom. You can visit https://icpc.global for details.

Why get started?

Is developing your problem-solving skills important? Yes. Is preparing for a future engaged
in the global digital community important? Yes. Is following T.S. Elliot’s advice that to
fully develop you must go too far? Yes. Do that in competitive programming. Be careful of
pursuits that are not reversible.
Is competitive programming practical? Aristotle asserted that there is nothing more
practical than engaging in mental activities and reflections which have their goal in them-
selves and take pace for their own sake. Let me recommend that you engage your spirit in
building a more beautiful world. In the immense scope of life, abundant small kindnesses
make a di↵erence. Find friends with common interest and embrace this cycle:

Repeat for a lifetime: Study; Practice; Rehearse; Dress Rehearse; Perform.

It works for athletes.

It works for musicians.
It works for all performance arts.
It will work for you.

Best, Bill
Dr. William B. “Bill” Poucher, Ph.D., ACM Fellow
Professor of Computer Science, Baylor University
Executive Director, ICPC International Collegiate Programming Contest
President, ICPC Foundation
July 13th, 2020.

viii
FOREWORDS Miguel Revilla Rodrı́guez

Miguel Revilla Rodrı́guez

Almost 20 years ago (on November 11th , 2003, to be precise), my father (Miguel Ángel
Revilla) received an e-mail with the following message:

“I should say in a simple word that with the UVa Site, you have given birth to
a new CIVILIZATION and with the books you write (he meant “Programming
Challenges: The Programming Contest Training Manual” [53], coauthored with
Steven Skiena), you inspire the soldiers to carry on marching. May you live long
to serve the humanity by producing super-human programmers.”

What, in my father’s words, was “clearly an exaggeration”, caused some thinking. And it’s
not a secret that thoughts can easily lead to dreams. His dream was to create a community
around the project he had started, as part of is teaching job at the University of Valladolid,
Spain, that gathered people from all around the world working together towards the same
ideal, the same quest. With a little searching, on the primitive Internet of the first years of
our century, a whole online community of excellent users and tools, built around the UVa
site, came to light.
The website Methods to Solve 1 , created by a very young student from Indonesia, was one
of the most impressive among them. There was the result of the hard work of a real genius
of algorithms and computer science. The seed was planted to believe that the dream could
come true. Moreover, it was not only that the leaves of that growing tree were a perfect
match, but the root of both projects were exactly the same: to serve the humanity. That
young student, the author of the e-mail and the website that put my father to dream, was
Steven Halim. Later he would discover that Steven was not alone in his quest, as his younger
brother, Felix, shared his view, his interests, and his extraordinary capabilities.
After 15 years of fruitful collaboration and, more important, friendship with Steven and
Felix, my father sadly passed away in 2018. His work, and his dreams, now belong to us,
the next generation. This book is the living proof that the dream has become true.
“I can’t imagine a better complement for the UVa Online Judge”, are my father’s words.
Now, with this fourth version of Competitive Programming in my hands, I can add that I
can’t imagine the very existence of the Online Judge without this book. Both projects have
grown in parallel and are, no doubt, perfect complements and companions to each other.
By practicing and mastering most programming exercises in this book, the reader can learn
how to solve hundreds of tasks and find a place in the top 500 best Online Judge coders.
You have in your hands over 2000 (yes, two thousand!) selected, classified, and carefully
commented problems from the Online Judge.
The authors, in the past two decades, have grown from contestants, to coaches and,
finally, masters in the art of competitive programming. They perfectly know every curve
and crossroad in that long path, and they can put themselves in the skins of the young
IOI contestant, the ICPC newcomer or the seasoned coach, speaking to each in their own
language. This book is, for that very reason, the perfect reading for all of them. No matter
if you are starting as a competitive programmer in your local IOI, or are coaching in the
next ICPC World Finals, no doubt this IS the book for you.

1
Please visit https://cpbook.net/methodstosolve

ix
FOREWORDS Miguel Revilla Rodrı́guez

I love movies, I adore classic movies, and I know that what I’m watching is a masterpiece,
when, after the film ends, I can’t wait to start all over again. In Steven and Felix own words
“the book is not meant to be read once, but several times”. And you will find that same
feeling, not only because the authors recommend it, but because you will be anxious to read
and re-read it as, like in the greatest movies, you will find something new and amazing each
time. This book is, by that logic, a masterpiece.
I also have the great honor of being the Spanish language translator of this book. Trans-
lating requires a very meticulous process of converting the words while keeping the spirit.
You have to think as the author would think, and have to perfectly understand not only
what the author is saying, but also what the author is meaning. It is a handcrafting exer-
cise. Having gone forth and back through this text hundreds of times, I have enjoyed every
concept, every new idea, and every tip, not only by what is written in it, but also by what
it wants to achieve. The quest of making better programmers and, behind that, the quest
of serving humanity. This book is, indeed, a truly masterpiece.
Once you’ve read this book several times, you will realize how much a better programmer
you are but, believe it or not, you will realize that you are also a happier person.
Miguel Revilla Rodrı́guez (Miguel Jr)
Online Judge Manager
https://onlinejudge.org
July 1st, 2020, Valladolid.

x
FOREWORDS Fredrik Niemelä

Fredrik Niemelä
I got my first physical copy of this book from Steven at IOI 2012 in Italy. Like so many other
computer scientists, he has a great sense of humor, and named it “Competitive Programming:
Increasing the Lower Bound of Programming Contests.” It was the second edition of the
book and already twice the size of the first edition. Packed with practical advice, it was well-
suited to get beginners started and had useful material for the more seasoned algorithmist.
Steven and Felix’s vision for their book was to teach everybody how to program (As
Gusteau from Ratatouille would put it: “Tout le monde peut programmer”). I had a similar
vision, but instead of writing a book, we created Kattis. “Competitive Programming” and
Kattis share this motivating principle: to make learning computer science and programming
accessible for everyone. In that sense, they are like two of many pieces in the same puzzle.
Kattis is an online tool for teaching computer science and programming, which relies on
a curated library of programming tasks. I managed to convince Steven that he should try
using Kattis for some of his teaching activities. Over the years he has moved from using
Kattis, to pushing us to improve Kattis, to adding high-quality content to Kattis.
From years of teaching algorithms and using similar systems that preceded Kattis, we
learned that the quality of the problems, and their absolute correctness, are paramount for
learning outcomes. So, this is where we put extra e↵ort into Kattis. (If you ever felt that
it’s too much work to add problems to Kattis, this is why). What we did back then is now
standard practice—both the ICPC and IOI use the same kinds of methods for their finals.
In this fourth edition (more than twice as large as the second edition!), Steven and Felix,
now joined by co-author Suhendry, are using problems from Kattis. We are honored to be
included. Finally, our puzzle pieces are directly connected, and I am very excited about
that.
I hope you will find this book informative and helpful and that you will spend the time
it asks of you. You will not be disappointed.
Fredrik Niemelä
Founder of Kattis
ICPC Contest System Director
IOI Technical Committee Founding Member
https://www.kattis.com
July 11th, 2020.

xi
FOREWORDS Brian Christopher Dean

Brian Christopher Dean

I’ve had the privilege to be part of the competitive programming world for more than three
decades, during which time I’ve seen the field grow substantially in terms of its impact
on modern computing. As director of the USA Computing Olympiad and coach of my
University’s ICPC teams, I have seen firsthand how competitive programming has become a
key part of the global computing talent pipeline - both academia and industry are now filled
with present-day superstars who were formerly superstars in competitive programming.
Just as the world of competitive programming has shown tremendous growth in scope,
depth, and relevance, so too has this text, now in its fourth edition. Earlier editions of
this book provided what I consider to be the gold standard for both an introduction and a
thorough reference to the algorithmic concepts most prevalent in competitive programming.
The same remains true for this edition.
Competitive programming can be a daunting undertaking for the novice student - learn-
ing to code is plenty challenging by itself, and on top of this we add a layer of ”standard”
algorithms and data structures and then another layer of problem-solving insight and tricks.
This text helps the introductory student navigate these challenges in several ways, by its
thoughtful organization, extensive practice exercises, and by articulating ideas both in clear
prose and code. Competitive programming can also be a daunting prospect for the advanced
student due to its rapid pace of evolution - techniques can go from cutting-edge to common-
place in a matter of just a few years, and one must demonstrate not only proficiency but
true mastery of a formidable and ever-expanding body of algorithmic knowledge. With its
comprehensive algorithmic coverage and its extensive listing of ⇡ 3458 categorized problems,
this text provides the advanced student with years of structured practice that will lead to a
high baseline skill level.
I think this is a book that belongs in the library of anyone serious about computing, not
just those training for their first or their hundredth programming competition. Ideas from
competitive programming can help one develop valuable skills and insight - both in theory
and implementation - that can be brought to bear on a wide range of modern computing
problems of great importance in practice. Algorithmic problem solving is, after all, truly
the heart and soul of computer science! These types of problems are often used in job
interviews for a good reason, since they indicate the type of prospective employee who has
a skill set that is broadly applicable and that can adapt gracefully to changes in underlying
technologies and standards. Studying the concepts in this text is an excellent way to sharpen
your skills at problem solving and coding, irrespective of whether you intend to use them in
competition or in your other computational pursuits.
I’ve thoroughly enjoyed reading successive drafts
of this updated work shared with me by the au-
thors at recent IOIs, and I commend the authors on
the impressive degree to which they have been able
extend the scope, clarity, and depth of an already-
remarkable text.
Brian Christopher Dean
Professor and Chair
Division of Computer Science, School of Computing
Clemson University, Clemson, SC, USA
Director, USA Computing Olympiad
July 5th, 2020
http://www.usaco.org/

xii
Testimonials of CP1/2/3

“Competitive Programming 3 has contributed immensely to my understanding of data

structures & algorithms. Steven & Felix have created an incredible book that thoroughly
covers every aspect of competitive programming, and have included plenty of practice
problems to make sure each topic sinks in. Practicing with CP3 has helped me nail job
interviews at Google, and I can’t thank Steven & Felix enough!”
— Troy Purvis, Software Engineer @ Google.
“Steven and Felix are passionate about competitive programming. Just as importantly,
they are passionate about helping students become better programmers. CP3 is the result:
a dauntless dive into the data structures, algorithms, tips, and secrets used by competitive
programmers around the world. Yet, when the dust settles on the book, the strongest
sillage is likely to be one of confidence—that, yes, this stu↵ is challenging, but that you can
do it.” — Dr. Daniel Zingaro, Associate Professor Teaching Stream,
University of Toronto Mississauga.
“CP-Book helped us to train many generations of ICPC and IOI participants for Bolivia.
It’s the best source to start and reach a good level to be a competitive programmer.” —
Jhonatan Castro, ICPC coach and Bolivia IOI Team coach,
Universidad Mayor de San Andrés, La Paz, Bolivia.
“Reading CP3 has been a major contributor to my growth, not just as a competitive
programmer, but also as a computer scientist. My entire approach to problem solving has
been improved by doing the exercises in the book; my passion for the art of problem
solving, especially in contest environments, has been intensified. I now mentor several
students using this book as a guide. It is an invaluable resource to anyone who wants to be
a better problem solver.” — Ryan Austin Fernandez, Assistant Professor,
De La Salle University, Manila, Philippines.
“I rediscovered CP3 book on 2017-2019 when I come back to Peru after my master in
Brazil, I enjoyed, learned and solved many problems, more than during my undergraduate,
coaching and learning together in small group of new students that are interesting in
competitive programming. It kept me in a constantly competition with them, at the end
they have solved more problems than me.” — Luciano Arnaldo Romero Calla,
PhD Student, University of Zurich.
“CP1 helped my preparation during national team training and selection for participating
the IOI. When I took the competitive programming course in NUS, CP2 book is
extensively used for practice and homework. The good balance between the programming
and theoretic exercises for deeper understanding in the book makes CP book a great book
to be used for course references, as well as for individual learning. Even at the top
competitive programming level, experts can still learn topics they have not learnt before
thanks to the rare miscellaneous topics at the end of the book.”
— Jonathan Irvin Gunawan, Software Engineer, Google.

xiii
TESTIMONIALS Various Book Readers

“Dr. Steven Halim is one of the best professors I have had in NUS. His intuitive
visualizations and clear explanations of highly complex algorithms make it significantly
easier for us to grasp difficult concepts. Even though I was never fully into Competitive
Programming, his book and his teaching were vital in helping me in job interviews and
making me a better coder. Highly recommend CP4 to anyone looking to impress in
software engineering job interviews.” — Patrick Cho, Machine Learning Scientist, Tesla.

“Flunked really hard at IOI 2017, missing medal cuto↵ by 1 place. Then at the beginning
of 2018 Steven Halim gave me a draft copy of CP3.1 / CP4 and I ended up getting a gold
medal!” — Joey Yu, Student, University of Waterloo, SWE Intern at Rippling,
IOI 2018 Gold Medalist.

“As a novice self-learner, CP-book helped me to learn the topics in both fun and
challenging ways. As an avid and experienced CP-er, CP-book helped me to find a
plentiful and diverse problems. As a trainer, CP-book helped me to plan ahead the
materials and tactical strategies or tricks in competition for the students. As the person
ever in those three di↵erent levels, I must e↵ortlessly say CP-book is a must-have to being
a CP master!” — Ammar Fathin Sabili, PhD Student, National University of Singapore.

“I’ve been in CP for three years. A rookie number for all the competitive programmers out
there. I have a friend (still chatting with him today) who introduced me to this book. He’s
my roommate on our National Training Camp for IOI 2018’s selection. I finally get a grab
of this book in early 2019. To be honest I’m not the ‘Adhoc’ and good at ‘Math’ type of
CP-er. I love data structures, graph (especially trees) And this CP3 book. Is a leap of
knowledge. No joke. I met Dr Felix when I was training in BINUS, I also met Dr Steven
when I competed in Singapore’s NOI and one of my unforgettable moment is, this legend
book got signed by its two authors. Even tho the book is full of marks and stains, truly
one of my favorite. Kudos for taking me to this point of my life.”
— Hocky Yudhiono, Student, University of Indonesia.

“I bought CP3 on 7th April 2014 on my birthday as a gift for myself and it has been the
most worth-it 30USD spent by me on any educational material. In the later years, I was
able to compete in IOI and ICPC WF. I think CP3 played a very big factor in igniting the
interest and providing a strong technical foundation about all the essential topics required
in CP.” — Sidhant Bansal, Student, National University of Singapore.

“I have always wanted to get involved in competitive programming, but I didn’t know how
and where to get started. I was introduced to this book while taking Steven’s companion
course (CS3233) in NUS as an exchange student, and I found the book to be really helpful
in helping me to learn competitive programming. It comes with a set of Kattis exercises as
well. This book provides a structured content for competitive programming, and can be
really useful to anyone ranging from beginners to experts. Just like CLRS for algorithms,
CP is THE book for competitive programming.” — Jay Ching Lim,
Student, University of Waterloo.

“My memories about CP3 is me reading it in many places, the bus, my room, the library,
the contest floor...not much time had passed since I start in competitive programming
reading CP3 until I got qualified to an ICPC World Final.”
— Javier Eduardo Ojeda Jorge, ICPC World Finalist, Universidad Mayor de San Simón,
Software Engineer at dParadig, Chile

xiv
Preface for CP4

This Competitive Programming book, 4th edition (CP4) is a must have for every compet-
itive programmer. Mastering the contents of this book is a necessary (but admittedly not
sufficient) condition if one wishes to take a leap forward from being just another ordinary
coder to being among one of the world’s finest competitive programmers.
Typical readers of Book 1 (only) of CP4 would include:

1. Secondary or High School Students who are competing in the annual International
Olympiad in Informatics (IOI) [31] (including the National or Provincial Olympiads)
as Book 1 covers most of the current IOI Syllabus [16],
2. Casual University students who are using this book as supplementary material for
typical Data Structures and Algorithms courses,
3. Anyone who wants to prepare for typical fundamental data structure/algorithm part
of a job interview at top IT companies.

Typical readers of both Book 1 + Book 2 of CP4 would include:

1. University students who are competing in the annual International Collegiate Program-
ming Contest (ICPC) [57] Regional Contests (including the World Finals) as Book 2
covers much more Computer Science topics that have appeared in the ICPCs,
2. Teachers or Coaches who are looking for comprehensive training materials [21],
3. Anyone who loves solving problems through computer programs. There are numerous
programming contests for those who are no longer eligible for ICPC, including Google
CodeJam, Facebook Hacker Cup, TopCoder Open, CodeForces contest, Internet Prob-
lem Solving Contest (IPSC), etc.

Prerequisites
This book is not written for novice programmers so that we can write much more about
Competitive Programming instead of repeating the basic programming methodology con-
cepts that are widely available in other Computer Science textbooks. This book is aimed
at readers who have at least basic knowledge in programming methodology, are familiar
with at least one of these programming languages (C/C++, Java, Python, or OCaml) but
preferably more than one programming language, have passed (or currently taking) a basic
data structures and algorithms course and a discrete mathematics course (both are typically
taught in year one of Computer Science university curricula or in the NOI/IOI training
camps), and understand simple algorithmic analysis (at least the big-O notation). In the
next subsections, we will address the di↵erent potential readers of this book.

xv
PREFACE c Steven, Felix, Suhendry

To (Aspiring) IOI Contestants

IOI is not a speed contest and for now, currently excludes the topics listed in the following
Table 1 (many are in Book 2). You can skip these topics until your University years (when
you join that university’s ICPC teams). However, learning these techniques in advance
is definitely beneficial as some tasks in IOI can become easier with additional knowledge.
Therefore, we recommend that you grab a copy of this book early in your competitive
programming journey (i.e., during your high school days).
We are aware that one cannot win a medal in IOI just by mastering the contents of the
current version (CP4) of this book. While we believe that many parts of the latest IOI
syllabus [16] has been included in this book (especially Book 1)—hopefully enabling you to
achieve a respectable score in future IOIs—we are well aware that modern IOI tasks require
keen problem solving skills and tremendous creativity [20]—virtues that we cannot possibly
impart through a static textbook. This book can provide knowledge, but the hard work must
ultimately be done by you. With practice comes experience, and with experience comes skill.
So, keep on practicing!

Topics in Book 2
Math: Big Integer, Modular Inverse, Probability Theory, Game Theory
String Processing: Suffix Trees/Arrays, KMP, String Hashing/Rabin-Karp
(Computational) Geometry: Various Geometry-specific library routines
Graph: Network Flow, Harder Matching problems, Rare NP-hard/complete Problems
More than half of the Rare Topics

Table 1: Not in IOI Syllabus [16] Yet

To Students of Data Structures and Algorithms Courses

The contents of this book have been expanded in CP4 so that the first four chapters of this
book are more accessible to first year Computer Science students. Topics and exercises that
we have found to be relatively difficult and thus unnecessarily discouraging for first timers
have been moved to Book 2. This way, students who are new to Computer Science will
perhaps not feel overly intimidated when they peruse Book 1.
Chapter 1 has a collection of very easy programming contest problems that can be solved
by typical Computer Science students who have just passed (or currently taking) a basic
programming methodology course.
Chapter 2 has received another major update. Now the writeups in the Sections about
Linear and Non-linear Data Structures have been expanded with lots of written exercises so
that this book can also be used to support a Data Structures course, especially in the terms
of implementation details.
The four problem solving paradigms discussed in Chapter 3 appear frequently in typical
Algorithms courses. The text in this chapter has been expanded and edited to help new
Computer Science students.
Parts of Chapter 4 can also be used as a supplementary reading or implementation
guide to enhance a Discrete Mathematics [50, 11] or a basic/intermediate (Graph) Algo-
rithms course. We have also provide some (relatively) new insights on viewing Dynamic
Programming techniques as algorithms on DAGs. Such discussion is currently still regret-
tably uncommon in many Computer Science textbooks.

xvi
PREFACE c Steven, Felix, Suhendry

To Job Seekers Preparing for IT Job Interview

It is well known that many job interviews in top IT companies involve fundamental data
structure/algorithm/implementation questions. Many such questions have been discussed
especially in Book 1 of CP4. We wish you the best in passing those interview(s).
On the other side of the job interview process, some interviewers read this book too in
order to get inspiration for their interview questions.

To ICPC Contestants
You are the primary readers of this CP4. Both Book 1 and Book 2 are for you.
We know that one cannot probably win an ICPC Regional Contest just by mastering
the contents of the current version of this book (CP4). While we have included a lot of
materials in this book—much more than in the first three editions (CP1 ✓ CP2, then CP2
✓ CP3, and finally CP3 ✓ CP4)—we are aware that much more than what this book can
o↵er is required to achieve that feat. Some additional pointers to useful references are listed
in the chapter notes for readers who are hungry for more. We believe, however, that your
team will fare much better in future ICPCs after mastering the contents of this book. We
hope that this book will serve as both inspiration and motivation for your 3-4 year journey
competing in ICPCs during your University days.

To Teachers and Coaches

Wk Topic In CP4
01 Introduction Chapter 1
02 Data Structures & Libraries Chapter 2+9
03 Complete Search Chapter 3+8+9
04 Dynamic Programming Chapter 3+8+9
05 Bu↵er slot Chapter 3/4/9/others
06 Mid-Semester Team Contest Entire Book 1
- Mid-Semester Break -
07 Graph 1 (Network Flow) Chapter 8+9
08 Graph 2 (Matching) Chapter 8+9
09 NP-hard/complete Problems Chapter 8
10 Mathematics Chapter 5+9
11 String Processing (esp Suffix Array) Chapter 6
12 (Computational) Geometry (Libraries) Chapter 7+9
13 Final Team Contest Entire Book 1+2 and beyond
- No Final Examination -

Table 2: Lesson Plan of Steven’s CS3233 (ICPC Regionals Level)

This book is mainly used in Steven’s CS3233 - “Competitive Programming” course in the
School of Computing at the National University of Singapore. CS3233 is conducted in 13
teaching weeks using the lesson plan mentioned in Table 2 (we abbreviate “Week” as “Wk”
in Table 2). Fellow teachers/coaches should feel free to modify the lesson plan to suit your
students’ needs. Hints or brief solutions of the non-starred written exercises in this book
are given at the back of each chapter. Some of the starred written exercises are quite
challenging and have neither hints nor solutions. These can probably be used as exam
questions or for your local contest problems (of course, you have to solve them first!).

xvii
PREFACE c Steven, Felix, Suhendry

To All Readers
Due to its diversity of coverage and depth of discussion, this book is not meant to be
read once, but several times. There are many written (⇡ 258) and programming exercises
(⇡ 3458) listed and spread across almost every section. You can skip these exercises at
first if the solution is too difficult or requires further knowledge and technique, and revisit
them after studying other chapters of this book. Solving these exercises will strengthen
your understanding of the concepts taught in this book as they usually involve interesting
applications, twists or variants of the topic being discussed. Make an e↵ort to attempt
them—time spent solving these problems will definitely not be wasted.
We believe that this book is and will be relevant to many high school students, University
students, and even for those who have graduated from University but still love problem solv-
ing using computers. Programming competitions such as the IOI and ICPC are here to stay,
at least for many years ahead. New students should aim to understand and internalize the
basic knowledge presented in this book before hunting for further challenges. However, the
term ‘basic’ might be slightly misleading—please check the table of contents to understand
what we mean by ‘basic’.
As the title of this book may imply, the purpose of this book is clear: we aim to improve
the reader’s programming and problem solving abilities and thus increase the lower bound
of programming competitions like the IOI and ICPC in the future. With more contestants
mastering the contents of this book, we believe that the year 2010 (CP1 publication year) was
a watershed marking an accelerated improvement in the standards of programming contests.
We hope to help more contestants to achieve greater scores ( 70 – at least ⇡ 6 ⇥ 10 points
for solving all subtask 1 of the 6 tasks of the IOI) in future IOIs and help more teams
solve more problems ( 2 – at least 1 more than the typical 1 giveaway problem per ICPC
problemset) in future ICPCs. We also hope to see many IOI/ICPC coaches around the world
adopt this book for the aid it provides in mastering topics that students cannot do without
in competitive programming contests. If such a proliferation of the required ‘lower-bound’
knowledge for competitive programming is continued in this 2020s decade, then this book’s
primary objective of advancing the level of human knowledge will have been fulfilled, and
we, as the authors of this book, will be very happy indeed.

Convention
There are lots of C/C++, Java, Python, and occasionally OCaml code included in this book.
If they appear, they will be typeset in this monospace font. All code have 2 spaces per
indentation level except Python code (4 spaces per indentation level).
For the C/C++ code in this book, we have adopted the frequent use of typedefs and
macros—features that are commonly used by competitive programmers for convenience,
brevity, and coding speed. However, we may not always be able to use those techniques in
Java, Python, and/or OCaml as they may not contain similar or analogous features. Here
are some examples of our C/C++ code shortcuts:
typedef long long ll; // common data types
typedef pair<int, int> ii; // comments that are mixed
typedef vector<int> vi; // in with code are placed
typedef vector<ii> vii; // on the right side
memset(memo, -1, sizeof memo); // to init DP memo table
vi memo(n, -1); // alternative way
memset(arr, 0, sizeof arr); // to clear array of ints

xviii
PREFACE c Steven, Felix, Suhendry

The following shortcuts are frequently used in both our C/C++ and Java code (not all of
them are applicable in Python or OCaml):

// Shortcuts for "common" constants

const int INF = 1e9; // 10^9 = 1B is < 2^31-1
const int LLINF = 4e18; // 4*10^18 is < 2^63-1
const double EPS = 1e-9; // a very small number
++i; // to simplify: i = i+1;
ans = a ? b : c; // ternary operator
ans += val; // from ans = ans+val;
index = (index+1) % n; // to right or back to 0
index = (index+n-1) % n; // to left or back to n-1
int ans = (int)((double)d + 0.5); // for rounding
ans = min(ans, new_computation); // min/max shortcut
// some code use short circuit && (AND) and || (OR)
// some code use structured bindings of C++17 for dealing with pairs/tuples
// we don’t use braces for 1 liner selection/repetition body
// we use pass by reference (&) as far as possible

Problem Categorization
As of 19 July 2020, Steven, Felix, Suhendry—combined—have solved 2278 UVa problems
(⇡ 45.88% of the entire UVa problemset as of publication date). Steven has also solved
5742.7 Kattis points (⇡ 1.4K other problems and ⇡ 55.46% of the entire Kattis problemset
as of publication date). There are ⇡ 3458 problems have been categorized in this book.
These problems are categorized according to a “load balancing” scheme: if a problem can
be classified into two or more categories, it will be placed in the category with a lower number
of problems. This way, you may find that some problems have been ‘wrongly’ categorized,
where the category that it appears in might not match the technique that you have used to
solve it. We can only guarantee that if you see problem X in category Y, then you know
that we have managed to solve problem X with the technique mentioned in the section that
discusses category Y.
We have also limit each category to at most 35 (THIRTY-FIVE) problems, splitting
them into separate categories when needed. In reality, each category has ⇡ 17 problems on
average. Thus, we have ⇡ 3458/17 ⇡ 200+ categories scattered throughout the book.
Utilize this categorization feature for your training! Solving at least a few problems from
each category is a great way to diversify your problem solving skillset. For conciseness, we
have limited ourselves to a maximum of 4 UVa + 3 Kattis (or 3 UVa + 4 Kattis) = 7 starred
* (must try) problems per category and put the rest as extras (the hints for those extras
can be read online at ‘Methods to Solve’ page of https://cpbook.net). You can say that
you have ‘somewhat mastered’ CP4 if you have solved at least three (3) problems per
category (this will take some time).
If you need hints for any of the problems (that we have solved), flip to the handy index
at the back of this book instead of flipping through each chapter—it might save you some
time. The index contains a list of UVa/Kattis problems, ordered by problem number/id (do
a binary search!) and augmented by the pages that contain discussion of said problems (and
the data structures and/or algorithms required to solve that problem). In CP4, we allow
the hints to span more than one line (but not more than two lines) so that they can be a bit
more meaningful. Of course you can always challenge yourself by not reading the hints first.

xix
PREFACE c Steven, Felix, Suhendry

Changes for CP4

Competitive Programming textbook has been around since 2010 (first edition, dubbed as
CP1), 2011 (second edition/CP2), and especially 2013 (third edition/CP3). There has been
7 years gap2 between the release of CP3 to the release of this CP4 (just before the landmark
IOI 2020 (Online) + IOI 2021 in Singapore). We highlight the important changes of these 7
years worth of additional Competitive Programming knowledge:

• Obviously, we have fixed all known typos, grammatical errors, and bugs that were
found and reported by CP3 readers since 2013. It does not mean that this edition is
100% free from any bug though. We strive to have only very few errors in CP4.

• We have updated many sample code into C++17, Java 11, Python 3, and even some
OCaml. Many of the sample code become simpler with a few more years of program-
ming language update (e.g., C++17 structured binding declaration), the upgraded cod-
ing skills/styles of the authors, and various interesting contributions from our readers
over these past few years.

• We use a public GitHub repo: https://github.com/stevenhalim/cpbook-code that

contains the same sample code content as this book during the release date of this
edition (19 July 2020). Obviously, the content of the GitHub repo will always be more
up-to-date/complete than the printed version as time goes on. Please star, watch, fork,
or even contribute to this public GitHub repo. You are free to use these source code
for your next programming contest or any other purposes.

• We have added Kattis online judge https://open.kattis.com on top of UVa online

judge and have raised the number of discussed problems to ⇡ 3458. This is more
than two times the number in CP3 (1675). Note that there are ⇡ 150+ overlapping
problems in both UVa and Kattis online judges. We only list them once (under Kattis
problem id). Steven is top 9 (out of ⇡ 141 132 users) in Kattis online judge and top 39
(out of ⇡ 365 857) in UVa online judge as of 19 July 2020, i.e., at the 99.9th percentile
for both online judges.

• We have digitized all hints of the ⇡ 3458 problems that we have solved at https:
//cpbook.net/methodstosolve, including the extras that are not fully shown in the
printed version of this book to save space. The online version has search/filter feature
and will always be more up-to-date than the printed version as time goes on. The
750+ problems in Kattis online judge with the lowest points [1.1..3.5] as of 19 July
2020 have been solved by us and are discussed in this book.

• A few outdated problem categories have been adjusted/removed (e.g., Combining Max
1D/2D Range Sum, etc). A few/emerging problem categories have been opened (e.g.,
Pre-calculate-able, Try All Possible Answer(s), Fractions, NP-hard/complete, etc).

• To help our readers avoid the “needle in a haystack” issue, we usually select only top
4 UVa+3 Kattis (or top 3 UVa+4 Kattis), totalling 7 starred problems, per category.
This reduce clutter and will help new competitive programmer to prioritize their train-
ing time on the better quality practice problems. This also saves a few precious pages
that can be used to improve the actual content of the book.

2
Including 10 ICPC Asia Regional Wins in between the release of CP3 (2013) and CP4 (2020).

xx
PREFACE c Steven, Felix, Suhendry

• We have re-written almost every existing topic in the book to enhance their presen-
tation. We have integrated our freely accessible https://visualgo.net algorithm
visualization tool3 as far as possible into this book. Obviously, the content shown in
VisuAlgo will always be more up-to-date than the printed version as time goes on. All
these new additions may be subtle but may be very important to avoid TLE/WA in
the ever increasing difficulties of programming contest problems [17]. Many starred
exercises in CP3 that are now deemed to be ‘standard’ by year 2020 have been inte-
grated into the body text of this CP4 so do not be surprised to see a reduction of the
number of written exercises in some chapters.

• Re-organization of topics compared to CP3, especially to facilitate the cleaner Book 1

versus Book 2 split:

– Book 1 (Chapter 1-4)

1. We select and organize some of the easiest problems found in UVa and Kattis
online judges that were previously scattered in several chapters (especially
from Chapter 5/6/7) into a compilation of exercises for those who have only
started learning basic programming methodology in Chapter 1. It is now
much easier to get the first few ACs in UVa and/or Kattis online judge(s) to
kick start your Competitive Programming journey.
2. We move basic string processing problems and some easier Ad Hoc string
processing problems from Chapter 6 to Chapter 1 and highlight the usage of
short Python code to deal with these problems.
3. We move Roman numerals from Chapter 9 into Chapter 1, it is a rare but
simple Ad Hoc problem.
4. We move Inversion Index and Sorting in Linear Time from Chapter 9 into a
‘Special Sorting Problems’ sub-category in Chapter 2.
5. We move Bracket Matching and Postfix Conversion/Calculator from Chapter
9 into a ‘Special Stack-based Problems’ sub-category in Chapter 2.
6. We move basic Big Integer from Chapter 5 to Chapter 2 as it is essentially a
built-in data structure for Python (3) and Java users (still classified as our-
own library for C++ users). This way, readers can be presented with some
easier Big Integer-related problems from the earlier chapters in Book 1.
7. We move Order Statistics Tree from Chapter 9 as another non-linear data
structure with its C++ specific pbds library in Chapter 2.
8. We swap the order of two sections: Fenwick Tree (its basic form is much more
easier to understand for beginners) and Segment Tree (more versatile).
9. We move (Ad Hoc) Mathematics-related Complete Search problems from
Chapter 5 to Chapter 3.
10. We move Ad Hoc Josephus problem that mostly can be solved with Complete
Search from Chapter 9 to Chapter 3.
– With these content reorganizations, we are happy enough to declare that the
content of Book 1 satisfy most4 of the IOI syllabus [16] as of year 2020.

3
VisuAlgo is built with modern web programming technologies, e.g., HTML5 SVG, canvas, CSS3,
JavaScript (jQuery, D3.js library), PHP (Laravel framework), MySQL, etc. It has e-Lecture mode for basic
explanations of various data structures and algorithms and Online Quiz mode to test basic understanding.
4
Note that the IOI syllabus is an evolving document that is updated yearly.

xxi
PREFACE c Steven, Felix, Suhendry

– Book 2 (Chapter 5-9)

1. We spread Java BigInteger specific features to related sections, e.g., Base
number conversion and simplifying fractions with GCD at Ad Hoc mathe-
matics section, probabilistic prime testing at Number Theory section, and
modular exponentiation at Matrix Power section.
2. We swap the order of two sections in Chapter 5: Number Theory (with
the expanded modular arithmetic section) and Combinatorics (some harder
Combinatorics problem now involve modular arithmetic).
3. We swap the order of two sections in Chapter 6: String Processing with DP
before String Matching. This is so that the discussion of String Matching
spread across three related subsections: standard String Matching (KMP),
Suffix Array, and String Matching with Hashing (Rabin-Karp).
4. We reorganize the categorization of many DP problems that we have solved
in Chapter 8.
5. We defer the discussion of Network Flow from Chapter 4 (in CP3) to Chapter
8 (in CP4) as it is still excluded from the IOI Syllabus [16] as of year 2020.
6. We move Graph Matching from Chapter 9 to Chapter 8, after the related Net-
work Flow section and before the new section on NP-hard/complete problems.
7. We add a new section on NP-complete decision and/or NP-hard optimization
problems in Competitive Programming, compiling ideas that were previously
scattered in CP3. We highlight that for such problem types, we are either
given small instances (where Complete Search or Dynamic Programming is
still sufficient) or the special case of the problem (where specialized polyno-
mial/fast algorithm is still possible—including Greedy algorithm, Network
Flow, or Graph Matching solutions).

• Chapter 1 changes:

1. We add short writeups about the IOI and ICPC, the two important international
programming competitions that use material in this book (and beyond).
2. We include Python (3) as one of the supported programming languages in this
book, especially for easier, non runtime-critical problems, Big Integer, and/or
string processing problems. If you can save 5 minutes of coding time on your first
Accepted solution and your team eventually solves 8 problems in the problem set,
this is a saving of 8 ⇥ 5 = 40 total penalty minutes.
3. We add some OCaml implementations (it is not yet used in the IOI or ICPC).
4. We use up-to-date Competitive Programming techniques as of year 2020.

• Chapter 2 changes:

1. Throughout this data structure chapter, we add much closer integration with our
own freely accessible visualization tool: VisuAlgo.
2. We add Python (3) and OCaml libraries on top of C++ STL and Java API.
3. We significantly expand the discussion of Binary Heap, Hash Table, and (bal-
anced) Binary Search Tree in Non-linear Data Structures section that are typically
discussed in a “Data Structures and Algorithms” course.

xxii
PREFACE c Steven, Felix, Suhendry

4. We emphasize the usage of the faster Hash Tables (e.g., C++ unordered map)
instead of balanced BST (e.g., C++ map) if we do not need the ordering of keys
and the keys are basic data types like integers or strings. We also recommend the
simpler Direct Addressing Table (DAT) whenever it is applicable.
5. We highlight the usage of balanced BSTs as a powerful (but slightly slower)
Priority Queue and as another sorting tool (Tree Sort).
6. We discuss ways to deal with graphs that are not labeled with [0..V -1] and on
how to store some special graphs more efficiently.
7. We enhance the presentation of the UFDS data structure.
8. We add more features of Fenwick Tree data structure: Fenwick Tree as (a variant
of) order statistics data structure, Range Update Point Query variant, and Range
Update Range Query variant.
9. We add more feature of Segment Tree data structure: Range Update with Lazy
Propagation to maintain its O(log n) performance.

• Chapter 3 changes:

1. We add two additional complete search techniques: Pre-calculate all (or some)
answers and Try all possible answers (that cannot be binary-searched; or when the
possible answers range is small). We also update iterative bitmask implementation
to always use LSOne technique whenever possible. We also add more complete
search tips, e.g., data compression to make the problem amenable to complete
search techniques. We also tried Python for Complete Search problems. Although
Python will mostly get TLE for harder Complete Search problems, there are ways
to make Python usable for a few easier Complete Search problems.
2. We now favor implementation of Binary Search the Answer (BSTA) using for loop
instead of while loop. We also integrate Ternary Search in this chapter.
3. We now consider greedy (bipartite) matching as another classic greedy problem.
We add that some greedy algorithms use Priority Queue data structure to dy-
namically order the next candidates greedily.
4. We now use the O(n log k) LIS solution (‘patience sort’, not DP) as the de-
fault solution for modern LIS problem. We now use LSOne technique inside the
O(2n 1 ⇥ n2 ) DP-TSP solution to allow it to solve n  [18..19] faster.

• Chapter 4 changes:

1. We redo almost all screenshots in this Chapter 4 using VisuAlgo tool.

2. We now set Kosaraju’s algorithm as the default algorithm for finding Strongly
Connected Components (SCCs) as it is simpler than Tarjan’s algorithm.
3. We significantly expand the Shortest Paths section with many of its known vari-
ations. We discuss and compare both versions of Dijkstra’s algorithm implemen-
tations. We move SPFA from Chapter 9, position this algorithm as Bellman-Ford
‘extension’, and called it as Bellman-Ford-Moore algorithm.
4. We significantly update the section on Euler graph and replace Fleury’s algorithm
with the better Hierholzer’s algorithm.
5. We add remarks about a few more special (rare) graphs and their properties.

xxiii
PREFACE c Steven, Felix, Suhendry

• Chapter 5 changes:

1. We expand the discussion of this easy but big Ad Hoc Mathematics-related prob-
lems. We identify one more recurring Ad Hoc problems in Mathematics: Fraction.
2. We recognize the shift of trend where the number of pure Big Integer problems
is decreasing and the number of problems that require modular arithmetic is
increasing. Therefore, the discussion on modular arithmetic in Number Theory
section have been significantly expanded and presented earlier before being used
in latter sections, e.g., Fermat’s little theorem/modular multiplicative inverse
is used in the implementation of Binomial Coefficients and Catalan Numbers
in Combinatorics section, modular exponentiation is now the default in Matrix
Power section.
3. We expand the Combinatorics section with more review of counting techniques.
4. We expand the discussion of Probability-related problems.
5. We enhance the explanation of Floyd’s (Tortoise-Hare) cycle-finding algorithm
with VisuAlgo tool.
6. We integrate Matrix Power into this chapter, expanded the writeup about matrix
power, and integrate modular arithmetic techniques in this section.

• Chapter 6 changes:

1. We discuss Digit DP as one more string processing problem with DP.

2. We further strengthen our General Trie/Suffix Trie/Tree/Array explanation.
3. We add String Hashing as alternative way to solve string processing related prob-
lems including revisiting the String Matching problem with hashing.
4. We integrate and expand section on Anagram and Palindrome, both are classic
string processing problems that have variants with varying difficulties.

• Chapter 7 changes:

1. We further enhance the existing library routines, e.g., (the shorter to code) An-
drew’s Monotone Chain algorithm is now the default convex hull algorithm, re-
placing (the slightly longer to code and a bit slower) Graham’s Scan.
2. We redo the explanation and add VisuAlgo screenshots of algorithms on Polygon.

• Chapter 8 changes:

1. We now set the faster O(V 2 ⇥ E) Dinic’s algorithm as the default algorithm,
replacing the slightly slower O(V ⇥ E 2 ) Edmonds-Karp algorithm. We also add
a few more network flow applications.
2. We expand the discussion of Graph Matching and its bipartite/non-bipartite +
unweighted/weighted variants. We augment the Augmenting Path algorithm with
the randomized greedy pre-processing step by default.
3. We add a few more problem decomposition related techniques and listed many
more such problems, ordered by their frequency of appearance.

xxiv
PREFACE c Steven, Felix, Suhendry

• Chapter 9 changes:

1. On top of enhancing previous writeups, we add more collection of new rare data
structures, algorithms, and/or programming problems that have not been listed
in the first eight chapters and did not appear in CP3. These new topics are:
(a) Square Root Decomposition,
(b) Heavy-Light Decomposition,
(c) Tree Isomorphism,
(d) De Bruijn Sequence,
(e) Fast Fourier Transform,
(f) Chinese Remainder Theorem,
(g) Lucas’ Theorem,
(h) Combinatorial Game Theory,
(i) Egg Dropping Puzzle,
(j) Dynamic Programming Optimization,
(k) Push-Relabel algorithm,
(l) Kuhn-Munkres algorithm,
(m) Edmonds’ Matching algorithm,
(n) Constructive Problem,
(o) Interactive Problem,
(p) Linear Programming,
(q) Gradient Descent.

• In summary, someone who only master CP3 (published back in 2013) content can be
easily beaten in a programming contest by someone who only master CP4 content
(published in year 2020).

Supporting Websites
This book has an official companion web site at https://cpbook.net. The Methods to
Solve tool is in this web site too.
We have also uploaded (almost) all source code discussed in this book in the public
GitHub repository of this book: https://github.com/stevenhalim/cpbook-code.
Since the third edition of this book, many data structures and algorithms discussed in
this book already have interactive visualizations at https://visualgo.net.
All UVa Online Judge programming exercises in this book have been integrated in the
https://uhunt.onlinejudge.org/ tool.
All Kattis Online Judge programming exercises in this book can be easily accessed using
the “Kattis Hint Giver” Google Chrome extension (created by Steven’s student Lin Si Jie)
that integrates the content of Methods to Solve directly to Kattis’s problems pages.

xxv
PREFACE c Steven, Felix, Suhendry

Copyright
In order to protect the intellectual property, no part of this book may be reproduced or
transmitted in any form or by any means, electronically or mechanically, including photo-
copying, scanning, uploading to any storage and retrieval system, without official permission
of the authors.

To a better future of humankind,

Steven Halim, Felix Halim, and Suhendry Effendy
Singapore, 19 July 2020

xxvi
Authors’ Profiles

Steven Halim, PhD5

stevenhalim@gmail.com
Steven Halim is a senior lecturer in School of Comput-
ing, National University of Singapore (SoC, NUS). He
teaches several programming courses in NUS, rang-
ing from basic programming methodology, intermedi-
ate to hard data structures and algorithms, web pro-
gramming, and also the ‘Competitive Programming’
module that uses this book. He is the coach of both
the NUS ICPC teams and the Singapore IOI team. He participated in several ICPC Re-
gionals as a student (Singapore 2001, Aizu 2003, Shanghai 2004). So far, he and other
trainers @ NUS have successfully groomed various ICPC teams that won ten di↵erent ICPC
Regionals (see below), advanced to ICPC World Finals eleven times (2009-2010; 2012-2020)
with current best result of Joint-14th in ICPC World Finals Phuket 2016 (see below), as
well as seven gold, nineteen silver, and fifteen bronze IOI medalists (2009-2019). He is also
the Regional Contest Director of ICPC Asia Singapore 2015+2018 and is the Deputy Di-
rector+International Committee member for the IOI 2020+2021 in Singapore. He has been
invited to give international workshops about ICPC/IOI at various countries, e.g., Bolivia
ICPC/IOI camp in 2014, Saudi Arabia IOI camp in 2019, Cambodia NOI camp in 2020.
Steven is happily married to Grace Suryani Tioso and has two daughters and one son:
Jane Angelina Halim, Joshua Ben Halim, and Jemimah Charissa Halim.
ICPC Regionals # Year(s)
Asia Jakarta 5 2013 (ThanQ), 2014 (ThanQ+), 2015 (RRwatameda),
2017 (DomiNUS), 2019 (Send Bobs to Alice)
Asia Manila 2 2017 (Pandamiao), 2019 (7 Halim)
Asia Nakhon Pathom 1 2018 (Pandamiao)
Asia Yangon 1 2018 (3body2)
Asia Kuala Lumpur 1 2019 (3body3)

Table 3: NUS ICPC Regionals Wins in 2010s

ICPC World Finals Team Name Rank Year

Phuket, Thailand RRwatameda Joint-14/128 2016
Ekaterinburg, Russia ThanQ+ Joint-19/122 2014
Rapid City, USA TeamTam Joint-20/133 2017

Table 4: NUS ICPC World Finals Top 3 Results in 2010s

5
PhD Thesis: “An Integrated White+Black Box Approach for Designing and Tuning Stochastic Local
Search Algorithms”, 2009.

xxvii
AUTHORS’ PROFILES c Steven, Felix, Suhendry

Felix Halim, PhD6

felix.halim@gmail.com
Felix Halim is a senior software engineer at Google.
While in Google, he worked on distributed system
problems, data analysis, indexing, internal tools, and
database related stu↵. Felix has a passion for web
development. He created uHunt to help UVa on-
line judge users find the next problems to solve.
He also developed a crowdsourcing website, https:
//kawalpemilu.org, to let the Indonesian public to
oversee and actively keep track of the Indonesia gen-
eral election in 2014 and 2019.
As a contestant, Felix participated in IOI 2002 Ko-
rea (representing Indonesia), ICPC Manila 2003-2005,
Kaohsiung 2006, and World Finals Tokyo 2007 (rep-
resenting Bina Nusantara University). He was also
one of Google India Code Jam 2005 and 2006 final-
ists. As a problem setter, Felix set problems for ICPC
Jakarta 2010, 2012, 2013, ICPC Kuala Lumpur 2014,
and several Indonesian national contests.
Felix is happily married to Siska Gozali. The picture on the right is one of their Europe
honeymoon travel photos (in Switzerland) after ICPC World Finals @ Porto 2019. For more
information about Felix, visit his website at https://felix-halim.net.

Suhendry E↵endy, PhD7

suhendry.e↵endy@gmail.com
Suhendry E↵endy is a research fellow in the School
of Computing of the National University of Singa-
pore (SoC, NUS). He obtained his bachelor degree
in Computer Science from Bina Nusantara University
(BINUS), Jakarta, Indonesia, and his PhD degree in
Computer Science from National University of Singa-
pore, Singapore. Before completing his PhD, he was
a lecturer in BINUS specializing in algorithm anal-
ysis and served as the coach for BINUS competitive
programming team (nicknamed as “Jollybee”).
Suhendry is a recurring problem setter for the
ICPC Asia Jakarta since the very first in 2008. From
2010 to 2016, he served as the chief judge for the
ICPC Asia Jakarta collaborating with many other
problem setters. He also set problems in many other
contests, such as the ICPC Asia Kuala Lumpur, the
ICPC Asia Singapore, and Olimpiade Sains Nasional
bidang Komputer (Indonesia National Science Olympiad in Informatic) to name but a few.

6
PhD Thesis: “Solving Big Data Problems: from Sequences to Tables and Graphs”, 2012.
7
PhD Thesis: “Graph Properties and Algorithms in Social Networks: Privacy, Sybil Attacks, and the
Computer Science Community”, 2017.

xxviii
Abbreviations

A* : A Star I/O : Input/Output

ACM : Assoc for Computing Machinery IOI : Intl. Olympiad in Informatics
AC : Accepted IPSC : Internet Problem Solving Contest
ADT : Abstract Data Type
AL : Adjacency List KISS : Keep It Short and Simple
AM : Adjacency Matrix LA : Live Archive [30]
APSP : All-Pairs Shortest Paths LCA : Lowest Common Ancestor
AVL : Adelson-Velskii Landis (BST) LCE : Longest Common Extension
BNF : Backus Naur Form LCM : Least Common Multiple
BFS : Breadth First Search LCP : Longest Common Prefix
BI : Big Integer LCS1 : Longest Common Subsequence
BIT : Binary Indexed Tree LCS2 : Longest Common Substring
bBST : (balanced) Binary Search Tree LIFO : Last In First Out
BSTA : Binary Search the Answer LIS : Longest Increasing Subsequence
LRS : Longest Repeated Substring
CC : Coin Change LSB : Least Significant Bit
CCW : Counter ClockWise
CF : Cumulative Frequency MCBM : Max Cardinality Bip. Matching
CH : Convex Hull MCM1 : Max Cardinality Matching
CRT : Chinese Remainder Theorem MCM2 : Matrix Chain Multiplication
CS : Computer Science MCMF : Min-Cost Max-Flow
CW : ClockWise MIS : Max Independent Set
MLE : Memory Limit Exceeded
DAG : Directed Acyclic Graph MPC : Min Path Cover
DAT : Direct Addressing Table MSB : Most Significant Bit
D&C : Divide and Conquer MSSP : Multi-Sources Shortest Paths
DFS : Depth First Search MST : Min Spanning Tree
DLS : Depth Limited Search MWIS : Max Weight Independent Set
DP : Dynamic Programming MVC : Min Vertex Cover
DS : Data Structure MWVC : Min Weight Vertex Cover

ED : Edit Distance NP : Non-deterministic Polynomial

EL : Edge List
OJ : Online Judge
FFT : Fast Fourier Transform
FIFO : First In First Out PE : Presentation Error
FT : Fenwick Tree RB : Red-Black (BST)
GCD : Greatest Common Divisor RMQ : Range Min (or Max) Query
RSQ : Range Sum Query
HLD : Heavy-Light Decomposition RTE : Run Time Error
RUPQ : Range Update Point Query
ICPC : Intl. Collegiate Prog. Contest RURQ : Range Update Range Query
IDS : Iterative Deepening Search
IDA* : Iterative Deepening A Star SSSP : Single-Source Shortest Paths
xxix
ABBREVIATIONS c Steven, Felix, Suhendry

SA : Suffix Array
SPOJ : Sphere Online Judge
ST : Suffix Tree
STL : Standard Template Library

TLE : Time Limit Exceeded

USACO : USA Computing Olympiad

UVa : University of Valladolid [44]

WA : Wrong Answer
WF : World Finals

xxx
Chapter 1

Introduction

I want to compete in ICPC World Finals!

— A dedicated student

1.1 Competitive Programming

The core directive in ‘Competitive Programming’ is this: “Given well-known Computer
Science (CS) problems, solve them as quickly as possible!”.
Let’s digest the terms one by one. The term ‘well-known CS problems’ implies that in
competitive programming, we are dealing with solved CS problems and not research problems
(where the solutions are still unknown). Some people (at least the problem author) have
definitely solved these problems before. To ‘solve them’ implies that we1 must push our CS
knowledge to a certain required level so that we can produce working code that can solve
these problems too—at least in terms of getting the same output as the problem author
using the problem author’s secret2 test data within the stipulated time limit. The need to
solve the problem ‘as quickly as possible’ is where the competitive element lies—speed is a
very natural goal in human behavior.

An illustration: UVa Online Judge [44] Problem Number 10911 (Forming Quiz Teams).
Abridged Problem Description:
Let (x, y) be the integer coordinates of a student’s house on a 2D plane. There
are 2N students and we want to pair them into N groups. Let di be the distance
P
between the houses of 2 students in group i. Form N groups such that cost = Ni=1 di
is minimized. Output the minimum cost as a floating point number with 2 digits
precision in one line. Constraints: 1  N  8 and 0  x, y  1000.
Sample input (with explanation):
N = 2; Coordinates of the 2N = 4 houses are {1, 1}, {8, 6}, {6, 8}, and {1, 3}.
Sample output (with explanation):
cost = 4.83.
Can you solve this problem?
If so, how many minutes would you likely require to complete the working code?
Think and try not to flip this page immediately!
1
Some programming competitions are done in a team setting to encourage teamwork as software engineers
usually do not work alone in real life.
2
By hiding the actual test data from the problem statement, competitive programming encourages the
problem solvers to exercise their mental strength to think of many (if not all) possible corner cases of the
problem and test their programs with those cases. This is typical in real life where software engineers have
to test their software a lot to make sure that the software meets the requirements set by clients.

1
1.1. COMPETITIVE PROGRAMMING c Steven, Felix, Suhendry

Figure 1.1: Illustration of UVa 10911 - Forming Quiz Teams

Now ask yourself: Which of the following best describes you? Note that if you are
unclear with the material or the terminology shown in this chapter, you can re-read it
again after going through this book once.
• Uncompetitive programmer A (a.k.a. the blurry one):
Step 1: Reads the problem and becomes confused. (This problem is new for A).
Step 2: Tries to code something: Reading the non-trivial input and output.
Step 3: A realizes that these two ideas below are not Accepted (AC):
Greedy (Section 3.4): Repeatedly pairing the two remaining students with the
shortest separating distances gives the Wrong Answer (WA).
Naı̈ve Complete Search: Using recursive backtracking (Section 3.2) and trying
all possible pairings yields Time Limit Exceeded (TLE).
• Uncompetitive programmer B (Gives up):
Step 1: Reads the problem and realizes that it is a graph matching problem.
But B has not learned how to solve this kind of problem...
B is not aware of the Dynamic Programming (DP) solution (Section 3.5)...
Step 2: Skips the problem and reads another problem in the problem set.
• (Still) Uncompetitive programmer C (Slow):
Step 1: Reads the problem and realizes that it is a difficult problem: ‘minimum
weight perfect matching on a weighted complete graph’. However, since
the input size is small, this problem is solvable using DP. The DP state is a
bitmask that describes a matching status, and matching unmatched students i
and j will turn on two bits i and j in the bitmask (see Book 2).
Step 2: Codes I/O routine, writes recursive top-down DP, tests, debugs >.<...
Step 3: After 3 hours, C’s solution is AC (passed all the secret test data).
• Competitive programmer D:
Completes all the steps taken by uncompetitive programmer C in  30 minutes.
• Very competitive programmer E:
A very competitive programmer (e.g., the red coders in Codeforces [4]) would
solve this ‘well known’ problem in  10 minutes and possibly also aware of the
various other possible solutions for the (harder) variant(s) of this problem...

Please note that being well-versed in competitive programming is not the end goal, but only
a means to an end. The true end goal is to produce all-rounder computer scientists or pro-
grammers who are much readier to produce better software and to face harder CS research
problems in the future. This is one of the objectives of the International Olympiad in Infor-
matics (IOI) [31] and the vision of the founders of the International Collegiate Programming
Contest (ICPC) [57]. With this book, we play our little role in preparing the current and fu-
ture generations to be more competitive in dealing with well-known CS problems frequently
posed in the recent IOIs and ICPCs.

2
CHAPTER 1. INTRODUCTION c Steven, Felix, Suhendry

Exercise 1.1.1: The greedy strategy of the uncompetitive programmer A above actually
works for the sample test case shown in Figure 1.1 as typically good problem authors do not
put their corner cases as sample test cases. Please give a better counter example!
Exercise 1.1.2: Analyze the time complexity of the naı̈ve complete search solution by
uncompetitive programmer A above to understand why it receives the TLE verdict!
Exercise 1.1.3*: Actually, a clever recursive backtracking solution with pruning can still
solve this problem (with 1  N  8). Solve this problem without using a DP table!

1.2 The Competitions

There are a few international programming competitions in the world. In this section, we
outline two of the most important programming competitions. The authors of this book are
(heavily) involved in these programming competitions.

1.2.1 International Olympiad in Informatics (IOI)

History and Format
IOI was started in 1989 (in Bulgaria) and it has been around annually since then. Singapore
hosts3 IOI in 2020+2021 and the authors of this book play crucial roles in those two back-
to-back IOIs. The IOI statistics can be found at https://stats.ioinformatics.org/.
IOI format: (optional) high school selection, (optional) provincial selection, National
Olympiad in Informatics (NOI) or other national top 4 selection methods (as each coun-
try/region can only send up to 4 contestants to IOI per year), and finally the actual IOI
(usually held in the months of June to September).

Eligibility and Selection

IOI eligibility rule can be found in the IOI regulations [31].
As IOI participants can come from various (secondary or high) schools of a country/region,
established (large) teams usually do preliminary Internet based selection/aptitude test, con-
duct intensive training camps in a centralized location, and gradually narrow down their
team selection via NOI or other selection methods until only top 4 students remain. These
top 4 represent the best 4 young students in Informatics, especially in the area of competitive
programming, that can be found and available to represent their country/region that year.
IOI team of a certain country/region is usually headed by a team leader that has experi-
ence managing their national training and olympiad. Ministry of Education representatives
and/or onsite coach(es) from that country/region is/are also usually present.

Typical Contest Strategies

IOI competition consists of (usually) 2-hours practice4 session and two contest days5 , 5 hours
per session. IOI is an individual contest6 . Each contest (usually) consists of 3 tasks, usually
one easi(er), one medium, and one hard(er) task, which are further divided into subtasks
with various points.
3
Online IOI in 2020 due to COVID-19.
4
The problems are usually already distributed online a few weeks prior to the actual IOI.
5
It is important to maintain stamina and emotional well-being for both contest days.
6
IOI 2018 used a one-o↵ live statistics of task scores to help contestants identify easier tasks.

3
1.2. THE COMPETITIONS c Steven, Felix, Suhendry

The International Scientific Committee (ISC) will strive to make the sum of subtask
points to be as diverse as possible to minimize ties7 (especially along medal boundaries). To
make IOI training in various national teams more manageable, the ISC maintains the IOI
syllabus [16].
Coding speed is usually not a di↵erentiating factor in IOI. One can submit a 100 points
(full) solution at time 4h59m and still be rewarded with the same 100 points compared to
one that submits 100 points solution at 30m. Thus IOI emphasizes peak performance, i.e.,
ability to solve the (harder) subtasks instead of how fast one can solve the (easier) subtasks8 .
Historically, to get a gold/silver/bronze medal, one should get 400+/300+/200+ points
(out of possible 600) after two contest days, respectively.
The main purpose of this book is to make the number of IOI participants scoring low total
points (under 70 points) after two contest days to be as low as possible. Not all subtasks in
IOI are hard as the ISC also needs to avoid demoralizing half of the contestants that will go
home without any medal. They are still future Computer Scientists after all.

What’s Next?
Many, but not all, of IOI medalists/alumni continue to study in the field of Computer
Science for their University degree9 . Many of them (but not all ) also join the next level
of Programming Contests: The ICPC (see the next subsection 1.2.2). Thus, if one already
knows this book from high school, he/she can use it throughout University too.

1.2.2 International Collegiate Programming Contests (ICPC)

History and Format
ICPC10 was established in 1970, originated from the USA, spread worldwide starting from the
1990s. Since 2000 (except 2003 and 2007), the winners are usually from Russian (especially
from 2012-2019) and Asian Universities.
ICPC format: (optional) University level selection, (optional) Preliminary contest, Re-
gional Contest (usually held in the months of October to December). The winners (and
sometimes the runner-ups and a few other slightly lower ranked teams) from various Region-
als will advance to World Finals in the following year (usually held in the months of April
to July). The participation levels grow significantly (< 10K in 2000, > 50K in 2020) [57].
As ICPC is a programming competition between Universities, the ICPC coaches are
usually University CS sta↵s who teach programming and/or algorithm classes.
ICPC competition runs for 5 hours. Each team consists of three University students.
Each team is only provided with one computer. Only submissions that are Accepted (fully
correct) will give +1 point to the team. Team gets penalty for each non-Accepted submission
(usually +20 minutes to their total time). Teams are ranked first by decreasing number of
problems solved and if ties, by lower penalty time, and if still ties (rare), by earlier time
of last Accepted submission. Most contests end with the second tie breaking criteria (the
winner and the runner up solved the same number of problems, one is faster than the other).
Win by a +1 margin is rare. Win by a +2 or more margin is extremely rare.
7
ISC may use floating point scoring system to help achieve this objective, e.g., in IOI 2015, 2017, 2019.
8
Implementing solution(s) for low-scoring subtask(s), no matter how fast one can code the solution,
consume a bit of contest time. Thus, this strategy is not optimal for top contestants who are aiming for
(good quality) medal who should think of the best possible solution for an extended duration first.
9
Many are with scholarships.
10
ICPC was previously under the auspices of Association of Computing Machinery (ACM).

4
CHAPTER 1. INTRODUCTION c Steven, Felix, Suhendry

Eligibility and Selection

Unlike IOI, where contestants compete individually representing their own country/region,
in ICPC contestants can be from various nationalities, as long as they are representing the
same University and still eligible according to ICPC eligibility rule.
Established Universities usually conduct their own internal training, team formation and
selection, before sending the strong(er) teams to compete in the Regionals.

Typical Contest Strategies

ICPC problem sets are usually designed in such a way that all teams solve at least one
problem (to avoid totally demoralizing newcomers in the competition, this is what we strive
to help via this book), no team solves all problems (to make the contest interesting until the
end of the fifth hour), and all problems are solvable by at least one team (thus minimize the
number of ‘impossible’ problems that require much more than 5 hours to think and code out
the solution correctly – even for the perceived favorite team(s) before the contest).
We can break down a 5-hours ICPC into three big stages: The start, the mid-game, and
the end-game. In ICPC, time penalty11 plays a crucial role, hence the ability to find easy (or
easier) problems that are buried inside the 10-13 problems in the problem set and solve them
as quickly as possible with 0 or as few penalties as possible, is crucial. Some (but not all)
contests purposely designate problem A (the first page) to be the easiest problem. For top
teams, the performance at the start dictates the tone for the rest of the contest, i.e., leading
or playing catch up. Most top teams will run in individual mode at this stage, i.e., each of
the 3 team members try to solve the first 3 easiest problems individually. Teams that rely
on the public scoreboard to identify which problems are easier will always play catch up.
The mid-game usually starts around the second to the third hour. At this point, all three
team members should have read all problems (that have not been solved up to that point
of time) and rank them based on (perceived) difficulties (and after comparing it with the
current public scoreboard). For top teams, ability to keep generating results at this stage –
i.e., the queue of next problem(s) to be solved/coded is not empty – is very important. As
the unsolved problems at this stage are the medium-hard problems (according to that team),
good team work is important. Some top teams with 3 strong contestants can probably still
work as 3 individuals. Some teams will switch to a pair + 1 individual. The rest of the teams
probably have to pool all 3 team members’ strengths in bid to solve one more problem.
The end-game starts when all easy and medium problems (according to that team) have
been solved by the team and the team is left with problems that the team has not solved
before (or have to spend lots of time to solve during practice sessions). Top teams will only
have a few remaining problems left at this stage and should be able to estimate what is the
time needed to solve +1 more so that they can submit +1 more AC code at minute 299
rather than after minute 300. For many other teams, this stage is about salvaging the result
with all 3 members working on one last not-yet-solved problem, hoping that they do not
get stuck. Most contests do not end with a clean sweep where the winning team solve all
problems as the judges usually set the required theoretical total time to solve all problems
(by the perceived favorite team(s) before the contest) to be longer than 5 contest hours.

What’s Next?
Most competitive programmers will likely end their competition career after their last ICPC.
Good performance in ICPC during University days is probably a(n important) requirement
in order to excel in technical interviews in (top) IT companies.
11
Some ex-IOI contestants may need to improve their implementation speed for ICPC.

5
1.3. TIPS TO BE COMPETITIVE c Steven, Felix, Suhendry

1.2.3 Other Programming Contests

Beyond University, there are other various programming competitions, mostly online (with
perhaps last onsite final). For example, Google CodeJam, Facebook Hacker Cup, Topcoder
Open, Codeforces contest, Internet Problem Solving Contest (IPSC), etc. These other pro-
gramming competitions are not specifically covered in this book.

1.3 Tips to be Competitive

If you strive to be like competitive programmers D or E as illustrated in Section 1.1—that
is, if you want to be selected (via provincial/state ! national team selections) to participate
and obtain a medal in the IOI [31], or to be one of the team members that represents your
University in the ICPC [57] (nationals ! Regionals ! and up to World Finals), or to do
well in other programming contests—then this book is definitely for you12 !
In the subsequent chapters, you will learn many things from the basic to the intermediate
or even to the advanced13 data structures and algorithms that have frequently appeared in
recent programming contests, compiled from many sources [45, 7, 49, 38, 51, 40, 53, 1, 35, 6,
52, 39, 5, 54, 42, 18, 37, 36] (see Figure 1.4). You will not only learn the concepts behind the
data structures and algorithms, but also how to implement them efficiently and apply them
to appropriate contest problems. On top of that, you will also learn many programming tips
derived from our own experiences that can be helpful in contest situations. We start this
book by giving you several general tips below:

1.3.1 Tip 1: Type Code Faster!

No kidding! Although this tip may not mean much as ICPC and (especially) IOI are not
typing contests, we have seen Rank i and Rank i + 1 ICPC teams separated only by a few
minutes14 and frustrated IOI contestants who miss out on salvaging important marks by not
being able to code a last-minute brute force solution properly. When you can solve the same
number of problems as your competitor, it will then be coding skill (your ability to produce
concise and robust code) and ... typing speed ... that determine the winner.
Try this typing test at https://www.typingtest.com and follow the instructions there
on how to improve your typing skill. Steven’s is ⇠85-95 wpm15 , Felix’s is ⇠55-65 wpm, and
Suhendry’s is ⇠70-80 wpm. If your typing speed is much less than these numbers, please
take this tip seriously!
On top of being able to type alphanumeric characters quickly and correctly, you will
also need to familiarize your fingers with the positions of the frequently used programming
language characters: round () or curly {} or square [] or angle <> parentheses/brackets,
the semicolon ; and colon :, single quotes ‘’ for characters, double quotes “” for strings, the
ampersand &, the vertical bar or the ‘pipe’ |, the exclamation mark !, etc.
12
Notice that in a (large) competition, there can only be one (or very few) winner(s), i.e., the probability
of not winning anything throughout your programming competition life is much higher than the opposite.
Thus, although you should still dream high and try to win at least one programming competition, you should
ultimately aim to better your programming and problem solving skills by reading books like this one.
13
Whether you perceive the material presented in this book to be of easy, intermediate, or advanced level
depends on your programming, algorithmic, and problem solving skills prior to reading this book.
14
Fast performance at the early stage of an ICPC is very beneficial. As an illustration, team A and team
B both solve a total of 8 problems. Team A gets its first AC only 5 minutes earlier than team B. They then
solve the next 7 problems at exactly the same speed. Team A wins by having 8 ⇥ 5 = 40 minutes lesser total
penalty time.
15
A few of the authors’ ICPC World Finalist students have typing speed faster than 120+ wpm. Note
that the average typing speed globally is just ⇡ 40 wpm.

6
CHAPTER 1. INTRODUCTION c Steven, Felix, Suhendry

As a little practice, try typing the C++ source code below as fast as possible16 :

/* Forming Quiz Teams, the solution for UVa 10911 above */

#include <bits/stdc++.h> // include all libraries
using namespace std;

#define LSOne(S) ((S) & -(S)) // important speedup

int N; // max N = 8
double dist[20][20], memo[1<<16]; // 1<<16 = 2^16

double dp(int mask) { // DP state = mask

double &ans = memo[mask]; // reference/alias
if (ans > -0.5) return ans; // this has been computed
if (mask == 0) return 0; // all have been matched
ans = 1e9; // init with a large value
int two_pow_p1 = LSOne(mask); // speedup
int p1 = __builtin_ctz(two_pow_p1); // p1 is first on bit
int m = mask-two_pow_p1; // turn off bit p1
while (m) {
int two_pow_p2 = LSOne(m); // then, try to match p1
int p2 = __builtin_ctz(two_pow_p2); // with another on bit p2
ans = min(ans, dist[p1][p2] + dp(mask^two_pow_p1^two_pow_p2));
m -= two_pow_p2; // turn off bit p2
}
return ans; // memo[mask] == ans
}

int main() {
int caseNo = 0, x[20], y[20];
while (scanf("%d", &N), N) { // yes, we can do this :)
for (int i = 0; i < 2*N; ++i)
scanf("%*s %d %d", &x[i], &y[i]); // ‘%*s’ skips names
for (int i = 0; i < 2*N-1; ++i) // build distance table
for (int j = i+1; j < 2*N; ++j) // use ‘hypot’ function
dist[i][j] = dist[j][i] = hypot(x[i]-x[j], y[i]-y[j]);
for (int i = 0; i < (1<<16); ++i) memo[i] = -1.0;
printf("Case %d: %.2lf\n", ++caseNo, dp((1<<(2*N)) - 1));
}
return 0;
} // DP to solve min weighted perfect matching on small general graph

Source code: ch8/UVa10911.cpp|java|py|ml

For your reference, the explanations of this ‘Dynamic Programming with bitmask’ solution
are gradually given in Section 2.2, 3.5, and later in Book 2. Do not be alarmed if you do not
understand it yet.
16
Notice that the typical Competitive Programming coding style actually violates many good Software
Engineering principles, e.g., over usage of global variables, usage of cryptic and incredibly short variable
names, inclusion of all available header files, over usage of bit manipulation, using namespace std, etc.

7
1.3. TIPS TO BE COMPETITIVE c Steven, Felix, Suhendry

1.3.2 Tip 2: Quickly Identify Problem Types

In recent ICPCs, the contestants (teams) are given a set of problems (⇡ 10-13 problems)
of varying types. From our observation of recent ICPC Asia Regionals and World Finals
problem sets, we can categorize the problems types and their rate of appearance as in Table
1.1. In IOIs, the contestants are given 6 tasks over 2 days17 that cover items 1-7 and a bit
of item 11, with a much smaller subset of items 8-11. For more details, please refer to the
IOI 1989-2008 problem classification [58] and the latest IOI syllabus [16].
No Category In This Book Frequency
1. Ad Hoc Section 1.4-1.6 1-2
2. (Heavy) Data Structure Chapter 2 0-1
3. Complete Search (Iterative/Recursive) Section 3.2++ 1-2
4. Divide and Conquer Section 3.3 0-1
5. Greedy (the non-classic ones) Section 3.4 1
6. Dynamic Programming (the non-classic ones) Section 3.5++ 1-2
7. Graph (except Network Flow/Graph Matching) Chapter 4 1
8. Mathematics Chapter 5 1-2
9. String Processing Chapter 6 1
10. Computational Geometry Chapter 7 1
11. Some Harder/Rare/Emerging Trend Problems Chapter 8-9 2-3
Total in Set is usually  14 10-17
Table 1.1: Recent ICPC (Asia) Regionals Problem Types
The classification in Table 1.1 is adapted from [43] and by no means complete. Some tech-
niques, e.g., ‘sorting’, are not classified here as they are ‘trivial’ and usually used only as
a ‘sub-routine’ in a bigger problem. We do not include ‘recursion’ as it is embedded in
categories like recursive backtracking or Dynamic Programming. Of course, problems some-
times require mixed techniques: a problem can be classified into more than one type, e.g.,
Floyd-Warshall algorithm is both a solution for the All-Pairs Shortest Paths (APSP, Section
4.5) graph problem and a Dynamic Programming (DP) algorithm (Section 3.5). Prim’s and
Kruskal’s algorithms are both solutions for the Minimum Spanning Tree (MST, Section 4.3)
graph problem and Greedy algorithms (Section 3.4). In Book 2, we will discuss (harder)
problems that require more than one algorithm and/or data structure to be solved.
In the (near) future, these classifications may change. One significant example is Dynamic
Programming. This technique was not known before 1940s, nor frequently used in IOIs or
ICPCs before mid-1990s, but it is considered a definite prerequisite today. As an illustration:
There were 3 DP problems (out of 11) in ICPC World Finals 2010.
However, the main goal is not just to associate problems with the techniques required to
solve them like in Table 1.1. Once you are familiar with most of the topics in this book, you
should also be able to classify problems into the four types in Table 1.2.

No Category Confidence and Expected Solving Speed

A1. I have solved this type before I am sure that I can re-solve it again (and fast)
A2. I have solved this type before I am sure that I can re-solve it again (but slow)
B. I have seen this type before But that time I know that I cannot solve it yet
C. I have not seen this type before See the discussion below
Table 1.2: Problem Types (Compact Form)

17
In year 2009-2010, IOI had 8 tasks over 2 days with at least 1 (very) easy task per day. However, this
format is no longer continued in favor of eas(ier) subtask 1 of all tasks.

8
CHAPTER 1. INTRODUCTION c Steven, Felix, Suhendry

To be competitive, that is, do well in a programming contest, you must be able to confidently
and frequently classify problems as type A1 and minimize the number of problems that you
classify into type A2 or B. That is, you need to acquire sufficient algorithm knowledge and
develop your programming skills so that you consider many classical problems to be easy –
especially at the start of the contest.
However, to win a programming contest, you will also need to develop sharp problem
solving skills so that you (or your team) will be able to derive the required solution to a
hard/original type C problem in IOI or ICPC and do so within the duration of the contest,
not after the solution(s) is/are revealed by the problem author(s)/contest judge(s). Some of
the necessary problem solving skills are:
• Reducing the given problem into another (easier) problem,
• Reducing a known (NP-)hard problem into the given problem,
• Identifying subtle hints or special properties in the problem,
• Attacking the problem from a non-obvious angle/asking a di↵erent question,
• Compressing the input data,
• Reworking mathematical formulas,
• Listing observations/patterns,
• Performing case analysis of possible subcases of the problem, etc.

UVa/Kattis Title Problem Type Hint

wordcloud Word Cloud Section 1.6
turbo Turbo Section 2.4
10360 Rat Attack Complete Search or DP Section 3.2
hindex H-Index Section 3.3
11292 Dragon of Loowater Section 3.4
11450 Wedding Shopping Section 3.5
11512 GATTACA Book 2
10065 Useless Tile Packers Book 2
11506 Angry Programmer Book 2
bilateral Bilateral Projects Book 2
carpool Carpool Book 2

Table 1.3: Exercise: Read and Classify These UVa/Kattis Problems

Exercise 1.3.2.1: Read the UVa [44] and Kattis [34] problems in Table 1.3 and determine
their problem types. One of them has been identified for you. Filling this table should be
easy after mastering this book as all the techniques required to solve these problems are
discussed in this book.
Exercise 1.3.2.2*: Using the same list of problems shown in Table 1.3 above, please provide
the abridged versions of those problems in at most three sentences, omitting the irrelevant
details/storyline, but preserving the key points of the problems in such a way that another
competitive programmer who does not read the original problem descriptions can still write
correct solutions for those problems. See the first page of this book for an example!

9
1.3. TIPS TO BE COMPETITIVE c Steven, Felix, Suhendry

1.3.3 Tip 3: Do Algorithm Analysis

Once you have designed an algorithm to solve a particular problem in a programming contest,
you must then ask this question: Given the maximum input bound (usually given in a good
problem description), can the currently developed algorithm, with its time/space complexity,
pass the time/memory limit given for that particular problem?
Sometimes, there is more than one way to attack a problem. Some approaches may be
incorrect, others not fast enough, and yet others ‘overkill’. A good strategy is to brainstorm
for many possible algorithms and then pick the simplest solution that works (i.e., is fast
enough to pass the time and memory limit and yet still produce the correct answer)18 !
Modern computers are quite fast and can process19 up to ⇡ 100M (or 108 ; 1M =
1 000 000) operations in one second. You can use this information to determine if your
algorithm will run in time. For example, if the maximum input size n is 100K (or 105 ;
1K = 1000), and your current algorithm has a time complexity of O(n2 ), common sense (or
your calculator) will inform you that (100K)2 or 1010 is a very large number that indicates
that your algorithm will require (on the order of) hundreds of seconds to run. You will thus
need to devise a faster (and also correct) algorithm to solve the problem. Suppose you then
find one that runs with a time complexity of O(n log2 n). Now, your calculator will inform
you that 105 log2 105 is just 1.7 ⇥ 106 and common sense dictates that the algorithm (which
should now run in under a second) will likely be able to pass the time limit.
The problem bounds are as important20 as your algorithm’s time complexity in determin-
ing if your solution is appropriate. Suppose that you can only devise a relatively-simple-to-
code algorithm that runs with a horrendous time complexity of O(n4 ). This may appear to
be an infeasible solution, but if n  50, then you have actually solved the problem. You can
implement your O(n4 ) algorithm with impunity since 504 is just 6.25M and your algorithm
should still run in around a second.
Note, however, that the order of complexity does not necessarily indicate the actual num-
ber of operations that your algorithm will require. If each iteration involves a large number of
operations (many floating point calculations, or a significant number of constant sub-loops),
or if your implementation has a high ‘constant’ in its execution (unnecessary repeated loops,
multiple passes of the data set, or even Input/Output (I/O) execution overhead), your code
may take longer to execute than expected. However, this is usually not a big issue as the
problem authors should have designed the time limits so that a few (more than one) rea-
sonable implementations of the algorithm with the intended target time complexity will all
achieve the Accepted (AC) verdict.
By analyzing the complexity of your algorithm with the given input bound and the stated
time/memory limit, you can better decide whether you should attempt to implement your
algorithm (which will take up precious time in the IOIs and ICPCs), attempt to improve
your algorithm first, or switch to other problems in the problem set.
As mentioned in the preface of this book, we will not discuss the concept of algorithmic
analysis in details. We assume that you already have this basic skill. There are a multitude
of other reference books (for example, the “Introduction to Algorithms” [5], “Algorithm De-
sign” [35], “Algorithms” [6], etc) that will help you to understand the following prerequisite
concepts/techniques in algorithmic analysis:
18
Discussion: It is true that in programming contests, picking the simplest algorithm that works is crucial.
However, during training sessions without time constraint, it can be beneficial to spend more time trying
to solve a certain problem using the best possible algorithm. If we encounter a harder version of the problem
in the future, we will have a greater chance of obtaining and implementing the correct solution!
19
Treat this as a rule of thumb. These numbers may vary from machine to machine and likely increases
(a bit) over time. A competitive programmer will test these numbers during practice session.
20
If you are a problem author who read this book, please pay attention to bounds!

10
CHAPTER 1. INTRODUCTION c Steven, Felix, Suhendry

• Basic time and space complexity analysis for iterative and recursive algorithms:

– An algorithm with k-nested loops of about n iterations each has O(nk ) complexity.
– If your algorithm is recursive with b recursive calls per level and has L levels, the
algorithm has roughly O(bL ) complexity, but this is a only a rough upper bound.
The actual complexity depends on what actions are done per level and whether
pruning is possible.
– A Dynamic Programming algorithm or other iterative routine which processes a
2D n ⇥ n matrix in O(k) per cell runs in O(k ⇥ n2 ) time. This is explained in
further detail in Section 3.5.
– Binary searching over a range of [1..n] has O(log n) complexity.

• More advanced algorithm analysis techniques:

– Prove the correctness of an algorithm (especially for Greedy algorithms in Section

3.4), to minimize your chance of getting the ‘Wrong Answer’ verdict.
– Perform the amortized analysis (e.g., see Chapter 17 of [5])—although rarely
used in contests—to minimize your chance of getting the ‘Time Limit Exceeded’
verdict, or worse, considering your algorithm to be too slow and skipping the
problem when it is in fact fast enough in amortized sense.
– Do output-sensitive analysis to analyze algorithm which (also) depends on output
size and minimize your chance of getting the ‘Time Limit Exceeded’ verdict. For
example, the time complexity of partial sort algorithm is O(n log k). The time
taken for this algorithm to run depends not only on the input size n but also the
output size—the required k smallest (or largest) numbers to be sorted (see more
details in Section 2.3.1).

• Familiarity with these bounds:

– 210 = 1024 ⇡ 103 , 220 = 1 048 576 ⇡ 106 .
– 10! = 3 628 800 ⇡ 3 ⇤ 106 , 11! = 39 916 800 ⇡ 4 ⇤ 107 .
– 32-bit signed integers (int) and 64-bit signed integers (long long) have upper
limits of 231 1 ⇡ 2 ⇥ 109 (safe for up to ⇡ 9 decimal digits) and 263 1 ⇡ 9 ⇥ 1018
(safe for up to ⇡ 18 decimal digits), respectively.
– Unsigned integers can be used if only non-negative numbers are required. 32-bit
unsigned integers (unsigned int) and 64-bit unsigned integers (unsigned long
long) have upper limits of 232 1 ⇡ 4 ⇥ 109 and 264 1 ⇡ 1 ⇥ 1019 , respectively.
– If you need to store integers 264 , use Big Integer21 (see Section 2.2.4).
– There are n! permutations and 2n subsets (or combinations) of n distinct elements.
– The best time complexity of a comparison-based sorting algorithm is ⌦(n log2 n).
– The largest input size n for typical programming contest problems must be < 1M .
Beyond that, the Input/Output (I/O) routine will be the bottleneck.
– Usually, O(n log2 n) algorithms are sufficient to solve most contest problems for a
simple reason: O(n log2 n) and the theoretically better O(n) algorithms are hard
to di↵erentiate empirically under programming contest environment with strict
time limit, n < 1M , and the need to support > 1 programming languages.
21
gcc has built-in type int128 but this data type is rarely useful in competitive programming setting.

11
1.3. TIPS TO BE COMPETITIVE c Steven, Felix, Suhendry

Many novice programmers would skip this phase and immediately implement the first (naı̈ve)
algorithm that they can think of only to realize that the chosen data structure and/or
algorithm is/are not efficient enough (or wrong). Our advice for ICPC contestants22 : refrain
from coding until you are sure that your algorithm is both correct and fast enough.
To help you understand the growth of several common time complexities, and thus help
you judge how fast is ‘enough’, please refer to Table 1.4. Variants of such tables are also
found in many other books on data structures and algorithms. This table is written from
a programming contestant’s perspective. Usually, the input size constraints are given in a
(good) problem description. With the assumption that a typical year 2020 CPU can execute
a hundred million (108 ) operations in around 1 second23 (the typical time limit in most
UVa/Kattis problems [44, 34]), we can predict the ‘worst’ algorithm that can still pass the
time limit24 . Usually, the simplest algorithm has the poorest time complexity, but if it can
already pass the time limit, just use it!

n Worst AC Algorithm Comment

 [10..11] O(n!), O(n6 ) e.g., Enumerating permutations (Section 3.2)
 [17..19] O(2n ⇥ n2 ) e.g., DP TSP (Section 3.5.2)
 [18..22] O(2n ⇥ n) e.g., DP with bitmask technique (Book 2)
 [24..26] O(2n ) e.g., try 2n possibilities with O(1) check each
 100 O(n4 ) e.g., DP with 3 dimensions + O(n) loop, n Ck=4
 450 O(n3 ) e.g., Floyd-Warshall (Section 4.5)
 1.5K O(n2.5 ) e.g., Hopcroft-Karp (Book 2)
 2.5K O(n2 log n) e.g., 2-nested loops + a tree-related DS (Section 2.3)
 10K O(n2 ) e.g., Bubble/Selection/Insertion Sort (Section 2.2)
 200K O(n1.5 ) e.g., Square Root Decomposition (Book 2)
 4.5M O(n log n) e.g., Merge Sort (Section 2.2)
 10M O(n log log n) e.g., Sieve of Eratosthenes (Book 2)
 100M O(n), O(log n), O(1) Most contest problem have n  1M (I/O bottleneck)

Table 1.4: Rule of Thumb for the ‘Worst AC Algorithm’ for various single-test-case input
sizes n, assuming that a year 2020 CPU can compute 100M operations in 1 second.

From Table 1.4, we see the importance of using good algorithms with small orders of growth
as they allow us to solve problems with larger input sizes25 . But a faster algorithm is usually
non-trivial and sometimes substantially harder to implement. In Section 3.2.3, we discuss a
few tips that may allow the same class of algorithms to be used with larger input sizes. In
subsequent chapters, we also explain efficient algorithms for various computing problems.

22
Unlike ICPC, the IOI tasks can usually be solved (partially or fully) using several possible solutions,
each with di↵erent time complexities and subtask scores. To gain valuable points, it may be good to initialy
use a brute force solution to score a few points especially if it is easy/short to code and to understand the
problem better. There will be no significant time penalty as IOI is not a speed contest. Then, iteratively
improve the solution to gain more points.
23
In CP3, the previous assumption was 108 operations in 3s. Notice that CPU speed does not double
every one/two year(s) recently and Competitive Programming has not venture into multi-threading yet.
24
Try problem Kattis - tutorial *.
25
It will be hard for the programming contest judges to di↵erentiate fast or slow solutions automatically
when the highly variable I/O speed heavily influences the overall runtime speed measurements and hence
they will not set insanely large test cases (typically, n  1M ).

12
CHAPTER 1. INTRODUCTION c Steven, Felix, Suhendry

Exercise 1.3.3.1: Please answer the questions below using your current knowledge about
classic algorithms and their time complexities. After you have finished reading this book
once, it may be beneficial to attempt this exercise again.
1. There are n webpages (1  n  10M ). Page i has a page rank ri . A new page can
be added or an existing page can be removed frequently. You want to pick the current
top 10 pages with the highest page ranks, in order. Which method is better?
(a) Load all n webpages’ page rank to memory, sort (Section 2.2) them in descending
page rank order, and obtain the current top 10.
(b) Use a Priority Queue data structure (Section 2.3).
(c) Use the QuickSelect algorithm (Section 2.3.4).

2. Given a list L with 100K integers, you need to frequently obtain sum(i, j), i.e., the
sum of L[i] + L[i+1] + ...+ L[j]. Which data structure should you use?

(a) Simple Array pre-processed with Dynamic Programming (Section 2.2 & 3.5).
(b) Balanced Binary Search Tree (Section 2.3).
(c) Segment Tree (Section 2.4.4).
(d) Fenwick (Binary Indexed) Tree (Section 2.4.3).
(e) Suffix Tree or its alternative, Suffix Array (Book 2).

3. Given an M ⇥ N integer matrix Q (1  M, N  70), determine if there exists a sub-

matrix S of Q of size A ⇥ B (1  A  M, 1  B  N ) where mean(S) = 7. Which
algorithm will not exceed 100M operations per test case in the worst case?

(a) Try all possible sub-matrices and check if the mean of each sub-matrix is 7.
This algorithm runs in O(M 3 ⇥ N 3 ).
(b) Try all possible sub-matrices, but in O(M 2 ⇥ N 2 ) with this technique: .

4. Given a multiset S of M = 100K integers, we want to know how many di↵erent

integers that we can form if we pick two (not necessarily distinct) integers from S and
sum them. The content of multiset S is prime numbers not more than 20K. Which
algorithm will not exceed 100M operations per test case in the worst case?

(a) Try all possible O(M 2 ) pairs of integers and insert their sums into a hash table
(O(1) per insertion). Finally, report the final size of the hash table.
(b) Perform an algorithm as above, but after performing this technique: .

5. You have to compute the shortest path between two vertices on a weighted Directed
Acyclic Graph (DAG) with |V |, |E|  100K. Which algorithm(s) can be used?

(a) Dynamic Programming (Section 3.5, 4.2.6, & 4.6.1).

(b) Breadth First Search (Section 4.2.3 & 4.4.2).
(c) Dijkstra’s (Section 4.4.3).
(d) Bellman-Ford (Section 4.4.4).
(e) Floyd-Warshall (Section 4.5).

13
1.3. TIPS TO BE COMPETITIVE c Steven, Felix, Suhendry

6. Which algorithm produces a list of the first 10M prime numbers with the best time
complexity? (Book 2)

(a) Sieve of Eratosthenes.

(b) 8i 2 [1..10M ], if isPrime(i) is true, add i in the list.

7. How to test if the factorial of n, i.e., n! is divisible by an integer m? 1  n  1014 .

(a) Test if n! % m == 0.
(b) The naı̈ve approach above will not work, use: (Book 2).

8. You want to enumerate all occurrences of a substring P (of length m) in a (long)

string T (of length n), if any. Both n and m have a maximum of 1M characters.
Which algorithm is faster?
(a) Use the following C++ code snippet:
for (int i = 0; i < n-m; ++i) {
bool found = true;
for (int j = 0; (j < m) && found; ++j)
if ((i+j >= n) || (P[j] != T[i+j]))
found = false;
if (found)
printf("P is found at index %d in T\n", i);
}

(b) There are better algorithms, we can use: (Book 2).

9. Given a set S of N points scattered on a 2D plane (2  N  5 000), find two points

2 S that have the greatest separating Euclidean distance. Is an O(N 2 ) complete search
algorithm that tries all possible pairs feasible?

(a) Yes, such complete search is possible.

(b) No, we must find another way. We must use: .

10. See Question above, but now with a larger set of points: 2  N  200K and one
additional constraint: The points are randomly scattered on a 2D plane.

(a) The O(N 2 ) complete search can still be used.

(b) The naı̈ve approach above will not work, use: (Book 2).

11. See the same Question above. We still have a set of 2  N  200K points. But this
time there is no guarantee that the points are randomly scattered on a 2D plane.

(a) The O(n2 ) complete search can still be used.

(b) The better solution using algorithm in Book 2 can still be used.
(c) We need to use:

14
CHAPTER 1. INTRODUCTION c Steven, Felix, Suhendry

1.3.4 Tip 4: Master Programming Languages

There are several programming languages supported in ICPC26 , including C/C++, Java,
and Python. Which programming languages should one aim to master?
Our experience gives us this answer: we prefer C++ (std=gnu++17) with its built-in
Standard Template Library (STL) but we still need to master Java and some knowledge
of Python. Even though it is slower, Java has powerful built-in libraries and APIs such as
BigInteger/BigDecimal, GregorianCalendar, Regex, etc. Java programs are easier to debug
with the virtual machine’s ability to provide a stack trace when it crashes (as opposed to
core dumps or segmentation faults in C/C++). Similarly, Python code can be surprisingly
very short for some suitable tasks. On the other hand, C/C++ has its own merits as
well. Depending on the problem at hand, either language may be the better choice for
implementing a solution in the shortest time.
Suppose that a problem requires you to compute 40! (the factorial of 40). The answer is
very large: 815 915 283 247 897 734 345 611 269 596 115 894 272 000 000 000. This far exceeds
the largest built-in primitive integer data type (unsigned long long: 264 1). As there is
no built-in arbitrary-precision arithmetic library in C/C++ as of yet, we would have needed
to implement one from scratch. The Python code, however, is trivially short:

import math
print(math.factorial(40)) # all built-in

The Java code for this task is also simple (more details in Section 2.2.4):

import java.util.Scanner;
import java.math.BigInteger;
class Main { // default class name
public static void main(String[] args) {
BigInteger fac = BigInteger.ONE;
for (int i = 2; i <= 40; ++i)
fac = fac.multiply(BigInteger.valueOf(i)); // it is in the library!
System.out.println(fac);
}
}

Mastering and understanding the full capability of your favourite programming language is
also important. Take this problem with a non-standard input format: The first line of input
is an integer N . This is followed by N lines, each starting with the character ‘0’, followed
by a dot ‘.’, then followed by an unknown number of target digits (up to 100 digits), and
finally terminated with three dots ‘...’. Your task is to extract these target digits.

26
[This is a personal opinion]. In IOI 2019 competition rules, the programming languages allowed in IOI
are C++ and Java (two older programming languages: Pascal and C have been retired recently). The ICPC
World Finals 2019 (and thus most Regionals) allows C, C++, Java, and Python (partially) to be used in the
contest. Therefore, it seems that the ‘best’ language to master as of year 2020 is still C++ (std=gnu++17)
as it is supported in both competitions, a fast language, and has strong STL support. If IOI contestants
choose to master C++, they will have the benefit of being able to use the same language (with an increased
level of mastery) for ICPC in their University level pursuits. Note that OCaml is not currently used in the
IOI or ICPC.

15
Discovering Diverse Content Through
Random Scribd Documents
The Project Gutenberg eBook of Footprints of the
Red Men
This ebook is for the use of anyone anywhere in the United States and
most other parts of the world at no cost and with almost no restrictions
whatsoever. You may copy it, give it away or re-use it under the terms of
the Project Gutenberg License included with this ebook or online at
www.gutenberg.org. If you are not located in the United States, you will
have to check the laws of the country where you are located before
using this eBook.

Title: Footprints of the Red Men

Author: Edward Manning Ruttenber

Release date: February 14, 2016 [eBook #51217]

Most recently updated: October 23, 2024

Language: English

Credits: Produced by Roger Burch with scans provided by the Internet Archive.

*** START OF THE PROJECT GUTENBERG EBOOK FOOTPRINTS OF THE

RED MEN ***
FOOTPRINTS OF THE RED MEN.

Indian Geographical Names

IN THE VALLEY OF HUDSON'S

RIVER,
THE VALLEY OF THE MOHAWK,
AND ON THE DELAWARE:
THEIR LOCATION AND THE
PROBABLE
MEANING OF SOME OF THEM.

BY

E. M. RUTTENBER,
Author of "History of the Indian Tribes of Hudson's River."
 "Indian place-names are not proper names, that is unmeaning words, but
significant appellatives each conveying a description of the locality to which it
belongs."—Trumbull.

PUBLISHED UNDER THE AUSPICES

OF THE

New York State Historical Association.

 Copyrighted by the

NEW YORK STATE HISTORICAL ASSOCIATION.

1906.
{INDEX p. 237}
 Primary Explanations.

The locatives of the Indian geographical names which have been handed
down as the names of boundmarks or of places or tribes, are properly a subject
of study on the part of all who would be familiar with the aboriginal geography
of a district or a state. In many cases these names were quite as designative of
geographical centers as are the names of the towns, villages and cities which
have been substituted for them. In some cases they have been wisely retained,
while the specific places to which they belonged have been lost. In this work
special effort has been made, first, to ascertain the places to which the names
belonged as given in official records, to ascertain the physical features of those
places, and carry back the thought to the poetic period of our territorial history,
"when the original drapery in which nature was enveloped under the dominion
of the laws of vegetation, spread out in one vast, continuous interminable
forest," broken here and there by the opened patches of corn-lands and the
wigwams and villages of the redmen; secondly, to ascertain the meanings of the
aboriginal names, recognizing fully that, as Dr. Trumbull wrote, "They were not
proper names or mere unmeaning marks, but significant appellatives conveying
a description of the locatives to which they were given." Coming down to us in
the crude orthographies of traders and unlettered men, they are not readily
recognized in the orthographies of the educated missionaries, and especially are
they disguised by the varying powers of the German, the French, and the
English alphabets in which they were written by educated as well as by
uneducated scribes, and by traders who were certainly not very familiar with the
science of representing spoken sounds by letters. In one instance the same name
appears in forty-nine forms by different writers. Many names, however, have
been recognized under missionary standards and their meanings satisfactorily
ascertained, aided by the features of the localities to which they were applied;
the latter, indeed, contributing very largely to their interpretation. Probably the
reader will find geographical descriptions that do not apply to the places where
the name is now met. The early settlers made many transfers as well as
extensions of names from a specific place to a large district of country. It must
be remembered that original applications were specific to the places which they
described even though they were generic and applicable to any place where the
same features were referred to. The locatives in Indian deeds and original
patents are the only guide to places of original application, coupled with
descriptive features where they are known.

No vocabularies of the dialects spoken in the lower valley of the Hudson

having been preserved, the vocabularies of the Upper-Unami and the Minsi-
Lenape, or Delaware tongues on the south and west, and the Natick, or
Massachusetts, on the north and east, have been consulted for explanations by
comparative inductive methods, and also orthographies in other places, the
interpretations of which have been established by competent linguists. In all
cases where the meaning of terms has been particularly questioned, the best
expert authority has been consulted. While positive accuracy is not asserted in
any case, it is believed that in most cases the interpretations which have been
given may be accepted as substantially correct. There is no poetry in them—no
"glittering waterfalls," no "beautiful rivers," no "smile of the Great Spirit," no
"Holy place of sacred feasts and dances," but plain terms that have their
equivalents in our own language for a small hill, a high hill, a mountain, a
brook, a creek, a kill, a river, a pond, a lake, a swamp, a large stone, a place of
small stones, a split rock, a meadow, or whatever the objective feature may have
been as recognized by the Indian. Many of them were particular names in the
form of verbals indicating a place where the action of the verb was performed;
occasionally the name of a sachem is given as that of his place of residence or
the stream on which he resided, but all are from generic roots.

To the Algonquian dialects spoken in the valley of Hudson's River at the

time of the discovery, was added later the Mohawk—Iroquorian, to some extent,
more particularly on the north, where it appears about 1621-6, as indicated in
the blanket deed given by the Five Nations to King George in 1726.
Territorially, in the primary era of European invasion, the Eastern Algonquian
prevailed, in varying idioms, on both sides of the river, from a northern point to
the Katskills, and from thence south to the Highlands a type of the Unami-
Minsi-Lenape or Delaware. That spoken around New York on both sides of the
river, was classed by the early Dutch writers as Manhattan, as distinguished
from dialects in the Highlands and from the Savano or dialects of the East New
England coast. North of the Highlands on both sides of the river, they classed
the dialect as Wapping, and from the Katskills north as Mahican or Mohegan,
preserved in part in what is known as the Stockbridge. Presumably the dialects
were more or less mixed and formed as a whole what may be termed "The
Hudson's River Dialect," radically Lenape or Delaware, as noted by Governor
Tryon in 1774. In local names we seem to meet the Upper-Unami and the Minsi
of New Jersey, and the Mohegan and the Natick of the north and east, the
Quiripi of the Sound, and the dialect of the Connecticut Valley. In the belt of
country south of the Katskills they were soft and vocalic, the lingual mute t
frequently appearing and r taking the place of the Eastern l and n. In the Minsi
(Del.) Zeisberger wrote l invariably, as distinguished from r, which appears in
the earliest local names in the valley of the Hudson. Other dialectic peculiarities
seem to appear in the exchange of the sonant g for the hard sound of the surd
mute k, and of p for g, s for g, and t for d, st for gk, etc. Initials are badly mixed,
presumably due in part at least, to the habit of Indian speakers in throwing the
sound of the word forward to the penult; in some cases to the lack of an "Indian
ear" on the part of the hearer.

In structure all Algonquian dialects are Polysynthetic, i. e., words

composed wholly or in part of other words or generic roots. Pronunciations and
inflections differ as do the words in meaning in many cases. In all dialects the
most simple combinations appear in geographical names, which the late Dr. J.
H. Trumbull resolved into three classes, viz.: "I. Those formed by the union of
two elements, which we will call adjectival and substantival, or ground-word,
with or without a locative suffix, or post-position word meaning 'at,' 'in,' 'on,'
'near,' etc. [I use the terms 'adjectival' and 'substantival,' because no true
adjectives or substantives enter into the composition of Algonquian names. The
adjectival may be an adverb or a preposition; the substantival element is often a
verbal, which serves in composition as a generic name, but which cannot be
used as an independent word—the synthesis always retains the verbal form.] II.
Those which have a single element, the substantival, or ground-word, with
locative suffix. III. Those formed from verbs as participials or verbal nouns,
denoting a place where the action of the verb is performed. Most of these latter,
however," he adds, "may be shown by strict analysis to belong to one of the two
preceding classes, which comprise at least nine-tenths of all Algonquian local
names which have been preserved." For example, in Class I, Wapan-aki is a
combination of Wapan, "the Orient," "the East," and aki, "Land, place or
country," unlimited; with locative suffix (-ng, Del., -it, Mass.), "In the East Land
or Country." Kit-ann-ing, Del., is a composition from Kitschi, "Chief, principal,
greatest," hanné, "river," and ing locative, and reads, "A place at or on the
largest river." The suffix -aki, -acki, -hacki, Del., meaning "Land, place, or
country, unlimited," in Eastern orthographies -ohke, -auke, -ague, -ke, -ki, etc.,
is changed to -kamik, or -kamike, Del., -kamuk or -komuk, Mass., in describing
"Land or place limited," or enclosed, a particular place, as a field, garden, and
also used for house, thicket, etc. The Eastern post-position locatives are -it, -et, -
at, -ut; the Delaware, -ng, -nk, with connecting vowel -ing, -ink, -ong, -onk, -
ung, -unk, etc. The meaning of this class of suffixes is the same; they locate a
place or object that is at, in, or on some other place or object, the name of
Which is prefixed, as in Delaware Hitgunk, "On or to a tree;" Utenink, "In the
town;" Wachtschunk, "On the mountain." In some cases the locative takes the
verbal form indicating place or country, Williams wrote "Sachimauónck, a
Kingdom or Monarchy." Dr. Schoolcraft wrote: "From Ojibwai (Chippeway) is
formed Ojib-wain-ong, 'Place of the Chippeways;' Monominikaun-ing, 'In the
place of wild rice,'" Dr. Brinton wrote "Walum-ink, 'The place of paint.'" The
letter s, preceding the locative, changes the meaning of the latter to near, or
something less than at or on. The suffixes -is, -it, -os, -es mean "Small," as in
Ménates or Ménatit, "Small island." The locative affix cannot be applied to an
animal in the sense of at, in, on, to. There are many formative inflections and
suffixes indicating the plural, etc.

Mohawk or Iroquoian names, while polysynthetic, differ from Algonquian

in construction. "The adjective," wrote Horatio Hale, "when employed in an
isolated form, follows the substantive, as Kanonsa, 'house;' Kanonsa-kowa,
'large house;' but in general the substantive and adjective coalesce." In some
cases the adjective is split in two, and the substantive inserted, as in Tiogen, a
composition of Te, "two," and ogen, "to separate," which is split and the word
ononté, "mountain," or hill, inserted, forming Te-ononté-ogen, "Between two
mountains," "The local relations of nouns are expressed by affixed particles,
such as ke, ne, kon, akon, akta. Thus from Onónta, mountain, we have
Onóntáke, at (or to) the mountain; from Akéhrat dish, Akehrátne, in or on the
dish," etc. From the variety of its forms and combinations it is a more difficult
language than the Algonquian. No European has fully mastered it.

No attempt has been made to correct record orthographies further than to

give their probable missionary equivalents where they can be recognized. In
many cases crude orthographies have converted them into unknown tongues.
Imperfect as many of them are and without standing in aboriginal glossaries,
they have become place names that may not be disturbed. No two of the early
scribes expressed the sound of the same name in precisely the same letters, and
even the missionaries who gave attention to the study of the aboriginal tongues,
did not always write twice alike. Original sounds cannot now be restored. The
diacritical marks employed by Williams and Eliot in the English alphabet, and
by Zeisberger and Heckewelder in the German alphabet, are helpful in
pronunciations, but as a rule the corrupt local record orthographies are a law
unto themselves. In quoting diacritical marks the forms of the learned linguists
who gave their idea of how the word was pronounced, have been followed. It is
not, however, in the power of diacritical marks or of any European alphabet to
express correctly the sound of an Algonquian or of an Iroquoian word as it was
originally spoken, or write it in European characters. Practically, every essential
element in pronunciation is secured by separating the forms into words or parts
of words, or particles, of which it is composed, (where the original elements of
the composition cannot be detected) by syllabalizing on the vowel sounds. An
anglicized vocalism of any name may be readily established and an original
name formed in American nomenclature, as many names in current use amply
illustrates. Few would suspect that Ochsechraga (Mohawk) was the original of
Saratoga, or that P'tuk-sepo (Lenape) was the original of Tuxedo.

A considerable number of record names have been included that are not
living. They serve to illustrate the dialect spoken in the valley as handed down
by European scribes of different languages, as well as the local geography of the
Indians. The earlier forms are mainly Dutch notations. A few Dutch names that
are regarded by some as Indian, have been noticed, and also some Indian names
on the Delaware River which, from the associations of that river with the history
of the State, as in part one of its boundary streams, as well as the intimate
associations of the names with the history of the valley of Hudson's River,
become of especial interest.

In the arrangement of names geographical association has been adopted in

preference to the alphabetical, the latter being supplied by index. This
arrangement seems to bring together dialectic groups more satisfactorily. That
there were many variations in the dialects spoken in the valley of Hudson's
River no one will deny, but it may be asserted with confidence that the
difference between the German and the English alphabets in renderings is more
marked than differences in dialects. In so far as the names have been brought
together they form the only key to the dialects which were spoken in the valley.
Their grammatical treatment is the work of skilled philologists.

Credit has been given for interpretations where the authors were known,
and especially to the late eminent Algonquian authority, J. Hammond Trumbull.
Special acknowledgment of valuable assistance is made to the late Dr. D. G.
Brinton, of Philadelphia; to the late Horatio Hale, M. A., of Clinton, Ontario,
Canada; to the late Prof. J. W. Powell, of the Bureau of Ethnology, Washington,
D. C, and his successor, William H. Holmes, and their co-laborers, Dr. Albert S.
Gatschet and J. B. N. Hewitt, and to Mr. William R. Gerard, of New York.

The compilation of names and the ascertaining of their locatives and

probable meanings has interested me. Where those names have been preserved
in place they are certain descriptive landmarks above all others. The results of
my amateur labors may be useful to others in the same field of inquiry as well
as to professional linguists. Primarily the work was not undertaken with a view
to publication. Gentlemen of the New York Historical Association, with a view
to preserve what has been done, and which may never be again undertaken,
have asked the manuscript for publication, and it has been given to them for that
purpose.

E. M. RUTTENBER.

Newburgh, January, 1906.

 INDIAN GEOGRAPHICAL NAMES.

Hudson's River and Its Islands.

Muhheakun'nuk, "The great waters or sea, which are constantly in

motion, either ebbing or flowing," was written by Chief Hendrick Aupaumut, in
his history of the Muhheakun'nuk nation, as the name of Hudson's River, in the
Stockbridge dialect, and its meaning. The first word, Muhheakun, was the
national name of the people occupying both banks of the river from Roelof
Jansen's Kill, a few miles south of Catskill, on the east side of the river, north
and east with limit not known, and the second -nuk, the equivalent of
Massachusetts -tuk, Lenape -ittuk, "Tidal river, or estuary," or "Waters driven by
waves or tides," with the accessory meaning of "great." Literally, in application,
"The great tidal river of the Muhheakan'neuw nation." The Dutch wrote the
national name Mahikan, Maikan, etc., and the English of Connecticut wrote
Mohegan, which was claimed by Drs. Schoolcraft and Trumbull to be derived
from Maingan (Cree Mahéggun), "Wolf"—"an enchanted wolf, or a wolf of
supernatural powers." From their prevailing totem or prevailing coat-of-arms,
the Wolf, the French called them Loups, "wolves," and also Manhingans,
including under the names "The nine nations gathered between Manhattan and
Quebec." While the name is generic its application to Hudson's River was
probably confined to the vicinity of Albany, where Chief Aupaumut located
their ancient capital under the name of Pem-po-tow-wut-hut Muh-hea-kan-
neuw, "The fire-place of the Muh-hea-kan-nuk nation." [FN] The Dutch found
them on both sides of the river north of Catskill, with extended northern and
eastern alliances, and south of that point, on the east side of the river, in alliance
with a tribe known as Wappans or Wappings, Wappani, or "East-side people,"
the two nations forming the Mahikan nation of Hudson's River as known in
history. (See Wahamensing.)

[FN] Presumed to have been at what is now known as Scho-lac, which see.
 Father Jogues, the French-Jesuit martyr-missionary, wrote in 1646, Oi-o-
gué as the Huron-Iroquoian name of the river, given to him at Sarachtoga, with
the connection "At the river." "Ohioge, river; Ohioge-son, at the long river,"
wrote Bruyas. Arent van Curler wrote the same name, in 1634, Vyoge, and gave
it as that of the Mohawk River, correcting the orthography, in his vocabulary, to
"Oyoghi, a kill" or channel. It is an Iroquoian generic applicable to any principal
stream or current river, with the ancient related meaning of "beautiful river."

It is said that the Mohawks called the river Cohohataton. I have not met
that name in records. It was quoted by Dr. Schoolcraft as traditional, and of
course doubtful. He wrote it Kohatatea, and in another connection wrote "-atea,
a valley or landscape." It is suspected that he coined the name, as he did many
others. Shate-muck is quoted as a Mohegan [FN-1] name, but on very obscure
evidence, although it may have been the name of an eel fishing-place, or a great
fishing-place (-amaug). Hudson called the stream "The River of the
Mountains." On some ancient maps it is called "Manhattans River." The Dutch
authorities christened it "Mauritus' River" in honor of their Staat-holder, Prince
Maurice. The English recognized the work of the explorer by conferring the title
"Hudson's River." It is a fact established that Verrazano visited New York harbor
in 1524, and gave to the river the name "Riviere Grande," or Great River; that
Estevan Gomez, a Spanish navigator who followed Verrazano in 1525, called it
"St. Anthony's River," a name now preserved as that of one of the hills of the
Highlands, and it is claimed that French traders visited the river, in 1540, and
established a château on Castle [FN-2] Island, at Albany, [FN-3] and called the
river "Norumbega." It may be conceded that possibly French traders did have a
post on Castle Island, but "Norumbega" was obviously conferred on a wide
district of country. It is an Abnaki term and belonged to the dialect spoken in
Maine, where it became more or less familiar to French traders as early as 1535.
That those traders did locate trading posts on the Penobscot, and that Champlain
searched for their remains in 1604, are facts of record. The name means "Quiet"
or "Still Water." It would probably be applicable to that section of Hudson's
River known as "Stillwater," north of Albany, but the evidence is wanted that it
was so applied. Had it been applied by the tribes to any place on Hudson's
River, it would have remained as certainly as Menaté remained at New York.
[FN-1] "Mohegans is an anglicism primarily applied to the small band of Pequots under
Uncas." (Trumbull.) While of the same linguistic stock, neither the name or the history of
Uncas's clan should be confused with that of the Mahicani of Hudson's River.

[FN-2] Introduced by the Dutch—Kasteel. The Indians had no such word. The Delawares
called a house or hut or a town that was palisaded, Moenach, and Zeisberger used the same
word for "fence"—an enclosure palisaded around. Eliot wrote Wonkonous, "fort."

[FN-3] It is claimed that the walls of this fort were found by Hendrick Christiansen, in
1614; that they were measured by him and found to cover an area of 58 feet; that the fort
was restored by the Dutch and occupied by them until they were driven out by a freshet,
occasioned by the breaking up of the ice in the river in the spring of 1617; that the Dutch
then built what was subsequently known as Fort Orange, at the mouth of the Tawalsentha,
or Norman's Kill, about two miles south of the present State street, Albany, and that Castle
Island took that name from the French château—all of which is possible, but for conclusive
reasons why it should not be credited, the student may consult "Norumbega" in Winsor's
"Narrative and Critical History of America." Wrote Dr. Trumbull: "Theuet, in La
Cosmographie Universella, gives an account of his visit, in 1656, to 'one of the finest rivers
in the whole world, which we call Norumbeque, and the aboriginees Agoncy,' now
Penobscot Bay."
 Manhattan, now so written, does not appear in the Journal of Hudson's
exploration of the river in 1609. On a Spanish-English map of 1610, "Made for
James I," and sent to Philip III by Velasco in letter of March 22, 1611, [FN-1]
Mannahatin is written as the name of the east side of the river, and Mannahata
as that of the west side. From the former Manhattan, and from it also the name
of the Indians "among whom" the Dutch made settlement in 1623-4, otherwise
known by the general name of Wickquaskecks, as well as the name of the entire
Dutch possessions. [FN-2] Presumably the entries on the Spanish-English map
were copied from Hudson's chart, for which there was ample time after his
return to England. Possibly they may have been copied by Hudson, who wrote
that his voyage "had been suggested" by some "letters and maps" which "had
been sent to him" by Capt. Smith from Virginia. Evidently the notations are
English, and evidently, also, Hudson, or his mate, Juet, had a chart from his own
tracing or from that of a previous explorer, which he forwarded to his
employers, or of which they had a copy, when he wrote in his Journal: "On that
side of the river called Mannahata," as a reference by which his employers
could identify the side of the river on which the Half-Moon anchored, [FN-3]
Presumably the chart was drawn by Hudson and forwarded with his report, and
that to him belongs the honor of reducing to an orthographic form the first
aboriginal name of record on the river which now bears his name. Five years
after Hudson's advent Adriaen Block wrote Manhates as the name of what is
now New York Island, and later, De Vries wrote Manates as the name of Staten
Island, both forms having the same meaning, i. e., "Small island." There have
been several interpretations of Mannahatin, the most analytical and most
generally accepted being by the late Dr. J. H. Trumbull: "From Menatey (Del.),
'Island'—Mannahata 'The Island,' the reference being to the main land or to
Long Island as the large island. Menatan (Hudson's Mannah-atin, -an or -in, the
indefinite or diminutive form), 'The small island,' or the smaller of the two
principal islands, the Manhates of Adriaen Block. [FN-4] Manáhtons, 'People of
the Island,' Manáhatanesen, 'People of the small islands.'" [FN-5] The Eastern-
Algonquian word for "Island" (English notation), is written Munnoh, with
formative -an (Mun-nohan). It appears of record, occasionally, in the vicinity of
New York, presumably introduced by interpreters or English scribes. The usual
form is the Lenape Menaté, Chippeway Minnis, "Small island," classed also as
Old Algonquian, or generic, may be met in the valley of the Hudson, but the
instances are not clear. It is simply a dialectic equivalent of Del. Ménates. (See
Monach'nong.) Van Curler wrote in his Mohawk vocabulary (1635), "Kanon-
newaga, Manhattan Island." The late J. W. Powell, Director of the Bureau of
Ethnology, wrote me: "In the alphabet of this office the name may be
transliterated Kanoñnò'ge. It signifies 'Place of Reeds.'" Perhaps what was
known as the "Reed Valley" was referred to, near which Van Twiller had a
tobacco plantation where the Indians of all nations came to trade. (See
Saponickan.) The lower part of the island was probably more or less a district of
reed swamps.

[FN-1] Brown's "Genesis of the United States," 327, 457, 459, ii, 80.

[FN-2] Colonial History of New York.

[FN-3] Hudson anchored in the bay near Hoboken. Near by his anchorage he noticed that
"there was a cliff that looked of the color of white green." This cliff is near Elysian Fields
at Hoboken. (Broadhead.) The cliff is now known as Castle Point.

[FN-4] The reference to Adriaen Block is presumably to the "Carte Figurative" of 1614-16,
now regarded as from Block's chart.

[FN-5] "Composition of Indian Geographical Names," p. 22.

Pagganck, so written in Indian deed of 1637, as the name of Governor's

Island—Peconuc, Denton, is an equivalent of Pagán'nak, meaning literally "Nut
Island." Also written Pachgan, as in Pachganunschi, "White walnut trees."
(Zeisb.) Denton explained, "Because excellent nut trees grew there." [FN] The
Dutch called it "der Nooten Eilandt," literally "The Walnut Island," from
whence the modern name, "Nutten Island." The island was purchased from the
Indian owners by Director Wouter van Twiller, from whose occupation, and its
subsequent use as a demense of the governors of the Province, its present name.

[FN] Denton's "Description of New York," p. 29. Ward's and Blackwell's islands were sold
to the Dutch by the Marechawicks, of Long Island, in 1636-7. Governor's Island was sold
in the same year by the Tappans, Hackinsacks and Nyacks, the grantors signing themselves
as "hereditary owners." Later deeds were signed by chiefs of the Raritans and Hackinsacks.
 Minnisais is not a record name. It was conferred on Bedloe's Island by Dr.
Schoolcraft from the Ojibwe or Chippeway dialect, [FN] in which it means
"Small island."

[FN] The Objibwe (Objibwai) were a nation of three tribes living northwest of the great
lakes, of which the Ojibwai or Chippeway represented the Eagle totem. It is claimed by
some writers that their language stands at the head of the Algonquian tongues. This claim is
disputed on behalf of the Cree, the Shawanoe, and the Lenape or Delaware. It is not
assumed that Ojibwe (Chippeway) terms are not Algonquian, but that they do not strictly
belong to the dialects of the Hudson's river families. Rev. Heckewelder saw no particular
difference between the Ojibwe and the Lenape except in the French and the English forms.
Ojibwe terms may always be quoted in explanations of the Lenape.

Kiosh, or "Gull Island," was conferred on Ellis Island by Dr. Schoolcraft

from the Ojibwe dialect. The interpretation is correct presumably.

Tenkenas is of record as the Indian name of what is now known as Ward's

Island. [FN] It appears in deed of 1636-7. It means "Small island," from Tenke
(Len.), "little."

[FN] The Dutch called the island Onvruchtbaar, "Unfruitful, barren." The English adopted
the signification, "Barren," which soon became corrupted to "Barrent's," to which was
added "Great" to distinguish it from Randal's Island, which was called "Little Barrent's
Island." Barn Island is another corruption. Both islands were "barren" no doubt.

Monatun was conferred by Dr. Schoolcraft on the whirlpool off Hallet's

Cove, with the explanation, "A word conveying in its multiplied forms the
various meanings of violent, forcible, dangerous, etc." Dr. Schoolcraft
introduced the word as the derivative of Manhatan, which, however, is very far
from being explained by it. Hell-gate, a vulgar orthography of Dutch Hellegat,
has long been the popular name of the place. It was conferred by Adriaen Block,
in 1614-16, to the dangerous strait known as the East River, from a strait in
Zealand, which, presumably, was so called from Greek Helle, as heard in
Hellespont—"Sea of Helle"—now known as the Dardanelles—which received