Ну Вы ответили, что пользователь управляет стоп-словами, а как он ими "управил" в тестовом примере, Вы не написали. Сейчас понятно. Стоп-слова, или очень частотные слова на самом деле, нужны в индексе. И как ни странно для того, чтобы быстро отвечать на тяжелые фразовые запросы "to be or not to be". Потому как если выбрать все документы со словом be (отнюдь не низкочастотным), то проверить наличие в них фразы можно только подняв текст документов (или их преобразованную версию). Поскольку документов со словом be очень много (практически каждый первый, если be еще и стеммится), каждый требует рандом акссесса к диску. Резюмируя все это, можно предположить, что запрос вполне может по дисковой активности вылиться на 5-10 минут (фактически по 0.05 мс на каждый найденный документ, а если их миллион, то операция займет больше часа). А если слова to, or, not есть в индексе, то хоть операция считывания соответствующих инвертированных списков и пересечения со списком be тяжелая, но списки можно считывать последовательно и гораздо быстрее. Думаю, что в минуту можно уложиться :-)
вот, кстати, вдогонку результатам поиска: из потенциальных стоп-слов только thereof, но он в действительности довольно редкое слово, никаких a, the, of, in, on.
Так Вы все-таки ответьте если не сложно на мой вопрос про стоп-слова, а то Вы уклоняетесь от ответа: в вашем тестовом примере с 20% индекса Вы их включали в индекс или нет? В принципе, отстутствие стоп-слов в индексе запросу фразовому не мешает.
А скорость поиска можно продемонстрировать на низкочастотных словах и сказать, что частотные слова "редко спрашивают". А в реальности, и я это наблюдал вживую, частотные слова в запросах как раз очень даже часто бывают. То есть наблюдается некоторая корреляция между частотой появления слова в документах и запросах.
Вот мне тоже было бы интересно, потому как 20% это минимальный из всех возможных результатов, наблюденных в природе.
Ок, интересные Вы вещи говорите, надо будет как-нибудь глянуть.
Уважаемый Модератор, меня поняли превртано. Я имел в виду, что Зодчий, как раз был второй жертвой хулиганства со стороны (я написал предположительно кого). Может это и не хулиганство, а все-таки баг? Можно же ведь это проверить по логам, кто заниматеся таким недостойным дело?
она не абстрактная, однако есть подзрение, что повторяемость внутри словаря, или другими словами энтропия, не слишком велика. какой-нибудь gzip сжимает такие данные максимум в три раза. к тому же, я подозреваю, что пойнтеры могут занимать даже больше места, чем я описал, а необходимость выравнивать битовые последовательности по границе байтов, когда мы приходим в разветвляющийся узел вносит дополнительные накладные расходы. какие точно? я не знаю. а, вообще, это увлекательная тема. я не видел пока еще ни одного серьезного исследования, посвященному именно словарному сжатию.
Ну тогда у меня есть сомнения, потому как информация о морфоизменениях + указатели (как миниум один на каждое слово) дают 100 кб прибавочной массы, оставляя 200 кб на хранение одно текста. Вот я сейчас пойду в разные конференции по сжатию данных и спрошу людей, знают ли они хоть один алгоритм сжатия слабокоррелирующего текста (то есть общие основы уже выделены и даже приставки может быть отрезаны) размером 1 мб в 200 кб :-) Посмотрим, что они скажут.
Просто, наверное, правила раскрутки префиксов-суффиксов уже практически всю морфологическую информацию содержат, потому как, например, ать -> ал, ать -> аю только глаголам (и еще кажется деепричастиям применимы) то бишь, чтобы отличать одно от другого еще один битик нужен. Если так, то мы просто говорим об одном и том же, но разными словами.
да нет, все правильно. с самого начала (см. первый пост) шла речь, как засунуть именно с морфологией.
