Generalized suffix tree

Generalized suffix treeMain

Community hub

8 pages, 0 posts

0 subscribers

Recent from talks

Be the first to start a discussion here.

Recent from talks

Be the first to start a discussion here.

Contribute something

About hubMembersContent overviewUpdatesRules

Main reference articles

Generalized suffix tree

View on Wikipedia

from Wikipedia

In computer science, a generalized suffix tree is a suffix tree for a set of strings. Given the set of strings $D=S_{1},S_{2},\dots ,S_{d}$ of total length $n$ , it is a Patricia tree containing all $n$ suffixes of the strings. It is mostly used in bioinformatics.^[1]

Functionality

[edit]

It can be built in $\Theta (n)$ time and space, and can be used to find all $z$ occurrences of a string $P$ of length $m$ in $O(m+z)$ time, which is asymptotically optimal (assuming the size of the alphabet is constant^[2]^: 119).

When constructing such a tree, each string should be padded with a unique out-of-alphabet marker symbol (or string) to ensure no suffix is a substring of another, guaranteeing each suffix is represented by a unique leaf node.

Algorithms for constructing a GST include Ukkonen's algorithm (1995) and McCreight's algorithm (1976).

Example

[edit]

A suffix tree for the strings ABAB and BABA is shown in a figure above. They are padded with the unique terminator strings $0 and $1. The numbers in the leaf nodes are string number and starting position. Notice how a left to right traversal of the leaf nodes corresponds to the sorted order of the suffixes. The terminators might be strings or unique single symbols. Edges on $ from the root are left out in this example.

Alternatives

[edit]

An alternative to building a generalized suffix tree is to concatenate the strings, and build a regular suffix tree or suffix array for the resulting string. When hits are evaluated after a search, global positions are mapped into documents and local positions with some algorithm and/or data structure, such as a binary search in the starting/ending positions of the documents.

References

[edit]

^ Paul Bieganski; John Riedl; John Carlis; Ernest F. Retzel (1994). "Generalized Suffix Trees for Biological Sequence Data". Biotechnology Computing, Proceedings of the Twenty-Seventh Hawaii International Conference on. pp. 35–44. doi:10.1109/HICSS.1994.323593.
^ Gusfield, Dan (1999) [1997]. Algorithms on Strings, Trees and Sequences: Computer Science and Computational Biology. USA: Cambridge University Press. ISBN 978-0-521-58519-4.

External links

[edit]

Media related to Generalized suffix tree at Wikimedia Commons
A C implementation of Generalized Suffix Tree for two strings

v t e Strings
String metric	Approximate string matching Bitap algorithm Damerau–Levenshtein distance Edit distance Gestalt pattern matching Hamming distance Jaro–Winkler distance Lee distance Levenshtein automaton Levenshtein distance Wagner–Fischer algorithm
String-searching algorithm	Apostolico–Giancarlo algorithm Boyer–Moore string-search algorithm Boyer–Moore–Horspool algorithm Knuth–Morris–Pratt algorithm Rabin–Karp algorithm Raita algorithm Trigram search Two-way string-matching algorithm Zhu–Takaoka string matching algorithm
Multiple string searching	Aho–Corasick Commentz-Walter algorithm
Regular expression	Comparison of regular-expression engines Regular grammar Thompson's construction Nondeterministic finite automaton
Sequence alignment	BLAST Hirschberg's algorithm Needleman–Wunsch algorithm Smith–Waterman algorithm
Data structure	DAFSA Substring index Suffix array Suffix automaton Suffix tree Compressed suffix array LCP array FM-index Generalized suffix tree Rope Ternary search tree Trie
Other	Parsing Pattern matching Compressed pattern matching Longest common subsequence Longest common substring Sequential pattern mining Sorting String rewriting systems String operations

Revisions and contributors Edit on Wikipedia Read on Wikipedia

View on Grokipedia

from Grokipedia

A generalized suffix tree (GST) is a compressed trie data structure that represents all suffixes from a collection of multiple strings, typically constructed by appending unique terminal symbols to each string to distinguish their suffixes and prevent cross-string prefix overlaps.^[1] This extension of the single-string suffix tree enables efficient processing of multi-string problems, such as finding the longest common substring across the input set in linear time relative to the total length of the strings.^[2] Developed as a natural generalization of the suffix tree introduced by Peter Weiner in 1973 and refined for linear-time construction by Esko Ukkonen in 1995, the GST addresses challenges in indexing multiple texts by building a Patricia trie (a compressed trie) over the concatenated suffixes of the strings.^[1] Construction algorithms, such as the two-phase method, first create a suffix tree for the concatenation of the strings separated by unique markers, then prune invalid paths via depth-first search, achieving O(m) time and space complexity where m is the total input length.^[2] Ukkonen's online algorithm can be adapted for GSTs by processing the strings incrementally, using suffix links to skip redundant computations and handle edge label compressions efficiently. Key applications of GSTs include bioinformatics tasks like multiple sequence alignment and motif discovery, as well as information retrieval problems such as plagiarism detection and longest common extension queries, which preprocess in O(m) time and answer in constant time.^[1] Early work on multi-string indexing, including solutions to the "color problem" for distinguishing string origins, was advanced by Lucas C.K. Hui in 1992, paving the way for practical implementations in large-scale genomic data analysis.^[1] The structure's ability to expose shared substrings through lowest common ancestors of leaves further supports advanced computations like edit distance approximations and parameterized matching.^[2]

Fundamentals

Definition

A generalized suffix tree for a set of strings

D = \{S_1, S_2, \dots, S_d\}

is a compressed trie, also known as a Patricia tree, containing all suffixes of each string

S_i \in D

. Each leaf in the tree is labeled with the string index

i

and the starting position

j

of the corresponding suffix within

S_i

. To distinguish suffixes originating from different strings and prevent cross-string overlaps, a unique terminal symbol \_i

(distinct from all characters in the input alphabet) is appended to the end of each

S_i

. The resulting structure encodes the suffixes of the augmented strings

S_1 $_1, S_2 $_2, \dots, S_d $_d $.^[3] This tree is equivalently defined as the suffix tree of the single concatenated string T = S_1 \_1 S_2 $_2 \dots S_d $_d $, where the terminal symbols ensure that no suffix of one augmented string is a prefix of another. In the trie representation, explicit nodes correspond to branching points or leaves, while implicit nodes represent positions embedded within edge labels, allowing for compression of unary paths.^[3]

Historical Context and Motivation

The suffix tree, a foundational data structure for efficient string processing, was first introduced by Peter Weiner in 1973 as a "position tree" enabling linear-time pattern matching.^[4] This was followed by Ed McCreight's 1976 algorithm, which refined the construction to a left-to-right approach while renaming the structure a "suffix tree" and maintaining linear time complexity.^[5] The generalized suffix tree emerged as a natural extension of these single-string methods in the late 1980s and early 1990s, adapting the core algorithms to handle multiple strings by concatenating them with unique terminators and building a unified tree over the combined input.^[1] A key early application appeared in Dan Gusfield's 1992 work on the all-pairs suffix-prefix problem, where the generalized suffix tree facilitated efficient computation across sets of strings.^[6] Esko Ukkonen's 1995 online construction algorithm further advanced this by providing a simpler, linear-time method adaptable to the generalized case without recomputing from scratch. The primary motivation for developing generalized suffix trees stemmed from the limitations of single-string suffix trees in scenarios requiring simultaneous analysis of multiple texts, such as comparing DNA sequences in bioinformatics, where identifying common motifs or alignments across genomes demands shared structural representation.^[7] In natural language processing, they enable tasks like document similarity and phrase extraction from corpora by capturing shared substrings efficiently.^[1] Similarly, in plagiarism detection, the structure supports rapid identification of overlapping content across documents, as highlighted in early applications for parameterized string matching.^[8] These fields, particularly bioinformatics during the mid-1990s genome projects, underscored the need for tools beyond isolated string processing, as naive approaches like separate suffix trees for each string lacked the integrated view necessary for cross-string queries.^[1] Compared to building independent suffix trees for each string—a naive multiple approach that, while also O(n) in space, hinders direct comparison of shared suffixes—generalized suffix trees achieve space efficiency of O(n) total size for n characters across all strings, leveraging prefix sharing in the trie structure.^[9] Their construction remains linear time via adaptations of Weiner, McCreight, or Ukkonen's algorithms on the concatenated input, avoiding quadratic overheads in pattern matching or substring discovery. The evolution of generalized suffix trees progressed from rudimentary concatenation techniques in Weiner's and McCreight's eras, which treated multiple strings as a single augmented one, to more optimized online algorithms like Ukkonen's that directly incorporate multiple-string handling during incremental building.^[1] This shift enabled broader adoption in computational biology and text analysis by the late 1990s, emphasizing direct multi-string processing without excessive preprocessing.^[9]

Construction Methods

Concatenation Approach

The concatenation approach provides a straightforward method for constructing a generalized suffix tree from a set of input strings by reducing the problem to building a standard suffix tree on a single concatenated string. This technique ensures that all suffixes from the individual strings are represented distinctly in the resulting tree structure. To implement this method, unique terminal symbols—distinct from each other and from the alphabet of the input strings—are appended to the end of each string. These terminals prevent suffixes originating from different strings from being erroneously combined during tree construction, as they act as non-overlapping delimiters. For example, given strings

S_1, S_2, \dots, S_k

, append terminals \_1, $_2, \dots, $_k ) (where each ( $_i

is unique and not in the input alphabet) to form augmented strings

S_1 $_1, S_2 $_2, \dots, S_k $_k ). These are then concatenated into a superstring ( T = S_1 $_1 S_2 $_2 \dots S_k $_k

. A conventional [suffix tree](/page/Suffix_tree) is built on

T $ using an established linear-time algorithm, such as Ukkonen's online construction method for single strings.^[10]^[11]^[12] The time and space complexity of this approach is

O(|T|)

, where

|T|

is the total length of the superstring, matching the efficiency of standard suffix tree construction algorithms assuming a constant-sized alphabet.^[12]^[10] A limitation of this method is its offline nature; it does not support efficient incremental additions of new strings, as incorporating additional input requires reconstructing the entire superstring and suffix tree anew.^[11] The following pseudocode outlines the core steps:

function BuildGeneralizedSuffixTree(strings S[1..k]): terminals = generate_unique_terminals(k) // Distinct symbols outside input alphabet T = [empty string](/page/Empty_string) for i = 1 to k: T = T + S[i] + terminals[i] return SuffixTreeConstruction(T) // e.g., using Ukkonen's [algorithm](/page/Algorithm)

Online Construction Algorithms

Online construction algorithms for generalized suffix trees extend the principles of Ukkonen's linear-time method for single strings to handle multiple strings directly, avoiding explicit concatenation by representing substrings with references to their originating strings. This approach builds the tree incrementally as strings are added, sharing structure for common substrings across strings while maintaining distinct leaf representations for suffixes from different strings. The resulting tree encodes all suffixes of the input strings in O(n total space and time, where n is the aggregate length of the strings. Key modifications to Ukkonen's algorithm include incorporating string identifiers into edge labels, typically as triples (string_id, start_index, end_index) to denote substrings without copying characters. Suffix links are generalized to span contexts across strings, enabling efficient traversal and implicit suffix insertion regardless of the source string. End markers are handled per string during construction, often as unique terminators appended virtually to each string's suffixes to prevent cross-string suffix confusion without altering the original texts. These changes ensure the tree remains compact and queryable for multi-string operations.^[13] The algorithm proceeds by initializing an empty suffix tree with a root node. Strings are added sequentially: for each new string of length m, the procedure simulates Ukkonen's online phases by processing its characters from left to right, starting with the active point at the root. For each position i in the new string, all implicit suffixes ending at i are added via a single extension step, leveraging existing tree paths for prefixes shared with prior strings. Traversals fetch characters using the edge labels' string references, splitting edges at mismatch points and creating new leaves labeled with the current string's identifier. Suffix links facilitate jumping to the longest proper suffix, amortizing the cost across phases. This ensures complete representation of all suffixes from the added string while integrating with the existing structure. The overall time complexity is O(n), as each of the n characters across all strings is involved in a constant number of operations on average, thanks to the suffix link accelerations and active point management. The method supports dynamic insertion of new strings in amortized O(m) time for a string of length m, allowing online updates to the collection without rebuilding the entire tree.^[13] A notable variant, described by Gusfield drawing from Farach's divide-and-conquer framework, adapts the approach for multiple strings by recursively partitioning suffixes based on initial characters while respecting string boundaries through identifier tracking. This method constructs the tree bottom-up: it builds subtrees for groups of suffixes from the same or different strings, then merges them linearly by resolving cross-string branches at internal nodes. The extension phase in this variant focuses on integrating a new suffix group by matching against the current partial tree and updating links, achieving O(n) time overall for fixed alphabets. Brief pseudocode for the extension phase resembles:

function extend(active_node, active_edge, active_length, pos, string_id, char): if active_edge != null: walk_down(active_node, active_edge, active_length, pos, string_id) remaining = active_length - walked if remaining > 0 and edge_label(active_node, next_char) matches char: // Implicit extension via active point update_active_length(remaining + 1) else: // Split edge and create new [leaf](/page/Leaf) split_edge(active_node, active_edge, walked) new_leaf = create_leaf(string_id, pos) add_child(active_node, char, new_leaf) update_suffix_link()

This pseudocode highlights the mismatch handling and leaf creation tailored for the current string_id, ensuring linear progress.

Properties and Operations

Structural Properties

The generalized suffix tree (GST) is a compressed trie that represents all suffixes of a set of input strings, typically constructed by concatenating the strings with unique terminal symbols (e.g., distinct end-markers like $1, $2, ..., $k for k strings) to form a single augmented string of total length n.^[3] Its nodes are divided into two primary types: internal nodes and leaf nodes. Internal nodes have a branching factor greater than 1 and represent the points where suffixes diverge, capturing common prefixes among multiple suffixes from the input strings. Leaf nodes, on the other hand, correspond to the explicit endings of individual suffixes and are labeled with tuples (string_id, start_position), where string_id identifies the originating input string and start_position indicates the starting index of the suffix within that string. Edge labels in a GST consist of compressed substrings from the concatenated input strings, represented efficiently as pairs of pointers (start index and length) rather than explicit character storage to minimize space.^[3] This compression occurs by collapsing paths of unary nodes (nodes with exactly one child), resulting in edges that span multiple characters. Importantly, no internal edge begins with a terminal symbol; terminal symbols appear only on edges leading to leaves, as these symbols are unique to each string's end and prevent suffix overlaps across strings. A key invariant of the GST structure is that every suffix of every input string maps to exactly one unique path from the root to a leaf, ensuring complete and non-overlapping representation of all suffixes without redundancy.^[3] Additionally, the depth of any node—defined as the length of the concatenated edge labels along the path from the root (string depth)—corresponds to the length of the substring represented by the node. Regarding size bounds, the GST for a concatenated string of total length n has at most n leaves (one per suffix) and at most n-1 internal nodes, yielding an upper bound of 2n-1 nodes in total, identical to the bound for a single-string suffix tree; this linear size ensures efficient storage and traversal. The distinguishing feature of the GST compared to a standard suffix tree lies in the partitioning of leaves by the unique terminal symbols, which allows differentiation of suffixes from distinct input strings and facilitates queries spanning multiple strings without ambiguity.^[3]

Core Operations

The core operations of a generalized suffix tree enable efficient querying of multiple strings by leveraging its compressed structure, where paths from the root represent all suffixes of the input strings, distinguished by unique terminators. A primary operation is suffix traversal, which locates a query pattern P of length m by following the unique path from the root that matches P's characters against edge labels. This process traverses O(m / \sigma) edges on average, where \sigma is the alphabet size, but achieves O(m) worst-case time through constant-time edge label comparisons and skipping mechanisms.^[14] Upon reaching the locus of P (an internal node or position within an edge), leaf enumeration retrieves all occurrences by traversing the subtree rooted there and collecting leaf labels, which encode starting positions and string identifiers. This reports or counts matches per input string in O(k) time, where k is the number of occurrences, yielding overall O(m + k) time for pattern location and reporting.^[15] To find the longest repeated substring within a specific input string S_i, identify the deepest internal node whose subtree contains at least two leaves labeled from S_i; the root-to-node path label then gives the substring of maximum length repeating in S_i. This requires a single tree traversal to compute depths and check subtree leaf distributions, taking O(n) time for total input length n, after which the result is available in O(1).^[14] Suffix links, pointers from each internal node to the node representing its longest proper suffix, accelerate repeated traversals by enabling jumps to suffix loci without restarting from the root. In sequential queries sharing prefixes or suffixes, this avoids re-tracing common paths, reducing total time from O(\sum m_j) to near-linear in the aggregate query length.^[14] All such operations run in time linear in the output size following the initial O(n) construction, with no additional preprocessing required beyond building the tree and its links. Leaf labels, a structural property, supply the string-specific identifiers essential for per-string distinctions in these operations.^[16]

Applications

Longest Common Substring Problems

Generalized suffix trees provide an efficient framework for solving the longest common substring (LCS) problem across multiple strings by leveraging the tree's structure to identify shared path labels. For two strings

S_1

and

S_2

with total length

n

, the algorithm begins by constructing the generalized suffix tree in

O(n)

time using Ukkonen's method extended to multiple strings. Each leaf is labeled with its originating string. A depth-first traversal annotates internal nodes if their subtrees contain leaves from both

S_1

and

S_2

, taking

O(n)

time. The deepest annotated internal node represents the locus of the LCS, with its string depth giving the length; the substring is reconstructed by reading edge labels from the root to this node. This yields an

O(n)

time solution overall.^[17] For the generalization to

k

strings with total length

n

, the approach identifies the deepest node whose subtree includes at least one leaf from each of the

k

strings. After building the generalized suffix tree, leaves are marked by string identifiers, and a bottom-up traversal computes for each node the count of distinct identifiers in its subtree, using techniques like bit vectors or color sets to track mixtures efficiently. Nodes with all

k

identifiers are candidates, and the maximum string depth among them determines the LCS length. To handle cases where multiple nodes tie in depth, string counts in subtrees resolve priorities by ensuring balanced representation. Locus finding operations locate these mixed-subtree nodes, enabling the reconstruction of the common substring. The entire process runs in

O(n)

time for linear-time variants.^[18] Extensions of this framework solve the longest common subsequence (LCSub) problem exactly for two strings, which allows non-contiguous matches, by extracting common substrings via tree traversals and modeling overlaps in a graph. A pre-order traversal of the generalized suffix tree identifies common substrings of various lengths, followed by constructing a directed acyclic graph (DAG) where nodes represent these substrings and edges denote valid extensions. The LCSub length is then the longest path in this DAG, computed in linear time relative to the graph size. This method provides an exact solution with

O(n)

preprocessing for the tree and

O(\eta^2)

time for the DAG, where

\eta

is the number of common substrings, offering a practical pathway when direct dynamic programming is infeasible for long sequences. Subtree enumeration from core operations aids in efficiently collecting these substrings during traversal.^[19]

Multiple Pattern Matching

A generalized suffix tree (GST) provides an effective indexing mechanism for a fixed collection of strings, facilitating rapid exact pattern matching across the entire set. The tree is constructed once in linear time relative to the total input size, after which any pattern

P

can be located by traversing from the root along the edges matching the characters of

P

, taking

O(|P|)

time regardless of the collection's size. This traversal leverages the compressed trie structure of the GST, where successful completion to the pattern's locus—a node or edge position—confirms occurrences in one or more strings. To count the occurrences of

P

, the number of leaves in the subtree rooted at the locus is examined; each leaf corresponds to a unique suffix starting with

P

, labeled by its originating string identifier. These counts can be partitioned by string by aggregating leaves with matching identifiers, enabling efficient frequency analysis per input string without rescanning the originals. For reporting all positions, a depth-first traversal of this subtree yields the full list of (string identifier, starting position) pairs from the leaf labels, in time linear to the pattern length plus the number of reported matches. Variants of GST-based matching extend to approximate searches by incorporating error-tolerant mechanisms, such as integrating a Levenshtein automaton to bound the edit distance (mismatches, insertions, deletions) during traversal, thus identifying similar patterns within a specified error threshold.^[20] In bioinformatics, GSTs excel in motif discovery applications, such as scanning multiple genomic sequences for conserved patterns indicative of regulatory elements or binding sites, where the static nature of the sequence set allows preprocessing to support numerous queries efficiently. They are also applied to multiple sequence alignment by identifying conserved regions through shared substrings in the tree.^[21]^[22] This approach outperforms alternatives like the Aho-Corasick automaton for scenarios with fixed texts and variable patterns, as it preprocesses the texts once for

O(|P|)

query times, contrasting Aho-Corasick's pattern preprocessing suited to dynamic texts.^[16] GSTs support plagiarism detection by constructing the tree over a collection of documents and identifying long common substrings that indicate potential copying.^[23] Additionally, they enable longest common extension (LCE) queries, which determine the length of the longest common prefix between any two suffixes, with

O(m)

preprocessing time and

O(1)

query time using lowest common ancestor structures on the tree.^[24]

Examples and Alternatives

Illustrative Examples

To illustrate the construction and usage of a generalized suffix tree, consider two strings: S1 = "banana" and S2 = "apple". These are concatenated as "banana$1apple$2", where $1 and $2 are unique terminal symbols not appearing in the strings, ensuring suffixes from different strings are distinguishable. The generalized suffix tree is then built for this concatenated string using an algorithm such as Ukkonen's, resulting in a compressed trie containing all suffixes. For example, suffixes from S1 include "banana$1" (position 1:1), "anana$1" (1:2), "nana$1" (1:3), "ana$1" (1:4), "na$1" (1:5), and "a$1" (1:6); from S2, they include "apple$2" (2:1), "pple$2" (2:2), "ple$2" (2:3), "le$2" (2:4), "e$2" (2:5), and "$2" (2:6).^[2] In the resulting tree, the root branches to nodes representing initial characters of these suffixes, such as 'b' for "banana$1", 'a' for "anana$1" and "apple$2", 'n' for "nana$1" and "na$1", and 'p' for "pple$2". An internal node for "a" (shared prefix) has children for continuations like "na$1" from S1 position 5 and "pple$2" from S2 position 2, with leaves labeled by string index and starting position, e.g., (1:2) for the suffix "anana$1" from S1 position 2 and (2:1) for "apple$2" from S2 position 1. This structure compacts repeated paths, such as the multiple "a"-starting suffixes from S1 merging under the "a" node.^[2]^[25] To demonstrate usage, the longest common substring (LCS) between S1 and S2 is found by traversing to the deepest internal node whose subtree contains leaves from both strings; here, the node for "a" is the deepest such mixed node, yielding LCS "a" of length 1. To count occurrences of a pattern like "an" across strings, locate the node for "an" and tally leaves from each string in its subtree: "an" appears twice in S1 (under (1:2) and (1:4)) but zero times in S2, as no S2 suffixes start with "an".^[2] For a case with three strings illustrating k-LCS (longest common substring across all k strings), consider S1 = "aa", S2 = "aaa", S3 = "aaaa", concatenated as "aa$1aaa$2aaaa$3" with unique terminals $1, $2, $3. The tree's root branches primarily to 'a', with deep paths merging due to repeated 'a's, but leaves are distinctly labeled (e.g., (1:1) for "aa$1", (2:1) for "aaa$2", (3:1) for "aaaa$3"). The deepest node with leaves from all three strings is at depth 2 (for "aa"), giving k-LCS "aa". The unique terminals prevent cross-string suffix confusion, as a suffix like "a$1a" from S1 cannot erroneously extend into S2's "aa$2" beyond the terminal, ensuring leaves accurately reflect original string boundaries and avoiding false matches across concatenations.^[2]^[25]

Alternative Data Structures

A prominent alternative to the generalized suffix tree for indexing multiple strings is the generalized suffix array, which consists of a sorted array of all suffixes from the input strings, augmented by the longest common prefix (LCP) array to facilitate efficient queries. The LCP array stores the lengths of the longest common prefixes between consecutive suffixes in the sorted order, enabling simulations of suffix tree operations such as pattern matching and longest common substring (LCS) computation.^[26] Unlike suffix trees, which compress paths via trie edges, suffix arrays lack this direct compression, resulting in a simpler but less compact representation.^[27] For multiple strings, generalization is achieved by concatenating them with unique separators and building the suffix array on the combined sequence, preserving distinctions between original strings.^[26] Construction typically requires O(n log n) time, where n is the total length, making it faster in practice than linear-time suffix tree algorithms for large inputs due to lower constants and cache efficiency.^[27] Another structure, the Aho-Corasick automaton, serves as an alternative for multiple pattern matching tasks across strings, though it is not suffix-based and focuses on a predefined dictionary of patterns rather than all possible substrings.^[28] It builds a trie of the patterns with failure links to enable efficient traversal, allowing searches for all occurrences of the patterns in a text in time proportional to the text length plus the number of matches.^[28] Construction time is linear in the total length of the patterns, and it excels in scenarios with dynamic or fixed sets of short patterns, offering better performance for exact dictionary lookups compared to suffix trees, which are optimized for substring queries.^[28] However, it underperforms for comprehensive all-substring queries like LCS across multiple strings, as it does not inherently capture suffix relationships.^[29] The FM-index, a compressed variant of the suffix array based on the Burrows-Wheeler transform (BWT), provides a space-efficient option for large-scale multi-string indexing, particularly in genomics.^[30] It transforms the concatenated strings via BWT to produce a permuted sequence that clusters similar characters, then augments it with rank and select structures for backward search, enabling pattern matching without storing the original text explicitly.^[30] For multiple strings, the same concatenation approach applies, with the BWT preserving suffix order information.^[31] This yields sublinear space usage, often around 3–4 bits per character for repetitive data like genomes, far below the requirements of uncompressed suffix trees or arrays.^[31] Key trade-offs among these structures highlight the generalized suffix tree's strengths in query speed at the cost of space. Suffix trees support O(1)-time LCS depth queries via lowest common ancestor computations but demand 20–200 times more space than FM-indexes for genomic data.^[31] Suffix arrays, using about 40 bits per character with LCP augmentation, offer a balance with O(m log n) pattern matching time—simpler to implement than trees but without inherent path compression.^[31] FM-indexes achieve the lowest space (e.g., 3.36n bits for the human genome) but incur higher query times, such as O(m + occ log n) for matching and slower LCS due to additional traversals.^[31] Alternatives like suffix arrays are preferable over generalized suffix trees for read-only, massive datasets where space constraints dominate, such as in bioinformatics tools for genome indexing.^[32] For instance, enhanced suffix arrays underpin inexact alignment searches in tools similar to BLAST variants, enabling efficient processing of billion-base-pair sequences on standard hardware without the memory overhead of trees.^[32]^[33]

History

Media collections

Generalized suffix tree

Recent from talks

Recent from talks

Contribute something

Contribute something

Media Pages

Timelines

Articles

Notes collections

Notes

Notes

Days in Chronicle

Generalized suffix tree

Functionality

Example

Alternatives

References

External links