[spip-dev] Modif importante du calcul de popularite

Salut,

Après 10 jours de "statistiques" sur uZine, le calcul de la popularite s'avère très incohérent: notamment parce que ça ne fonctionne que s'il y a des referers, ça ne prend pas en compte les visites "dans l'absolu", et ça donne la plupart des articles avec une popularite de zéro (ce qui interdit les classements "par popularite" sur des sélections restreintes (par exemple, dans même rubrique). Et, surtout, des articles "pas importants" totalement surestimés sans que l'on sache trop pourquoi.

Du coup, je viens d'uploader une nouvelle version de inc_statistiques, avec une version plus souple, et qui semble pour l'instant donner des résultats plus cohérents:
- d'abord ça prend tous les articles publiés; comme ça, au minimum, ça se base sur le nombre de visites dans l'absolu;
- puis ça prend le nombre de "visites entrantes" (je laisse tomber le nombre de referers différents, l'info est déjà intégrée au nombre de "visites entrantes") depuis spip_referers_articles pour chaque article (j'ajoute 1 à chaque fois, histoire de ne jamais avoir de valeur nulle).

Ensuite, la popularite est la multiplication du nombre de visites absolues par le nombre de visites entrantes; divisé par la popularité maximale (donc valeur entre 0 et 1). Là, je balance deux "sqrt", donc je prends la racine quatrième de cette popularité relative, et je multiplie par 100. De cette façon, on obtient bien un résultat entre 0 et 100, et les valeurs sont réparties sur l'ensemble [0,100] de manière relativement uniforme (ce qui évite le massacre d'avoir les valeurs ramenées à 0 ou 1 à cause d'une article particulièrement visité et référencé par rapport aux autres).

Sur uZine, où l'on a des entrées et référencements vraiment très divers, ça donne des résultats qui semblent bien cohérents pour l'instant.

Du coup, on obtient une popularité qui dépend du nombre de visites et du nombre d'entrées directes sur l'article. Mais pas de l'âge de l'article. C'est ce que je prévoyais au départ, car la difficulté est de calculer une valeur "relative" sur tout le site (sur 100), et non un problème d'âge de l'article.

Donc, nouveau critère de classement dans les boucles ARTICLES: {par activite}, l'activité étant la popularité au carré divisé par l'âge de l'article. Là encore, sur uZine, ça donne des résultats cohérents.

Ah oui, au passage, d'après mon décompte, il n'y a pas plus de requêtes que dans la version précédente (au pire, pour les update, comme j'ai repris le principe du tableau popularite_upload, on n'a que 100 requêtes au maximum, même si 10000 articles publiés).

ARNO*

Coucou,

on pourrait passer les nouvelles fonctionnalités après la 1.4 ? J'ai fait
une 1.4PR4 avec ce qu'on avait dans le CVS, mais le récent code d'Arno pour
l'activite n'a été vu par personne.

-- Fil

>Du coup, on obtient une popularité qui dépend du nombre de visites et du
>nombre d'entrées directes sur l'article. Mais pas de l'âge de l'article.
>C'est ce que je prévoyais au départ, car la difficulté est de calculer
>une valeur "relative" sur tout le site (sur 100), et non un problème
>d'âge de l'article.
From fil@miel.brainstorm.fr Mon Aug 26 23:34:36 2002

Return-Path: <fil@miel.brainstorm.fr>
Received: by miel.brainstorm.fr (Postfix, from userid 1001)
  id 1A8F71C01D; Mon, 26 Aug 2002 23:34:36 +0200 (CEST)

N'importe quoi. Alors je vais expliquer pourquoi ton système de calcul (qui, lui, n'a jamais été expliqué) ne fonctionne pas.

  // Calcul des gains en popularite
  $query = "SELECT id_article, COUNT(*) AS referers, SUM(visites) AS visites ".
    "FROM spip_referers_articles GROUP BY id_article";
  $result = spip_query($query);

Le calcul se base uniquement sur la table spip_referers_articles. Déjà, si on n'active pas les referers (et ils sont désactivés par défaut), on n'a pas de "popularite" (alors que les visites sont, logiquement, une information de popularité). Quant aux sites et articles qui sont peu ou mal référencés, ils travaillent sur des statistiques tellement faibles qu'on est dans l'aléatoire pur (valeurs pas discrimantes, une visite un jour, zéro le lendemain, 3 le jour suivant). Le nombre d'entrées dans l'absolu doit donc être pris en compte, il permet d'avoir non seulement un fonctionnement quand les referers sont désactivés, mais en plus une valeur de base pour les articles à faibles visites (au moins, ça augmente de 1 ou 2 par jour).

De plus, les articles les plus "visités actuellement" ne sont pas forcément les plus référencés: sur uZine, l'article "Installer SPIP" est un des articles les plus visités (actuellement, pas seulement sur la durée), alors qu'il a un nombre de referers très faible. D'accord, c'est un exemple spécifique, mais c'est logique: certains articles sont visités parce qu'on navigue sur le site vers les articles "pertinents", mais ce ne sont pas forcément les articles référencés depuis l'extérieur (notamment sites à "dossiers" où un seul article est référencé, voir même l'entrée directe dans une rubrique, auquel cas avec les referers_articles on ne compte plus rien du tout).

  while ($row = mysql_fetch_array($result)) {
    $id_article = $row['id_article'];
    $referers = $row['referers'];
    $visites = $row['visites'];

    $popularite = intval(10 * sqrt(($referers + 1) * $visites));
    $popularite_update[$popularite][] = $id_article;
    if ($max < $popularite) $max = $popularite;
  }

Ensuite, le gain de popularite est obtenu en multipliant le nombre de sites-referers différents par le nombre d'entrées directes. Or, le nombre de sites-referers est extrêmement aléatoire, et puisque désormais on a un nombre d'entrées directes, ce nombre est beaucoup plus pertinent dans une optique de popularité (de plus, il dépend déjà pour un bonne part du nombre de sites-referers). En multipliant par le nombre de sites-referers, on obtient de plus une surpondération énorme des articles à mots-clés forts (sex, mp3) en provenance des moteurs (nombreux referers différents à très peu de visites), par rapport aux articles référencés "volontairement" par un nombre de sites eux-mêmes très fréquentés (peu de referers différents pour éventuellement le même nombre de visites). De plus, le nombre de sites-referers dépend du système utilisé sur le site réferant: un article référencé dans un article sous SPIP aura en gros un referer unique (car théoriquement une seule URL par article), alors qu'un article sous un autre système (daCode, Nuke) aura plusieurs referers identifiés pour un même lien (flagrant en ce moment sur l'article de Fil sur unicode; un article recevant 100 visites directes depuis un site sous SPIP (une seule URL) aura donc une popularité de 10*sqrt(100), et 100 visites directes depuis un site sous daCode (presque 10 URL différentes) aura un popularité de 10*sqrt(1000). Donc, le critère "visites" seul est plus pertinent; multiplier par le nombre de sites-referers est à la fois redondant et aléatoire.

  if ($max < 100) $max = 100;

D'où sort cette valeur de 100??? Le système est conçu pour aller chercher des valeurs sur l'ensemble des visites, histoire de fabriquer une normalisation logique, et on sort une valeur absolue à partir de rien? Pour info, sur uZine, aujourd'hui, on obtient un $max de 5819. Et sur un site peu référencé, évidemment il ne sera pas anormal d'avoir aussi un $max inférieur à 100.

  $query = "UPDATE spip_articles SET popularite = popularite + $popularite * 100 / $max ".
    "WHERE id_article IN (".join(', ', $articles).")";

La modification de popularité est donc basée sur le calcul: $popularite * 100 / $popularite_maximale. (Mais c'est une série x_1 = x_0 + delta; pour simplifier à l'extrême, en considérant que la popularité est stable d'un jour à l'autre - même si elle varie beaucoup sur les périodes plus longues -, on obtient bien la popularité calculée précédemment, ramenée en pourcentage de la valeur maximale, mais amortie sur quelques jours.))

Très bien. Bon, toujours sur l'exemple hyper-vachement-spécifique d'uZine, j'obtiens, sur 503 articles calculés, 146 articles avec une modif de 0, 202 avec un modif de 1, et 70 avec une modif de 2. C'est-à-dire 418 articles sur 503 qui se voient modifier d'une valeur de 0, 1 ou 2. On obtient ainsi une popularite qui n'est pas du tout discriminante pour les 4/5 du site. Donc, il vaut mieux prévenir: la popularité ne sert à afficher que les 7 articles les plus populaires sur l'ensemble du site, mais faut surtout pas jouer avec sur des rubriques, parce que là ça ne donnera plus rien du tout; ni même sur des secteurs entiers si les visites du site sont déséquilibrées selon les secteurs.

Sur des sites faiblement référencés, vu qu'on a un $max qui est fixé arbitrairement à une valeur supérieure, on détruit encore plus la discrimination, vu que la modif de popularité maximale ne sera plus un pourcentage de la valeur max, mais sur bien plus (si le $max réel est 50, on "divise" les gains de popularité, déjà dérisoires pour la plupart des articles, par 2).

  $query = "UPDATE spip_articles SET popularite = popularite * 100 / $max";
  $result = spip_query($query);

Enfin on "normalise" à nouveau (histoire de ne pas obtenir de valeur supérieure à 100, c'est normal). $max étant la valeur maximale de popularité sur les articles. Or, chaque jour la valeur maximale (dès qu'un site est relativement référencé, donc qu'on ne recourt pas au $max=100) de popularité avant modif est 100%; le lendemain, on ajoute la nouvelle valeur calculée, et comme la plupart du temps le site le plus "populaire" le reste pendant plusieurs jours, c'est le même qui se voit attribuer 100+100, donc le $max pour la normalisation est 200 (en gros, sauf à imaginer que l'article ayant la plus grosse popularité change tous les jours, avec des changements de valeur énormes, et malgré l'amortissement du calcul par les referers sur 7 jours). Ce qui signifie qu'on divise simplement toutes les valeurs par deux.

Sur uZine, on obtient donc, sur 503 articles, 418 articles dont la popularité déjà faible (0,1,2) est divisée par deux; ça devient vraiment plus du tout discriminant, avec des suites qui tendent, pour les 4/5 des articles, vers les valeurs 0 ou 1.

Et là-dessus on fait le ménage:
$query = "DELETE FROM $table WHERE date < DATE_SUB(NOW(),INTERVAL 7 DAY) OR visites <= $visites_min";

J'avais mis un AND, et non un OR. Puisqu'ici, on détruit purement et simplement les referers des articles à faible traffic, et donc le calcul de popularité, puisqu'on ne laisse même pas le temps d'accumuler sur 7 jours au moins quelques "petits" referers. Et au bout de 7 jours on efface tout, y compris le referer énorme qui alimente en visites énormes tous les jours le même article, mais depuis une semaine (il recommence à zéro du jour au lendemain sans aucune modification réelle de l'activité de l'article).

L'ensemble est incohérent de bout de bout. Sur les sites à faible traffic, peu référencés, les valeurs seront tout bonnement aléatoires. Les referers étant désactivés, on n'a plus rien non plus. Sur des sites au traffic réparti de manière très hétérogène (soit à cause de quelques articles receuillant le plus de traffic direct, soit parce qu'il y a dossiers, avec un article servant de porte d'entrée), on obtient des résultats uniquement pour une poignée d'articles, les résultats suivants sont tellement peu disciminants que ça n'a aucun sens - ça, on me croit ou non, mais sur tous les sites les visites sont très hétérogènes. En revanche, ça oui, sur des gros sites à très fort traffic, à la structure très homogène (pas d'articles vraiment "en vedette" référencés par un gros site), sur une durée de 10 jours à la fin des vacances, certainement ça a une chance de fournir un résultat.

ARNO*

Salut,

Je viens de refaire un système de calcul de popularité, qui intègre mes remarques du mail précédent et l'exigence d'Antoine d'avoir l'évolution temporelle (activité récente) directement dans le calcul de la popularité.

Le principe général est de se ramener à une valeur de visites quotidiennes pondérée par l'âge des visites. Sur le principe (grossièrement): les visites du jour-1 sont comptées fois 1; pour le jour-2, fois 1/2; pour le jour -3, fois 1/3... En fait, pas exactement, il y a une variable $diff, qui décale le calcul, pour éviter de surpondérer les toutes première valeurs de manière trop importante. On ajoute toutes ces visites. Puis on prend les entrées directes "récentes" (15 jours), et on les surpondère (d'un facteur $coeff_referers). On ajoute au total. Ensuite, comme d'hab, on divise par la valeur maximale, on passe au carré (le carré d'une valeur entre 0 et 1, donc résultat entre 0 et 1, avec très forte progressivité des petites valeurs, et aplatissement des grandes valeurs).

Donc, trois étapes, pour 3 requêtes mySQL...

- On commence par récupérer les visites dans spip_visites_articles. Pour chaque entrée, on a la date, donc le calcul visites/age est facile. C'est la valeur réellement importante dans le calcul des visites.

- Ensuite on récupère la valeur des visites des articles dans spip_articles directement. C'est important, car cela permet d'obtenir des valeurs même pour les articles qui n'ont pas été visités récemment (donc pas dans spip_visites_articles récemment); certes ils écoperont de valeurs très faibles, mais pas d'un zéro absolu qui interdirait tout classement (ce qui revient en -très- gros à classer selon le nombre de visites divisé par l'âge de l'article). Accessoirement, cela permet d'avoir une certaine continuité, et donc cohérence, lors de la mise à jour de SPIP sur un site déjà existant.

- Enfin, on récupère les "entrées directes" depuis spip_referers_articles. C'est déjà surpondéré dans le calcul (on prend les referers récents, mais on ne divise pas par un âge des entrées), mais on surpondère encore par un $coeff_referers, de façon à régler ça. Et on ajoute au total des visites pondérées de l'article.

Ensuite, la normalisation en fonction de la valeur max pour obtenir un pourcentage.

On obtient donc bien une évolution en fonction du temps: les articles visités récemment et ayant été référencés sont très nettement favorisés. Cependant on obtient des valeurs qui couvrent de manière homogène l'intervalle [0,100], ça devrait fonctionner même sur les sites à faible traffic, l'absence ou le très faible nombre de referers ne gêne pas le fonctionnement. Et, même si les valeurs sont calculées chaque jour, il y a un amortissement de l'évolution dû au mode de calcul.

Les deux variables permettront de régler le comportement du système:
- Le "décalage" de temps $dif: si on le diminue, on augmente la popularité des articles publiés très récemment (favoriser la date); si on l'augmente, on favorise les articles ayant beaucoup d'entrées (favoriser les visites).
- Le cofficient des entrées directes $coeff_referer: si on l'augmente, on favorise les sites fortement référencés par rapport aux sites très visités.

ARNO*

(alors que les visites sont, logiquement, une
information de popularité).

Dans ce cas, tu utilises les visites. C'est bien toi qui as voulu un
système supplémentaire depuis le début, non ? Sans quoi on ne serait
même pas en train de se faire chier.

> Quant aux sites et articles qui sont peu ou

mal référencés, ils travaillent sur des statistiques tellement faibles qu'on est dans l'aléatoire pur

N'importe quoi aussi. La méthode est cumulative : les entrées sont
sommées jour après jour et amorties par un facteur de 0.9.

De plus, les articles les plus "visités actuellement" ne sont pas forcément les plus référencés:

Tu te fous de la gueule du monde ? C'est *toi* qui as toujours dit
qu'une mesure de popularité devait se baser sur le nombre de referers
extérieurs parce que c'était "plus pertinent", et maintenant tu me
reproches de calculer une mesure à ton goût ??

par rapport aux articles référencés "volontairement" par un nombre de sites eux-mêmes très fréquentés (peu de referers différents pour éventuellement le même nombre de visites).

Encore une fois, c'est *toi* qui as voulu dès le début comptabiliser
les referers externes parce que c'était super-plus-parlant. Si tu
n'avais pas fait chier le monde avec ce genre d'idées à la mords-moi-
le-noeud, il n'y aurait même pas de décompte de referers et on aurait
évité de se prendre le chou.

On obtient ainsi une popularite qui n'est pas du tout discriminante pour les 4/5 du site. Donc, il vaut mieux prévenir: la popularité ne sert à afficher que les 7 articles les plus populaires sur l'ensemble du site,

Sur _ton_ site, oui. Tu vas nous raconter qu'un article qui reçoit
5 visites par jour est censé être classé comme "populaire" ?

Note, tu racontes des conneries : quand le resume.php3 était présent
sur uzine, on voyait bien que les 10 articles les plus populaires
étaient au-dessus de 10%, donc qu'il y en avait pas mal derrière.
Mais j'imagine qu'au point où tu en es tu n'as plus rien à foutre
de savoir si ce que tu dis est juste ou pas.

(si le $max réel est 50, on "divise" les gains de popularité, déjà dérisoires pour la plupart des articles, par 2).

Si le site est dérisoirement populaire, la popularité est dérisoire, oui.
Ca me semble raisonnable.

Et là-dessus on fait le ménage:
$query = "DELETE FROM $table WHERE date < DATE_SUB(NOW(),INTERVAL 7 DAY) OR visites <= $visites_min";

J'avais mis un AND, et non un OR. Puisqu'ici, on détruit purement et simplement les referers des articles à faible traffic, et donc le calcul de popularité, puisqu'on ne laisse même pas le temps d'accumuler sur 7 jours au moins quelques "petits" referers. Et au bout de 7 jours on efface tout, y compris le referer énorme qui alimente en visites énormes tous les jours le même article, mais depuis une semaine

On détruit tout parce qu'on veut pouvoir contrôler l'espace-disque.
J'ai bien compris que tu t'en foutais, c'est pour ça qu'à un moment
sur uzine il y avait une instance des visiteurs qui avait bouffé
150 Mo (et tu t'étonnais que ton site passe son temps à planter :-)).

Cependant on obtient des valeurs qui couvrent de manière homogène l'intervalle [0,100],

Ah, j'imagine que tu as testé alors ?

"Fatal error: Call to undefined function: optimiser_referers() in d:\http\spip\inc-stats.php3 on line 88"

C'est un système éprouvé, donc.

Je viens de refaire un système de calcul de popularité, qui intègre mes remarques du mail précédent

Plus exactement, plutôt que de fignoler l'existant, tu as rebalancé
un nouveau bousin totalement différent (et qui balance une erreur de
syntaxe ;-)). C'est pénible....

Et pour résumer, on n'a toujours pas de mesure de la popularité
instantanée, mais un agrégat incompréhensible fait d'additions
de visites récentes, de visites totales et de referers récents,
le tout avec des coefficients bizarres et des règles folkloriques.
(du genre : $age = intval(2 * ($row['age'] + $diff) / 3) )

> (alors que les visites sont, logiquement, une

information de popularité).

Dans ce cas, tu utilises les visites. C'est bien toi qui as voulu un
système supplémentaire depuis le début, non ? Sans quoi on ne serait
même pas en train de se faire chier.

Non, car le critère {par visites} est un critère dans l'absolu (depuis le début du site). Mon système permet d'avoir une popularité par les visites récentes à l'intérieur de la popularité.

De plus, les articles les plus "visités actuellement" ne sont pas forcément les plus référencés:

Tu te fous de la gueule du monde ? C'est *toi* qui as toujours dit
qu'une mesure de popularité devait se baser sur le nombre de referers
extérieurs parce que c'était "plus pertinent", et maintenant tu me
reproches de calculer une mesure à ton goût ??

Je ne te "reproche" rien, je t'explique pour le système que avait mis ne fonctionnait pas.

par rapport aux articles référencés "volontairement" par un nombre de sites eux-mêmes très fréquentés (peu de referers différents pour éventuellement le même nombre de visites).

Encore une fois, c'est *toi* qui as voulu dès le début comptabiliser
les referers externes parce que c'était super-plus-parlant. Si tu
n'avais pas fait chier le monde avec ce genre d'idées à la mords-moi-
le-noeud, il n'y aurait même pas de décompte de referers et on aurait
évité de se prendre le chou.

Ben il n'y a plus du tout de décompte des referers, puisque le champ "referers" de spip_articles n'est plus du tout alimenté.

Depuis, j'ai des analyses de stats depuis deux mois (remis à zéro y'a 10 jours, m'enfin ça tourne), et comme désormais on a le nombre d'"entrées directes" (ce qu'on avait pas du tout dans la 1.3, où on n'enregistrait que les urls des referers, pas le nombre de fois où ils avaient servi à quelque chose).

On obtient ainsi une popularite qui n'est pas du tout discriminante pour les 4/5 du site. Donc, il vaut mieux prévenir: la popularité ne sert à afficher que les 7 articles les plus populaires sur l'ensemble du site,

Sur _ton_ site, oui. Tu vas nous raconter qu'un article qui reçoit
5 visites par jour est censé être classé comme "populaire" ?

Quelle que soit la méthode de calcul, de toute façon la popularité n'est pas un chiffre "dans l'absolu", mais une méthode de classement des articles. Si l'article le plus visité est à 20 visites, oui il est noté comme le plus populaire du site, histoire qu'on ait un classement, donc un ordre relatif entre les articles.

La notion de _mon site_ est intéressante: si le système ne fonctionne pas sur "mon" site, ça suffit déjà à se poser des questions, non?

Note, tu racontes des conneries : quand le resume.php3 était présent
sur uzine, on voyait bien que les 10 articles les plus populaires
étaient au-dessus de 10%, donc qu'il y en avait pas mal derrière.
Mais j'imagine qu'au point où tu en es tu n'as plus rien à foutre
de savoir si ce que tu dis est juste ou pas.

C'est donc bien exactement ce que je dis: dès le 10e article (sur 577), on est déjà à 10%. Et on se devrait se démerder avec ça pour obtenir un classement relatif entre les articles. Quand je dis que 4/5 du site se retrouvent avec des valeurs 0, 1 ou 2, c'est bien ça.

Avec mon nouveau bousin, sur uZine, on atteint les 10% à partir du 450e article, ce qui autorise tout même un classement.

Si le site est dérisoirement populaire, la popularité est dérisoire, oui.
Ca me semble raisonnable.

Non, sinon on n'irait pas chercher à ramener à un pourcentage du chiffre maximal. On aurait un chiffre calculé dans l'absolu, donc on aurait aussi un classement entre les articles; avec une notion de "popularite" dans l'absolu, c'est-à-dire qu'on pourrait même classer les articles sur plusieurs sites différents (uZine étant certainement moins populaire que le Diplo).

Mais à partir du moment où l'on ramène tout à une valeur maximale (étant fixée à 100), c'est bien parce que tout ce qu'on veut, c'est une méthode de classement à l'intérieur du site. Donc sur un site "dérisoirement populaire", hé bien l'article le plus populaire est à 100; et le webmestre obtient déjà un classement de popularité quelle que soit la popularité "absolu" de son site.

Le choix d'une popularité absolu pourrait être tout aussi bien choisi, remarque. Mais dans ce cas, ça n'est pas sur une valeur de 1 à 100 qu'il faut classer, mais sur un très long entier.

Et là-dessus on fait le ménage:
$query = "DELETE FROM $table WHERE date < DATE_SUB(NOW(),INTERVAL 7 DAY) OR visites <= $visites_min";

J'avais mis un AND, et non un OR. Puisqu'ici, on détruit purement et simplement les referers des articles à faible traffic, et donc le calcul de popularité, puisqu'on ne laisse même pas le temps d'accumuler sur 7 jours au moins quelques "petits" referers. Et au bout de 7 jours on efface tout, y compris le referer énorme qui alimente en visites énormes tous les jours le même article, mais depuis une semaine

On détruit tout parce qu'on veut pouvoir contrôler l'espace-disque.
J'ai bien compris que tu t'en foutais, c'est pour ça qu'à un moment
sur uzine il y avait une instance des visiteurs qui avait bouffé
150 Mo (et tu t'étonnais que ton site passe son temps à planter :-)).

T'es gentil: dès la première version que j'avais installé du nouveau système de comptage, la première préoccupation était que ça ne bouffe pas trop de place. Mais ma fonction d'optimisation était certainement trop lourde (je veux bien le croire), donc remplacée. De là à conclure que je m'en fous...

Pour uZine, non je ne me suis jamais étonné d'un plantage; et je ne l'avais même pas constaté, je l'ai appris le lendemain. Quant aux instances du système d'indentification, j'ai pas souvenir d'être pour quoi que ce soit dans le développement de ce système.

Je viens de refaire un système de calcul de popularité, qui intègre mes remarques du mail précédent

Plus exactement, plutôt que de fignoler l'existant, tu as rebalancé
un nouveau bousin totalement différent (et qui balance une erreur de
syntaxe ;-)). C'est pénible....

Oui, j'ai eu le même sentiment quand tu as écrasé mon premier système, qui fonctionnait depuis 1 mois et demi sur uZine sans problème, avec un mode de calcul totalement nouveau plutôt que d'améliorer l'ancien, et sans expliquer ni pourquoi l'ancien ne convenait pas, ni comment fonctionnait le nouveau.

Mais là, j'ai pris le temps d'expliquer les défauts du système ancien, et le fonctionnement du nouveau.

Et pour résumer, on n'a toujours pas de mesure de la popularité
instantanée, mais un agrégat incompréhensible fait d'additions
de visites récentes, de visites totales et de referers récents,
le tout avec des coefficients bizarres et des règles folkloriques.
(du genre : $age = intval(2 * ($row['age'] + $diff) / 3) )

Lire mon message d'explication, les 3 étapes successives sont expliquées, le code est simple et commenté.

Quant à l'erreur de syntaxe, désolé, je me suis gourré dans mon copier-coller.

ARNO*

Oui, j'ai eu le même sentiment quand tu as écrasé mon premier système, qui fonctionnait depuis 1 mois et demi sur uZine sans problème, avec un mode de calcul totalement nouveau plutôt que d'améliorer l'ancien, et sans expliquer ni pourquoi l'ancien ne convenait pas,

Oui, sauf qu'il y avait un bug qui traînait depuis un mois dans Mantis
expliquant que le système était trop lourd (environ quatre requêtes SQL
par article publié). Et pour avoir un système léger, il fallait bien le
réécrire en partie.

Pour le reste, désolé mais une mesure de popularité récente est largement
plus intéressante qu'une mesure globale qui ne permet de déduire aucune
information précise. Et pour le nivellement, suffit de rajouter un sqrt().