Ефективні структури даних для побудови швидкої перевірки орфографії

Я намагаюся написати перевірку орфографії, яка повинна працювати з досить великим словником. Я дуже хочу, щоб ефективний спосіб індексувати мої словникові дані, використовуючи відстань Дамерау-Левенштейн, щоб визначити, які слова найближчі до неправильно написаного слова.

Я шукаю структуру даних, яка б дала мені найкращий компроміс між складністю простору та складністю виконання.

На основі того, що я знайшов в Інтернеті, у мене є кілька підказок щодо того, який тип структури даних використовувати:

Трие

trie-500px

Це моя перша думка і виглядає досить просто втіленням і має забезпечити швидкий пошук / вставлення. Орієнтовний пошук з використанням Дамерау-Левенштейна повинен бути простим для здійснення і тут. Але це виглядає не дуже ефективно з точки зору складності простору, оскільки, швидше за все, у вас є велика кількість витрат на зберігання вказівників.

Патрісія Трі

trie-500px

Це, здається, займає менше місця, ніж звичайний Trie, оскільки ви в основному уникаєте витрат на зберігання покажчиків, але я трохи переживаю за фрагментацію даних у випадку дуже великих словників, як у мене.

Дерево суфіксу

суфікс-500px

Я не впевнений у цьому, здається, що деякі люди вважають його корисним у видобутку тексту, але я не дуже впевнений, що це дасть у плані продуктивності перевірки орфографії.

Трирічне дерево пошуку

тст

Вони виглядають досить приємно і за складністю повинні бути близькими (кращими?) До Патрісії Тріс, але я не впевнений, що стосується фрагментації, якщо це буде краще гіршого, ніж Патрісія Тріс.

Вибух дерева

лопнув

Це здається гібридним, і я не впевнений, яку перевагу він мав би над Трісом тощо, але я кілька разів читав, що це дуже ефективно для пошуку тексту.

Я хотів би отримати деякий відгук щодо того, яку структуру даних найкраще використовувати в цьому контексті та що робить її кращою за інші. Якщо я пропускаю деякі структури даних, які були б ще більш підходящими для перевірки орфографії, я також дуже зацікавлений.

data-structures strings string-metrics

— Чарльз Менгуй
джерело

Як патріція триє уникає витрат на зберігання покажчиків? Це просто en.wikipedia.org/wiki/Radix_tree ? Якщо це так, то я думаю, що він все ще зберігає багато покажчиків, але ви будете мати величезну економію місця, оскільки загальні префікси зберігаються лише один раз

— Джо

\geq n

$\geq n$

@linker: Ви випробували всі варіанти вашого словника? З огляду на фіксований випадок використання, це, мабуть, найшвидший спосіб з’ясувати, яка структура даних займає скільки місця.

— Рафаель

Це просто основний словник, просто відомий список правильно написаних слів.

— Чарльз Менгуй

Дивіться також це найбільш тісне питання .

— Рафаель

Я стикався з тією ж проблемою, але використовував інший підхід. Ви можете побудувати якусь функцію "хеш", яка для подібного слова дасть однакове або близьке число.

Проблема полягає в тому, що функція, яка дасть "хороший" результат для слів із вставкою / видаленням, дасть "поганий" для переходу, і навпаки. Приклад: картографуйте букви до чисел, схожих на сусідні цифри, і просто підсумовуйте їх за кожною літерою в слові. Потім створіть хеш-таблиці з наборами для кожної клавіші та знайдіть перетин для слова.

Можливо, певних результатів можна досягти, якщо подивитися на "простір" слів. X для зміни літери, Y для додавання / видалення, Z для переходу або щось подібне.

Однак це лише абстрактні ідеї, у мене не вистачає часу на їх реалізацію.

— MadRunner
джерело

Це те, що робить Soundex en.wikipedia.org/wiki/Soundex

— rgrig

$\mathcal O(\log (n))$ $\mathcal O$

Не зберігайте рядки в метричному дереві. Просто збережіть індекс і збережіть рядки у дереві Патриції.

Я не впевнений, яке дерево ви повинні використовувати. Це залежатиме від ваших даних та ваших вимог (вам потрібно швидко вставити?). Оновіть своє запитання, якщо виявите, що одне дерево є більш ефективним, ніж інші.

Ви також можете подивитися на спеціалізовані засоби, наприклад, люценові.

— оао
джерело