agnostic-levenshtein

Crates.ioagnostic-levenshtein
lib.rsagnostic-levenshtein
version
sourcesrc
created_at2025-02-01 06:09:59.123319
updated_at2025-02-03 00:44:03.6808
descriptionLevenshtein distance for ASCII or Unicode strings
homepage
repositoryhttps://github.com/theodore-s-beers/agnostic-levenshtein
max_upload_size
id1538223
Cargo.toml error:TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include`
size0
Theo Beers (theodore-s-beers)

documentation

README

agnostic-levenshtein

After doing the LeetCode problem on the edit distance between two strings—which in this case refers to the Levenshtein distance—I became quite enamored of the algorithm and wanted to write my own implementation in Rust. That's all this is.

I wrote my version such that the function edit_distance takes three arguments: two &str and a bool flag for "ASCII mode." When this flag is set, the algorithm will work directly with the bytes of the strings, rather than building Vecs of their 32-bit (i.e., UTF-32) char values. This should be faster and avoid some allocation, as far as I understand. I wonder if there might be a more efficient approach for the Unicode case.

Either way, the return value is the Levenshtein distance as u32. It may be worth noting that input strings of length greater than u32::MAX will not yield correct results—though I can hardly imagine that problem arising in practice.

Commit count: 16

cargo fmt