You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix grapheme cluster handling in reweighting distance calculations
Fixed incorrect edit distance calculations in the reweighting logic that
were counting combining characters as separate characters instead of
treating them as parts of grapheme clusters.
Changes:
- Added grapheme_damerau_levenshtein() function that properly handles
Unicode grapheme clusters (base character + combining marks) as single
units
- Changed reweighting logic to use grapheme clusters instead of chars
throughout (input_lower and sugg_lower now Vec<&str> instead of Vec<char>)
- Updated string building to use .join("") instead of .iter().collect()
- Added logic to correctly classify changes as start/mid/end based on
their actual position in the word:
* When prefix_len == 0 (no prefix match), the first grapheme difference
is a START change, remainder is MID
* When suffix_len == 0 (no suffix match), the last grapheme difference
is an END change, remainder is MID
This ensures that reweighting penalties are calculated correctly based on
actual grapheme edit distance and position, essential for languages using
combining diacritics like Kildin Sami (а̄, э̄, о̄).
Example fixes:
- Input "ыббьр" → Suggestion "э̄ббр"
Before: rew: 0/15/0 (incorrect - э̄ counted as 2 chars)
After: rew: 10/5/0 (correct - э̄ is 1 grapheme at start)
- Input "ыббьр" → Suggestion "-аббьр"
Before: rew: 0/10/0 (incorrect - first change not classified as start)
After: rew: 10/5/0 (correct - first grapheme change is at start)
Fixes#54
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
0 commit comments