Успешность алгоритма характеризует его возможность решать конкретные задачи.
Для меня частный случай определяет задача, с которой облегченная версия алгоритма успешно справляется.
Обоснование использования контрольных сумм: быстрота сравнения, легковестность хранения в БД (значительная между прочим).
Сравнивая вы 2 текста без использования хэш функций, возможно значительную разницу вы и не почувствуете. При пакетной обработке текстов использование контрольных сумм значительно(!) ускорит процесс.
Про хэш суммы понятно, я еще в самом начале дискуссии это указал.
На этапе канонизации текста, он очищается от лишнего, что не предназначено для сравнения и может повлиять на значения контрольных сумм.
Так я и не утверждал идеальность данного алгоритма.
Я сообщаю факт: статьи, отфильтрованные моей самописной, более легкой версией данного алгоритма очень хорошо кушаются как гуглом, так и яндексом и висят в индексе уже более года :) О чем это говорит? Наверное о возможности каждого алгоритма работать с погрешностями.
Но давайте вспомним, все началось с коллизий хэш-алгоритмов. Собственно вопрос: вы считаете, что даже в приведенном вами методе описательных слов, фразы сравниваются в явном виде, а не их контрольные суммы?
Мне так и не понятно, какие рамки вы просили определить, пожалуйста, поясните.
у Зеленкова с Сегаловичем тоже обоснования как я понимаю нет
Обоснований чего? Они не обсуждали криптостойкости алгоритмов расчета контрольных сумм, а предложили решения задачи, упомянув о том, что коллизии хэш-кодов имеют место быть. А так же представили результаты экспериментов.
боюсь что данные выкладки являются «тыканием пальцем в небо»
Каждый имеет право на собственное мнение :)
С точки зрения банальной логики сравнение опосредованных сумм, гораздо хуже чем простое сравнение количества ключевых слов и фраз. Такой вес будет точнее показывать тематику документа и позволит обходить простые уловки типа переставления слов или предложений местами.
По вашему сравниваются слова/фразы в явном виде, а не их контрольные суммы, алгоритмы расчета которых содержат вероятность возникновения коллизий?
Данный подход называется «Методом описательных слов», насколько мне известно и вполне может быть использован для решения конкретных задач.
так чем почти дубликат где два существительных поменяны местами отличается от других «почти дубликатов»? :)
Для веб-документов подобная подмена неприменима, перестановка существительных в предложении местами превратит текст в нечитабельный, сайт, на котором он будет размещен вероятно постигнет участь дорвеев.
Существует услуга размножения текстов для SEOшников, где «обмана» поисковых систем для слов и словосочетаний подбирают синонимы, затем производят случайное комбинирование и в результате получают читабельные тексты, готовые к размещению на площадках. Для фильтрации наиболее «уникальных» статей, использование данного алгоритма вполне уместно.
Я изначально опираюсь на труд Зеленкова Ю. Г. и Сегаловича И.В., ссылку на который представил в статье. Повторяюсь, для разъяснения теории считаю этого достаточным.
Данные «выкладки» работают очень успешно в несколько упрощенном варианте, проверено лично мной и несколькими пользователями моей программы. Об их не успешности мне ничего не известно *PARDON*
Что значит «если вас интересует дубликат »? Меня интересует не дубликат, а проверка на почти-дубликат, это во первых. Во вторых какие рамки нужно определить? Каждый сам для себя определит, что считать дубликатом, а что нет. Выражайтесь конкретнее.
Зачем нам математическое доказательство на данном этапе? Теорию алгоритма я разъяснил, думаю для заинтересованных этого будет достаточно.
Смотря что понимать под «простой», равнозначно можно сказать, что перестановка существительных в предложении делает статью не дубликатом, а уникальной, определите границы, пожалуйста.
84 набора как раз-таки и используются для последующей случайной выборки.
Для чего сравнивать каждый из 100 значений 84 раза между собой, в соответствии алгоритму хэширования? Можно было бы вполне обойти и одной функцией.
Сравнить два массива по 100 шинглов => 10000 операций сравнения, учитываем, что у нас 84 таких набора, то 84 * 10000 = 840000 сравнений.
Используя случайную выборку мы ограничиваемся 84 сравнениями на финальном этапе, ну и + выборка минимального элемента.
Результат экспериментов :)
На данном этапе высчитывать контрольные суммы через 84 функции может показаться нелогичным. Но в модификации алгоритма шинглов используется случайная выборка над этими 84мя значениями для увеличения производительности.
Для меня частный случай определяет задача, с которой облегченная версия алгоритма успешно справляется.
Обоснование использования контрольных сумм: быстрота сравнения, легковестность хранения в БД (значительная между прочим).
Сравнивая вы 2 текста без использования хэш функций, возможно значительную разницу вы и не почувствуете. При пакетной обработке текстов использование контрольных сумм значительно(!) ускорит процесс.
На этапе канонизации текста, он очищается от лишнего, что не предназначено для сравнения и может повлиять на значения контрольных сумм.
Так я и не утверждал идеальность данного алгоритма.
Я сообщаю факт: статьи, отфильтрованные моей самописной, более легкой версией данного алгоритма очень хорошо кушаются как гуглом, так и яндексом и висят в индексе уже более года :) О чем это говорит? Наверное о возможности каждого алгоритма работать с погрешностями.
Но давайте вспомним, все началось с коллизий хэш-алгоритмов. Собственно вопрос: вы считаете, что даже в приведенном вами методе описательных слов, фразы сравниваются в явном виде, а не их контрольные суммы?
Обоснований чего? Они не обсуждали криптостойкости алгоритмов расчета контрольных сумм, а предложили решения задачи, упомянув о том, что коллизии хэш-кодов имеют место быть. А так же представили результаты экспериментов.
Каждый имеет право на собственное мнение :)
По вашему сравниваются слова/фразы в явном виде, а не их контрольные суммы, алгоритмы расчета которых содержат вероятность возникновения коллизий?
Данный подход называется «Методом описательных слов», насколько мне известно и вполне может быть использован для решения конкретных задач.
Для веб-документов подобная подмена неприменима, перестановка существительных в предложении местами превратит текст в нечитабельный, сайт, на котором он будет размещен вероятно постигнет участь дорвеев.
Существует услуга размножения текстов для SEOшников, где «обмана» поисковых систем для слов и словосочетаний подбирают синонимы, затем производят случайное комбинирование и в результате получают читабельные тексты, готовые к размещению на площадках. Для фильтрации наиболее «уникальных» статей, использование данного алгоритма вполне уместно.
Данные «выкладки» работают очень успешно в несколько упрощенном варианте, проверено лично мной и несколькими пользователями моей программы. Об их не успешности мне ничего не известно *PARDON*
Что значит «если вас интересует дубликат »? Меня интересует не дубликат, а проверка на почти-дубликат, это во первых. Во вторых какие рамки нужно определить? Каждый сам для себя определит, что считать дубликатом, а что нет. Выражайтесь конкретнее.
Смотря что понимать под «простой», равнозначно можно сказать, что перестановка существительных в предложении делает статью не дубликатом, а уникальной, определите границы, пожалуйста.
Для чего сравнивать каждый из 100 значений 84 раза между собой, в соответствии алгоритму хэширования? Можно было бы вполне обойти и одной функцией.
Сравнить два массива по 100 шинглов => 10000 операций сравнения, учитываем, что у нас 84 таких набора, то 84 * 10000 = 840000 сравнений.
Используя случайную выборку мы ограничиваемся 84 сравнениями на финальном этапе, ну и + выборка минимального элемента.
2) По поводу прилагательных, объясните, пожалуйста.
На данном этапе высчитывать контрольные суммы через 84 функции может показаться нелогичным. Но в модификации алгоритма шинглов используется случайная выборка над этими 84мя значениями для увеличения производительности.