Suffix Trees & String Processing

Lecture 13's tries answered "is this exact word stored?" against a dictionary of many words. Today's question is different: given one long text T, answer things like "does pattern P occur anywhere in T?", "what's the longest substring that repeats?", "what's the longest stretch shared by two texts?" — over and over, cheaply, without rescanning T each time.

Key trick: every substring of T is a prefix of some suffix of T. So if you store every suffix of T in a trie, answering "does P occur in T?" becomes exactly a prefix search — an operation you already know cold from Lecture 13.

Take T = "banana", append a unique terminal character $ (smaller than every real character, and appearing nowhere else) to get "banana$" — this guarantees no suffix is ever a prefix of another, so every suffix gets its own distinct leaf. List its 7 suffixes:

banana$, anana$, nana$, ana$, na$, a$, $

Insert all 7 into a trie exactly as in Lecture 13. This structure is called a suffix trie. We'll build it in a few minutes — but first, a serious problem with it.

String "a" repeated m times (aaaa…a): every suffix is a shorter run of a's — the trie is a single chain. Node count: 2m + 2 — linear in m.

String aⁿbⁿ (say n a's then n b's, so m = 2n): now there are n distinct "a-chains" (one per suffix starting inside the a-run), each needing its own trailing "b-chain" of length up to n. Node count: n² + 4n + 2 — quadratic in n, i.e. quadratic in m.

In the worst case: the trie's depth (top to bottom) is at most m + 1 — the length of the longest suffix. Its width (how many distinct substrings exist at any one length) can itself be as large as m. Depth × width gives an upper bound of O(m²) nodes — and aⁿbⁿ shows this bound is actually achieved, not just a loose estimate.

For a genome-length text (m in the millions), an O(m²)-space structure is unusable. We need the same lookup power in guaranteed O(m) space — that requirement is exactly what a suffix tree is built to satisfy.

Both formulas on the last slide use m — but m by itself doesn't fix the tree's size. What actually decides it is how much the string's own suffixes overlap with each other. Fix m = 4 and compare two genuinely different strings of that exact length.

"aaaa$" — repeated-character family, m = 4 — against "aabb$" — the aⁿbⁿ family with n = 2, so m = 2n = 4. Same length. Watch what happens to the node count.

aaaa$, aaa$, aa$, a$, $ — every suffix is a prefix of a longer one, so all 5 sit on one spine, each just peeling off its own "$" leaf. 2(4) + 2 = 10 nodes.

aabb$, abb$, bb$, b$, $ — the two suffixes starting inside the a-run share only their first "a", then diverge, and each needs its own unshared b-tail. 2² + 4(2) + 2 = 14 nodes.

Take the suffix trie and find every maximal chain of nodes with exactly one child (nodes that carry no real branching decision). Collapse each such chain into a single edge. That edge is labeled with a (start, end) index pair into the original text T — never a copy of the substring itself.

• Exactly m leaves for a text of length m (one per suffix, guaranteed distinct by the terminal $).
• Fewer than m internal branching nodes (excluding the root) — every internal node has ≥ 2 children.
• Total space: O(m) — always, not just on average. This is the structure called a suffix tree.

• Guaranteed O(m) space — no worst-case blow-up, unlike the raw suffix trie.
• O(p) exact pattern search for any pattern of length p, after one O(m) preprocessing pass over T.
• One structure answers many different string questions — pattern matching, longest repeated substring, longest common substring of two texts, and more — all in time proportional to the answer, not to rescanning T.

• Construction is intricate. The naive "insert every suffix, then compress" approach we're about to animate costs roughly O(m²) work. A genuinely linear O(m) build is possible, but the algorithm that achieves it is notoriously fiddly to implement without bugs — well beyond what this course derives by hand.
• Real-world overhead. Each node/edge carries pointers and index pairs — the constant factor per character is larger than a simpler alternative, the suffix array (a sorted array of suffix start-positions plus an LCP array), which is more cache-friendly and is often preferred in production systems despite similar asymptotic guarantees.

Every node with exactly one child and no branching decision gets merged into the edge above it. Leaves keep their identity (they're labeled here with the starting position of their suffix — standard suffix-tree convention); only the pure "pass-through" nodes disappear.

Every edge now carries a full substring label (shown as a small tag on the connecting line) instead of one character. Internal node boxes show the string spelled out from the root to that point — this is exactly the "string-depth" you'll need for the next two animations.

• start[c] never moved. Not one slot. An edge always begins where it always began — merging only makes it run further.
• Only child[c] and end[c] were written. Take the child's end, repoint past the child, free it. Two writes per merge, no matter how long the chain was.
• "reads as" is not stored. It's computed as T[start..end] whenever the characters are actually needed. There is no fourth array.

Slot $ already pointed straight at a leaf — no chain beneath it to collapse. Slot a pointed at a node that branches immediately (into "$" and "n"), so it carries a real decision and must survive. Only b and n sat above non-branching runs, so only those two slots were touched — exactly the two merges you watched in the animation.

Walk from the root, matching the pattern character-by-character against edge labels. Three things can happen: you land exactly on an internal node (pattern occurs — once per leaf below that node); you stop partway along an edge having matched the whole pattern (pattern occurs exactly once — wherever that edge's leaf says); or you hit a mismatch (pattern does not occur at all).

Search "ana" — lands exactly on an internal node. Search "ban" — matches fully, but stops partway along one edge. Search "bant" — fails partway along that same edge.

Given one text T, find the longest string that appears in it at least twice. Not two different texts — one text, comparing it against itself.

For banana, work through the candidates: "a" appears 3× (positions 2, 4, 6). "an" and "na" each appear 2×. "ana" appears 2× — at positions 2 and 4. But "anan" appears only once, and so does "nana". So the answer is "ana", length 3.

Those two copies of "ana" overlap: the first covers positions 2–4, the second covers 4–6, and they share position 4. That still counts as repeating twice.

Why it matters in practice: repeated blocks are what compression algorithms hunt for, what plagiarism detectors flag, and what biologists look for as repeated motifs in a genome.

Append a different unique terminator to each text (say # to S1, $ to S2), then build one suffix tree over the concatenation of both. Label every leaf with which text its suffix came from.

The longest common substring of S1 and S2 is then the deepest internal node whose subtree contains at least one leaf from each text — exactly the same "deepest internal node" idea as longest repeated substring, just with an extra bookkeeping condition.

S1 = abczz, S2 = xyabc. Checking every possible common substring by hand: single characters a, b, c are common; two-character "ab" and "bc" are common; the three-character "abc" is common (S1 positions 1–3, S2 positions 3–5); no four-character substring matches (S1's 4-grams are "abcz","bczz"; S2's are "xyab","yabc" — no overlap).

Longest common substring = "abc", length 3 — found at the deepest node with leaves tagged from both S1 and S2 beneath it.