Неправильно поняли (вроде бы).
На странице может быть и 100 и 1000 и 5000 слов, но тошнота зависит (и релевантносмть соответственно) не от общего числа слов на странице!!!!! А от числа самого частотного слова на странице. А это число никак не связано с общим числом слов на странице!.
Пробовали на случайных страницах в интернете (но выбирали так, чтобы ВИЦ был минимальным). Пока все укладывается в схему: самое частотное слово определяет тошноту однозначно. Единственная сложность: учет лемматизации (насчет лемматизации здесь: http://romip.narod.ru/romip2006/03_yandex.pdf), т.е. учет всех словоформ одного слова, приходится ручками лемматизировать.
Превысил 7 слов, допустим самое частотное слово на странице встретилось N раз , тошнота стала равной sqrt(N/7). Подтвеждается с точностью до 10 знака.
Тошнота рулит для всех ВИЦев и вклад ее не меньше чем ВИЦ (Хотя это две стороны медали, один множитель ВИЦ, а тошнота - делитель.
Второе плотность ключевика на странице для большого Яндекса - это МИФОЛОГИЯ (на сегодня)..
Опыт номер два.
Опять два одностраничных сайта с теми же словами однословками случайным образом перемешанных. Но на одном уже 30 слово1, на другом 40 слово2
Повторяем ту же процедуру что и в первом посте.
Изменения: изменились положения ступенек и их величина.
Причем с точностью до 9-го знака величины ступенек стали:
для страницы с 30 словами:
ступенька30=sqrt(30/7)*ступенька7
для страницы с 40 словами:
ступенька40=sqrt(40/7)*ступенька7
Ступенька7 это ступенька для страниц, с самым частым словом не более 7.
Релевантность ~ sqrt(ln(вес слова))/sqrt(tf_max)
По Минычу sqrt(tf_max) это тошнота, для страницы с 30 словами (самое частотное слово) tf_max равно 30, с 40 словами (самое частотное слово) tf_max равно 40.
Правильно, wolf, только не забраковали, а жалуются, что не побеждают в соревновании с явным преимуществом, так как коллекция тестовая документов слишком правильная и не загажена так, как в интернете.
А если бы загаженная, то тогда лучше tf брать по самому частотному или функции от нескольких самых частотных или профилю страницы по двойному Пуассону...
Кое что наверняка подправят и в большом Яндексе.
Заметил там любовь к 10ным коэффициентам 0.1 0.2 ... При измерениях они и сейчас кое где вылазят.
Я себе придумал такую схему для этого:
Каждый запрос переколдовывется и получается несколько отдельных запросов к Яндексу (потоков). Каждый поток имеет свой кэш.
Из-за перегрузки серверов Яндекса бывает так , что в нужное время отдельный поток в Яндексе не отвечает и тогда ранжирование как-бы становится урезанным инвалидом, так как проводится при неответе отдельного потока (например, части ссылок). если частично изменить запрос, или подать его повторно, то может вдруг сработать та часть которая сплоховала (не отдала результат в нужное время) и запрос может сработать по другому... Кэши это великое дело и обновляются, якобы, только во время апдейтов.
Я хочу сказать не просто кэши, а кэши ПОДПОТОКОВ конкретного запроса.
Пример, запрос ИЛИ:
хрен1|хрен2
Если сплоховал подпоток запроса "хрен2", и закешировался....
Или запрос И:
хрен1 хрен2
Если сплоховал подпоток запроса "хрен2" и закешировался....
Смысл поясню:
Представьте идет запрос "Пластиковые окна"
он запускает 4(?) потока"
Поток один: найти документы с контектным ограничением "пластиковые окна"
Поток два: на этом ограничении запустить подсчет влияния слова ПЛАСТИКОВЫЕ (а этот поток уже был ранее посчитан по зпаросу ПЛАСТИКОВЫЕ, нахрен его повторно считать? Взять из кеша.
Поток 3 на этом ограничении запустить подсчет влияния слова ОКНА (а этот поток уже был ранее посчитан по зпаросу ОКНА, нахрен его повторно считать? Взять из кеша.
Поток 4: слить два потока: ПЛАСТИКОВЫЕ и ОКНА.
.... Ну, может еще что....
Кэши обновляются только во время апдейтов... Поэтому все перегрузки серверов отрицательно влияют на выдачу, так как они НЕ ЕСТЬ РЕЗУЛЬТАТ ПРАВИЛЬНОГО АЛГОРИТМА ЯНДЕКСА, а результат ПЕРЕГРУЗКИ и хренотени.
Я хочу сказать что кэш, это не к полному запросу только относится, но и к его может быть очень маленькой части.
Кстати, что нас ждет в ближайшем будущем по плотности ключевиков в Яндексе можно посмотреть здесь:Алгоритм текстового ранжирования Яндекса на РОМИП-2006 (Слайды)А. Гулин, М. Маслов, И. Сегаловичстр. 40-51
Могу высказать предположение, что Ваши примеры дают такой результат потому, что "-формат" словоформа учитывется как вес в найденном пассаже (ранжирующее И-НЕ для слова с минусом), а "~формат" словоформа это неранжирующее И-НЕ.
Посмотрите так:
(формат<<(формат -1) )| (1<<(1 -формат))
У меня до сих пор запросик с минусом выдает ноль результатов :)
Возможно это из-за перегрузки таким сложным запросом. Если оставить только (1 -формат) , то Яндекс очень долго думал, секунд 15-20...
И главное. Если числительное идет в комбинации с обычным словом, то из измерений не видно, что Яндекс учитывает "классность". Только если по отдельности.
Оператор минус сильно смахивает на оператор процент :)
Я же не истина в последней инстанции :)
Все-таки различия в выдаче по таким запросам Яндекса и Гугля - огромны, разве не так? И раз есть такие различия. чем это не особенности национальной рыбалки?
wolf, к сожалению запрос (1 -формат) | (формат -1) мне не выдал ничего, буду ломать голову почему, сразу ответить не смогу.
Стоп. запрос типа
1975 url="histori.ru" | диван
не дает ничего, так как. например вы знаете что сильнее, | или неявное И ?
Помните из школы: знак умножения * всегда сильнее знака +
Чтобы однозначность соблюсти, поставьте явно скобки.
Еще добавлю, что подмеченная особенность относится именно к запросам типа
хрен1|[хрен2, когда же туда добавляют в комбинации И с числительным все запутывается! и не все так однозначно с делением на классы!
