поиск слова из словаря в данных

[wrest]

realeugene в сообщении #1286671 писал(а):

Превращаете текст в массив слов между пробельными символами,

Для антимата так делать неэффективно, такой фильтр будет много пропускать.

[realeugene]

wrest в сообщении #1286711 писал(а):

Для антимата так делать неэффективно, такой фильтр будет много пропускать.

Зато такой фильтр не будет зарезать лишнего вне заданного списка слов. Или вы хотите построить алгоритмическую модель словообразования матерных слов? Отдельная непростая задачка для ML. Написать нейросеть, которая будет материться так, как не умеют её авторы.

[wrest]

realeugene в сообщении #1286750 писал(а):

Или вы хотите построить алгоритмическую модель словообразования матерных слов?

Антимат - стандартная задача для держателей постмодерируемых форумов и чатов.
Особо сложно, как мне представляется, быть не должно и я полностью согласен насчет regexp-ов, это должно быть эффективным способом и о 4000 слов речь не идёт.
"На самом деле" нецензурная брань не так уж и изменчива. В "трехэтажных" и более-этажных матах достаточно матчить только первый этаж и браковать весь пост. Например, показывая пользователю что именно сматчилось.

realeugene в сообщении #1286750 писал(а):

Зато такой фильтр не будет зарезать лишнего вне заданного списка слов.

Тут вопрос что за аудитория будет материться и каково будет её желание антимат обходить. Например, просто меняя кириллицу на похожую по начертанию латиницу и т.п.

Ну а раз уж есть словарь, то будет удобно отлаживать regexp, смотря на то, почему не сматчилось слово из словаря.
Нужен конечно и список исключений типа "скипидар", "стебель", "подстрахуй", "колебать" ну и т.п.

[gevaraweb]

Кстати, а разве из

Dmitriy40 в сообщении #1286314 писал(а):

Не утерплю и покажу пример когда могут.
Предварительно сделаем пару правдоподобных предположений: все искомые слова начинаются на одну и ту же букву; используется тривиальный алгоритм сравнения слов (подстрок).
Итак, при тривиальном алгоритме чтобы проверить наличие слова в тексте надо для каждого символа текста сравнить две подстроки: вырезанную с текущего символа из текста и каждое из 4000 искомых слов. А для этого будет сделано 4000 сравнений текущего символа текста и первой буквы каждого из слов. Несмотря на то что они все одинаковые! Общая сложность не меньше чем $4000 \cdot L$ ($L$ - длина текста). Длину слов не учитываем - считаем её намного меньшей длины всего текста.
КА же не будет делать 4000 сравнений первой буквы всех слов с текущим символом текста, он выполнит ровно 1 сравнение текущего символа текста с одинаковой первой буквой всех слов.
Если в тексте вообще нет ни одного слова с первой буквой как у искомых слов - это в 4000 раз быстрее.

не следует истинность

gevaraweb в сообщении #1286537 писал(а):

регэсп будет работать быстрее на наборе 4000 слов, начинающихся на одну букву, чем на наборе из 4000 слов, не начинающихся на одну букву.

Просто две схожие регулярки было бы проще и надежнее было бы сравнивать.

[Dmitriy40]

gevaraweb
На этот вопрос я уже ответил:

Dmitriy40 в сообщении #1286548 писал(а):

Впрочем, процитированное утверждение тоже верно, т.к. для слов на одну букву будет лишь одно сравнение в начальном состоянии КА, для слов на 25 разных букв сравнений будет 25, что теоретически медленнее (но на практике незаметно).

[gevaraweb]

Нашел ответ на свой вопрос, можно оказывается указать в регулярке так:

д(верь|ом|юна|инамит)

Теперь верю, что быстрее ) Но по-прежнему сомневаюсь, что регэксп самостоятельно определит такое

дверь|дом|дюна|динамит

Ну да ладно. Нашел готовый Ахо-Корасик. Сократил словарь до 1000 слов, сделал простой поиск без защиты от замены букв и пр.
https://jsfiddle.net/gevaraweb/ytkm1363/

[Dmitriy40]

gevaraweb в сообщении #1287363 писал(а):

Но по-прежнему сомневаюсь, что регэксп самостоятельно определит такое дверь|дом|дюна|динамит

По идее такой регэсп превратится в дерево с одной вершиной, одной ветвью (с буквой "д") к узлу, 4-я ветвями (с 4-я буквами) из него к 4-м разным узлам следующего уровня и потом из каждого этого узла ещё цепочка ветвей и узлов разной длины уже без ветвлений до конечного листа (соответствующего слова). Реализация КА обрабатывающего это дерево может быть разной, но в общем виде будет похожа на:

Используется синтаксис C

for(i=0;i<len;i++)//цикл прохода по буквам всего текста, разбиение на слова для простоты не приведено
switch (state) {
case 0://ждём первую букву искомых слов
        switch (s[i]) {
        case 'д': state=1; break;//проверка слова дверь
        case 'д': state=1; break;//проверка слова дом
        case 'д': state=1; break;//проверка слова дюна
        case 'д': state=1; break;//проверка слова динамит
        };
        break;
case 1://проверяем вторую букву искомых слов, причём первая была точно "д"
        switch (s[i]) {
        case 'в': state=2; break;//проверка слова дверь
        case 'о': state=3; break;//проверка слова дом
        case 'ю': state=4; break;//проверка слова дюна
        case 'и': state=5; break;//проверка слова динамит
        default: state=0;//неподходящая буква
        };
        break;
case 2://проверяем третью букву слова дверь
        if (s[i]=='е') state=6; else state=0;//проверка слова дверь
        break;
case 3://проверяем третью букву слова дом
        switch (s[i]) {
        case 'м': return 2;//проверка слова дом, нашли второе искомое слово!
        default: state=0;//неподходящая буква
        };
        break;
case 4://проверяем третью букву слова дюна
        state=(s[i]=='н')?7:0;//проверка слова дюна
        break;
...
};

Разные варианты кодирования условных операторов показаны специально, функциональность их (в контексте обработки КА) одинакова.
Так вот, даже если построитель КА по регэспу совсем тупой и не исключил дублирование четырёх одинаковых ветвей из state 0 (что в общем-то совершенно нереально по самому принципу минимизации КА), то они будут убиты оптимизирующим компилятором.
Это и есть ответ на Ваш вопрос определит ли и будет ли быстрее. Да, определит и будет.

Подчеркну, любой КА (без памяти) можно представить в виде такого вот длинного switch, просто описываете каждое его уникальное состояние и условия переходов между ними (как в первых двух case выше) и всё, больше ни о чём думать не надо. Правда для сложных паттернов при ошибке текущей буквы переход часто будет в не в state 0, а в другое, которое является подстрокой уже найденной части слова. Пример: проломить|ломать, после получения на вход пролом и появлении буквы а возврат будет не к ожиданию любой из букв п|л, а к ожиданию буквы т уже в слове ломать, т.к. полученная подстрока пролома включает и начало слова ломать. Но это уже тонкость на Ваш вопрос не влияющая, просто Вам для информации что не всё так просто как кажется на первый взгляд.

PS. Для любителей чистоты и полноты выкладываемого кода: да, код не полный и даже может содержать незначительные для понимания принципа работы ошибки/описки. Я его не проверял, это лишь иллюстрация принципа реализации одного из видов КА (без памяти).

[wrest]

gevaraweb
Регулярки умеют много гитик
Посмотрите например как работают positive\negative lookbehind\lookahead http://www.regular-expressions.info/lookaround.html