Турбо-алгоритм Бойера-Мура — различия между версиями
Zemskovk (обсуждение | вклад) (→Пример работы) |
м (rollbackEdits.php mass rollback) |
||
| (не показано 6 промежуточных версий 4 участников) | |||
| Строка 67: | Строка 67: | ||
==Асимптотика== | ==Асимптотика== | ||
{{Утверждение|statement= Фаза препроцессинга требует <tex>O(m + \sigma)</tex> времени и памяти, где <tex>\sigma</tex> {{---}} размер алфавита. | {{Утверждение|statement= Фаза препроцессинга требует <tex>O(m + \sigma)</tex> времени и памяти, где <tex>\sigma</tex> {{---}} размер алфавита. | ||
| − | |proof= Стадия препроцессинга совпадает со стадией препроцессинга в [[Алгоритм Бойера-Мура|алгоритме Бойера-Мура]], поэтому рассмотрим только стадию поиска.}} | + | |proof= Стадия препроцессинга совпадает со стадией препроцессинга в [[Алгоритм Бойера-Мура|алгоритме Бойера-Мура]]<ref>В этом конспекте приведена реализация за <tex>O(n^2)</tex> и неконстантную память, реализацию за <tex>O(n)</tex> и константную память можно посмотреть вот [http://www-igm.univ-mlv.fr/~lecroq/string/node14.html#SECTION00140 тут] </ref>, поэтому рассмотрим только стадию поиска.}} |
{{Утверждение|statement= Фаза поиска требует <tex>O(n)</tex> времени, где <tex>n</tex> {{---}} длина строки, в которой выполняется поиск. | {{Утверждение|statement= Фаза поиска требует <tex>O(n)</tex> времени, где <tex>n</tex> {{---}} длина строки, в которой выполняется поиск. | ||
}} | }} | ||
| Строка 141: | Строка 141: | ||
* [[Алгоритм Кнута-Морриса-Пратта|Алгоритм Кнута-Морриса-Пратта]] | * [[Алгоритм Кнута-Морриса-Пратта|Алгоритм Кнута-Морриса-Пратта]] | ||
* [[Алгоритм Апостолико-Крочемора|Алгоритм Апостолико-Крочемора]] | * [[Алгоритм Апостолико-Крочемора|Алгоритм Апостолико-Крочемора]] | ||
| + | |||
| + | ==Примечания== | ||
| + | |||
| + | <references /> | ||
| + | |||
==Источники информации== | ==Источники информации== | ||
* [[wikipedia:ru:Алгоритм_Бойера_—_Мура|Википедия {{---}} Алгоритм Бойера-Мура]] | * [[wikipedia:ru:Алгоритм_Бойера_—_Мура|Википедия {{---}} Алгоритм Бойера-Мура]] | ||
Текущая версия на 19:21, 4 сентября 2022
Турбо-алгоритм Бойера-Мура (англ. Turbo Boyer-Moore) является улучшением алгоритма Бойера-Мура. Турбо-алгоритм, разработанный группой учёных во главе с М.Крочемором, предлагает другой подход к коротким алфавитам и заодно решает вторую проблему — квадратичную сложность в худшем случае. Помимо эвристики стоп-символа и эвристики совпавшего суффикса, применяется третья эвристика — эвристика турбосдвига.
Содержание
Алгоритм
Турбо-алгоритм Бойера-Мура не нуждается в дополнительном препроцессинге и требует только постоянную дополнительную память относительно оригинального алгоритма Бойера-Мура. Он состоит в запоминании сегмента текста, который соответствует суффиксу шаблона, совпавшему во время предыдущего шага алгоритма (и только тогда, когда сдвиг хорошего суффикса был выполнен). Эта методика представляет два преимущества:
- Можно перепрыгнуть через этот сегмент.
- Она может позволить выполнение «турбо-сдвига».
Турбо-сдвиг может произойти, если мы обнаружим, что суффикс образца, который сходится с текстом, короче, чем тот, который был запомнен ранее.
Определение турбо-сдвига
Пусть — запомненный сегмент, а — cуффикс, совпавший во время текущей попытки, такой что — суффикс . Тогда — суффикс , два символа и встречаются на расстоянии в тексте, и суффикс длины имеет период длины , а значит не может перекрыть оба появления символов и в тексте. Наименьший возможный сдвиг имеет длину (его мы и называем турбо-сдвигом).Тем не менее, при , если длина сдвига плохого символа больше, чем длина сдвига хорошего суффикса и длины турбо-сдвига, то длина фактического сдвига должна быть больше или равна . Действительно, в этом случае два символа и различны, так как мы предположили, что предыдущий сдвиг был сдвигом хороший суффикса. Тогда сдвиг больший, чем турбо-сдвиг, но меньший, чем будет выравнивать и с таким же символом в , в этом случае длина фактического сдвига должна быть по крайней мере равен .
Нельзя совместить символы с одним и тем же символом в .
Описание алгоритма
В алгоритм Бойера-Мура дополнительно добавится запоминание длины сегмента текста, который соответствует суффиксу шаблона во время последней попытки, который мы не будем лишний раз рассматривать при сравнении суффиксов двух подстрок, а также запоминании размера сдвига , который мы совершили. Вычислять его будем следующим образом:
Пусть , и — размер алфавита.
- Если текущем шаге у нас подстрока совпала с шаблоном , то ( равен периоду шаблона ), .
- Иначе возможны два случая:
- Если сдвиг хорошего суффикса не меньше турбо-сдвига и сдвига плохого символа, тогда , , где — текущая подстрока.
- В противном случае, , , где — длина турбо-сдвига, — длина сдвига плохого символа. Если турбо-сдвиг меньше сдвига плохого символа, то должен быть не больше , где — сегмент текста, рассматриваемый на прошлом шаге.
Псевдокод
Стадия препроцессинга совпадает со стадией препроцессинга в алгоритме Бойера-Мура, функция вычислений сдвигов плохих символов и функция вычисления хороших суффиксов не меняются, меняется только сам алгоритм, в него добавляется обработка турбо-сдвигов.
//x — шаблон, y — текст, m — длина шаблона, n — длина текста
function TBM(x: char[m], y: char[n]): List<int>
int i = 0
int u = 0
int shift = m
//answer — массив, в который мы сохраняем индексы, начиная с которых, подстроки текста совпадают с шаблоном
List<int> answer
if (m == 0)
return
//Предварительные вычисления
int bmBc[] = preBmBc(x, m)
int bmGs[] = preBmGs(x, m)
while (i <= n - m)
int j = m - 1
while (j >= 0 and x[j] == y[i + j])
--j
if (u != 0 and j == m - 1 - shift)
j -= u
if (j < 0)
answer.add(i)
shift = bmGs[0]
u = m - shift
else
int v = m - 1 - j
int turboShift = u - v
int bCShift = bmBc[y[i + j]] - m + j + 1
shift = max(turboShift, bCShift, bmGs[j + 1])
if (shift == bmGs[j + 1])
u = min((m - shift), v)
else
if (turboShift < bcShift)
shift = min(shift, (u + 1))
u = 0
i += shift
return answer
Асимптотика
| Утверждение: |
Фаза препроцессинга требует времени и памяти, где — размер алфавита. |
| Стадия препроцессинга совпадает со стадией препроцессинга в алгоритме Бойера-Мура[1], поэтому рассмотрим только стадию поиска. |
| Утверждение: |
Фаза поиска требует времени, где — длина строки, в которой выполняется поиск. |
| Утверждение: |
В худшем случае поиск требует сравнений. |
|
Так как мы запоминаем последний просмотренный сегмент текста, совпадающий с суффиксом шаблона, это позволяет нам пропускать его при нахождении очередного (нам незачем второй раз просматривать сегмент, про который известно, что он совпадает), что уменьшет число сравнений и хождений по строке. Докажем, что число сравнений после такой оптимизаций будет . Разобьём поиск на шаги, каждый из которых будет состоять из двух операций: сканирования и сдвига. На шаге мы будем называть длину суффикса шаблона, что совпадает с текстом, перед суффиксом шаблона будет символ, который не совпадает с соответствующим символом в тексте (в случае когда не соответствует длине шаблона). Мы также будем называть длину сдвига, сделанного на шаге . Рассмотрим три типа шагов в зависимости от характера сканирования и сдвига. Мы говорим, что сдвиг на шаге короткий, если . Тогда эти три типа будут:
Идея доказательства состоит в амортизации стоимости сравнения со сдвигами. Определим стоимость шага следующим образом:
Общее количество сравнений, выполняемых алгоритмом — сумма стоимостей шагов. Мы хотим доказать, что . Во второй длину последнего сдвига заменим . В случае шага типа (1), стоимость соответствует единственному сравнению несовпадающих символов. Другие сравнения, проведенные в течение того же шага, являются стоимостью последующих шагов. Рассмотрим каждый тип шага:
Покажем правильность шагов по индукции: если все шаги до таковы, что , то . |
Пример работы
Пусть нам дана строка и образец .
Построим массив :
Рассмотрим шаги алгоритма:
В итоге, чтобы найти одно вхождение образца длиной в образце длиной нам понадобилось сравнений символов.

