«плавность» топа

пользуясь случаем, хотелось бы поинтересоваться, зачем используют вот эту парашу:

function getXmlHttp(){
var xmlhttp;
try {
xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (E) {
xmlhttp = false;
}
}
if (!xmlhttp && typeof XMLHttpRequest!='undefined') {
xmlhttp = new XMLHttpRequest();
}
return xmlhttp;
}

https://gitorious.org/batekman/scripts/source/f1c26c8136d8eeb8c0fd6665956c9dc...

Проверил щас ради интереса, XMLHttpRequest поддерживается даже в IE7. Что то тут не так. Что, много публики с IE6 заходит?

При событии «onclick» закладок и кнопок поиска, как и при нажатии Enter в одной из поисковых строк, в фоне срабатывает функция счётчика, добавляющая единичку к количеству использований закладки или поисковой машины. При каждой загрузке страницы элементы сортируются по этому значению. В результате имеем, что элементы, у которых счётчик примерно одинаков, будут прыгать при каждом его увеличении.

Тут важно отметить что важность теряется со временем. Как вариант хранить все в float и, например, раз в день делать top *= 0.99;

Ещё как вариант учитывать несоответствие топу психологическому восприятию(хотя я не психолог, может пред полнейший) я говорю о том что возможно человек с большой радостью будет выбирать второй вариант из списка, потому что например мышкой удобней дотянутся.

Во) Придумал) Смотри, делай группы элементов. Пусть рейтинг 1000 999 500. В таком случае ты первый и второй выводишь на одной высоте(делишь область вывода пополам) а третий внизу на всю ширину. Хотя тут опять будет важна психология восприятия

Какой бы вы посоветовали алгоритм смягчения таких перемещений по топу?

https://ru.wikipedia.org/wiki/Устойчивая_сортировка

при чем тут питон третьей версии, и, исключительно из любопытства, нафига тег web-development, если есть одноименный раздел?

Попробуй такую схему: при использовании элемента его счётчик увеличивается на 1, но всплывает он только если значение его счётчика превышает значение счётчика предыдущего элемента на 5, к примеру. Это означает, что элементы примерно одинаковой частоты использования мешают всплывать друг другу, и не будут меняться местами.

Или на 5+h, где h пропорционально расстоянию от текущей позиции элемента в топе до его хвоста. Это будет означать, что всплывать со дна легче, чем на самом верху.

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

Этот проект я разрабатываю «для себя», по большей части — по принципу «чтобы работало», так что там вполне вероятно увидеть даже нечто более странное. Указанный фрагмент я позаимствовал из одной из найденных статей про AJAX. В перспективе думаю вычищать подобные недоразумения и оптимизировать код.

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

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

Если говорить про мышку, тут всё зависит от исходного положения курсора.

В таком случае ты первый и второй выводишь на одной высоте(делишь область вывода пополам) а третий внизу на всю ширину.

Ну это уж совсем переусложнение) Так можно и до облака (как для тегов) дойти, кстати, это тоже идея.

Это, может тогда сделать так чтоб значения менялись местами когда будет явное превосходство? Например, храним прошлый список. И если в новом будут значения 1000 1004 то продолжаем их выводить в таком порядке, а когда уже например превысил на 5, то в таком - 1005 1000

Питон при том, что скрипт на нём, чтобы те, кто даёт советы, не чувствовали себя спортсменами по научному тыку.

Development — потому что вопрос касается разработки в целом, а не только веба, а тег web-development — потому что в данном случае возможно использование каких-либо средств браузера (в смысле, JS, AJAX, HTML5, …).

Устойчивая (стабильная) сортировка — сортировка, которая не меняет относительный порядок сортируемых элементов, имеющих одинаковые ключи.

У меня так и происходит — если ключи одинаковые, берём порядок из файла. И если элемент стоит в файле ниже другого и периодически обгоняет его по использованиям, то он начинает прыгать.

Тоже об этом думал. А потом какой-нибудь элемент будет ниже другого только потому, что обогнал его на 3, а не на 5.

Надо как-то сделать, чтобы он полз незаметно, но полз. Например, хранить в базе не только количество использований, а ещё и получившийся порядковый номер. И каждый день изменять его в зависимости от направления изменения на психологически допустимый уровень (1-3, чтобы не искать потом по всему списку). Можно даже сделать, чтобы скорость перемещения зависела от количества использований.

С другой стороны, если список большой, то какой-нибудь важный сайт будет так ползти целый месяц, и это плохо. Так что тут надо разработать какой-то особо хитрый алгоритм, который изо всех сил будет стараться на основе указанных чисел «чувствовать» пользователя.

И если элемент стоит в файле ниже другого и периодически обгоняет его по использованиям, то он начинает прыгать

у которых счётчик примерно одинаков, будут прыгать при каждом его увеличении

ЯННП, в чём проблема сортировать по 2 критериям?

А потом какой-нибудь элемент будет ниже другого только потому, что обогнал его на 3, а не на 5.

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

Тоже об этом думал. А потом какой-нибудь элемент будет ниже другого только потому, что обогнал его на 3, а не на 5.

Так и пусть, второе место в списке не намного хуже первого. И если человек реально заходит одинаковое количество раз на оба сайта то это будет вполне приемливо. Значит для него второй сайт не важнее первого.

как вариант можно сделать следующее, смотреть как долго один сайт выше другого. Пусть например тогда алгоритм будет такой, если разность рейтинга, плюс количество дней когда этот рейтинг выше > 5 тогда менять местами.

Тоже сначала так понял задачу )

Не обновляй рейты при выводе, пока выводимые элементы не наберут некую дистанцию, например 1%, или пока их не запросят, скажем, раз 10. Пока не набрали или не накликали - просто показывай старые значения.

Наверно, ещё лучше, чтобы у посетителя не чесались руки делать рефреш слишком часто, по рефрешу отдавай каждый 9 из 10 раз старые значения, а обновляй на 10й и/или динамически.