Task-oriented documentation for using libdictenstein — how to pick a backend, build and query it, associate values, traverse it edge-by-edge, and persist it. For the why and the internals, follow the links into theory, algorithms, and architecture.
- Getting started — add the crate, build your first dictionary, run a query, walk the automaton. Five minutes.
- Choosing a backend — the selection summary and feature-flag reference. Which of the 20+ backend variants fits your workload.
- In-memory dictionaries — a guided tour of the volatile
(RAM-resident) backends: sets vs. maps, exact vs. substring search, insert-only vs. mutable, and
the
u8/char/u64alphabets. - Cookbook — copy-paste recipes for common tasks: counting, prefix completion, substring search, bidirectional maps, set algebra, serialization, and durable persistence.
A dictionary is a traversable set of terms (strings), optionally mapping each term to a
value V. Every backend implements a small trait API — contains,
root, and node-by-node transition — so you can swap implementations without touching call sites.
With the default value type () a dictionary is a set (membership only); with any other V it
is a map. Lookup costs q, independent of how many
terms are stored — the defining property of the trie-shaped indexes this crate provides.
libdictenstein is the container half of approximate string matching. The query half — a Levenshtein-automaton transducer that walks any of these dictionaries to find terms within an edit distance — lives in the companion crate liblevenshtein. This crate contains no fuzzy-matching code itself.
Notation in these guides follows docs/notation.md.