Задача географической идентификации скорее разрешима, чем нет: словари ограничены, связи тоже, к тому же динамика мала. Из традиционных проблем анализа - омонимия, с этим также можно побороться в данном случае.
Кто этим занимается? Например, RCO, по-моему, еще РуТез, почти наверное, Конвера. Обязательно есть и другие.
Точное высказывание, встречал в этом треде нечто похожее: "Все сложнее, чем представляется сначала", "Все зависит от цели", "Все должно быть изложено с оптимальной простотой".
Если можно, Artisan, чуть конкретнее. Желательно, примеры, когда стоит экономить на стоп-словах, строя индекс, а когда нет.
В то, что Вы, lagif, представляете многие аспекты проблем ПС, у меня сомнений нет. Будет время, с удовольствием могу с Вами обсудить и проблемы ранжирования.
Давайте разделим проблемы "зачем" и "может загнуться".
На второй вопрос я попытался ответить выше, а на первый - в предыдущем посте.
Что до реализации сего в локальном поисковике, то мы это сделали (да и не только мы) достаточно давно. Правда, базы тогда были до гигабайта, машины - первые пентюхи (помните такие?).
То, что это есть в яндексе и гугле, недостаточно?
Хорошо, например, для поиска точных фраз, а также инициалов: Иванов И.И. и Иванов А.А. - есть разница, правда?
Вы про 60 Мб/с? Эти цифры давал не я - вопрос к постановщику данной задачи.
Не вижу серьезной проблемы в хранении и обработке "и".
Частотность этого предлога ~3%, следовательно хватит 5-6 бит на одно словоупотребление. Кладем с запасом байт, при скорости чтения 60 Мб/сек за 1 сек можно прочитать 60 млн словоупотреблений, этого хватит на базу с общим словоупотреблением примерно 1,8 млрд. Т.е. около 15 Гб текста. Достаточно для одной машины? И это при простейшем решении.
Думаю, ответ Вы получите скорее, если спросите прямо на форуме РЦО.
В данном случае подойдет простой словарь словоформ без всяких "заточенных под язык" методов (любое дерево здесь подойдет). Вот тогда получение диапазона для шаблона превращается в тривиальную задачу.
Правильно ли я понимаю, что трудности вызывает именно применение шаблона (поиск*, поиск? и т.д.)?
Если так, то здесь все достаточно просто:
1. Получаем диапазон подходящих слов;
2. Объединяем соответствующие списки.
Время выполнения операции (1) пренебрежимо мало - одно обращение к словарю. Основное время операции (2) занимает чтение соответствующих списков, что также невелико.
Такие вещи реализовывались еще в поисковиках, работавших на 386-486 машинах, если кто помнит такие.
Так что проблемы, вроде, нет.
Цифра 0.002 - экспериментальная, ссылаюсь на сообщение Влада Шабанова при обсуждении хэшей. Оригинал его сообщения, к сожалению найти на форуме не могу.
Равновероятное = равномерное (не нормальное) - идеальный хэш. Если бы было так, то вероятность склейки была бы для CRC32 2^-32, что противоречит результату 0,002.
Собственно, этого достаточно для доказательства (естественно, не математически строгого) неравномерности распределения.
Но, конечно, если разберете алгоритм, будет интересный результат, с удовольствием почитаю.
