01 Start here
Core Learn the low-friction patterns first: monotone search, prefix preprocessing, window scans, and basic traversal.
Binary Search, Prefix Sums and Difference Arrays, Two Pointers and Sliding Window, BFS and DFS
Overview
These notes are the part of the competitive programming archive that is not tied to one contest year. The goal is simple: keep the ideas that I actually want to reuse in a form that is still readable after the adrenaline of the original contest is gone.
I care about three things here:
the structural reason an algorithm or data structure works,
the implementation shape I would still trust in contest code,
the failure modes that usually cause wrong answers or wasted time.
How the Notes Are Written
Each topic keeps note.tex as the written source of truth and code.cpp as the implementation source of truth. The site renders the TeX into HTML and shows the C++ file separately, so the prose can stay focused while the code remains directly copyable.
The finished notes are meant to be public-facing study material, not private scraps. That means the emphasis is on explanations, invariants, use cases, and pitfalls instead of dumping templates with no context.
Recommended Learning Path
If I were revising this section from scratch, I would split it into a few routes instead of pretending there is one universal order:
core first: binary search, prefix sums, sliding window, coordinate compression, Fenwick tree, BFS / DFS,
graph path: topological sort, Dijkstra, MST, SCC, Euler tour, LCA, tree decompositions,
DP optimization path: knapsack, tree DP, monotone queue, divide-and-conquer DP, Knuth, convex hull trick, rerooting,
advanced data structures: segment tree, sparse table, ordered set, Li Chao tree, persistent segment tree, rollback DSU,
number theory path: extended Euclid, modular arithmetic, CRT, sieve, Mobius, Miller-Rabin, discrete log.
That is still not the only valid order, but it is closer to how I actually revise: pick a branch, stay inside it long enough for the invariants to become familiar, then switch.
What ``Finished'' Means Here
A finished note should answer the questions I usually care about when revising:
What kind of contest situation makes this the right tool?
What invariant is doing the real work?
Which implementation shape is the least fragile under time pressure?
Which edge cases usually break the first version?
What does a worked contest-style example actually look like?
Some topics are still only planned. They are listed openly as planned instead of pretending that a shallow page is enough.
References Behind the Section
The explanations are rewritten in my own words, but the topic map and many implementation choices were informed by: