Comment fair un meilleur PH ?

Coucou tout le monde, j'aimerais parler un peu ici du PH.
J'adore toujours autant le faire, mais je me disais que ce serait bien d'avoir votre avis sur de possibles améliorations.
Et j'aimerais vous expliquer aussi un peu la difficulté d'estimer qui progresse le mieux.

Donc voilà, si vous avez des suggestions, envoyez !

Et sinon, je m'en vais vous expliquer ici-même comment et pourquoi je fais le top/bottom de la semaine.

Premièrement, le but ici est d'évaluer qui, chaque semaine, progresse le mieux/ a le mieux jouer en quelques sorte.
Pour ce faire on a accès à leur nombre de point et leur classement général.

Le premier moyen qui vient en tête c'est de comparer de façon brute la croissance (le nombre de points gagnés).
Mais ce n'est pas du tout pertinent car là où Preda, 33ème de l'uni, fait facilement 20K points par semaine, Fougère en bon 500ème ne peut en faire autant.
Du coups une autre iddé, un peu meilleur est de se dire : plutôt que de comparer la croissance absolue, on peut comparer la croissance relative. C'est-à-dire la croissance par rapport au nombre de points déjà gagnés.
On passe à des pourcentages.
Mais là encore ce n'est pas parfaitement pertinent car les petits joueurs ont souvent de grosses croissances relatives, et les gros joueurs de petites croissances relatives.
Dans les vieux uni, les top 100 sont SUPER heureux quand ils font 1% de croissance, ils ne sont pas pour autant moins bon joueurs que les top 200 qui font pourtant mieux en moyenne.

Le problème ici c'est que la croissance dépend beaucoup du nombre de points déjà acquis, et cette dépendance n'est pas linéaire (sinon la croissance relative serait plus ou moins la même partout dans l'univers).

Du coups la meilleure manière d'évaluer un joueur c'est de le comparer à ses voisins, ceux qui ont plus ou moins le même nombre de points. Et comment on fait ça ? "Simplement" en regardant le classement général !
Mais là encore un problème se pose : les joueurs avec peu de points sont très proches, et dès que l'un d'entre eux est un peu meilleurs que les autres, il gagnes beaucoup de places d'un coups.
Alors que dans le top 50 par exemple, les places sont beaucoup plus chères ! Les joueurs ont des scores très espacés, du coups quand un joueur haut niveau est meilleur que les autres, puisque l'écart entre chacune est immense, cela ne se voit pas forcément sur une ou deux semaines.
C'est pourquoi par exemple Preda se plaints d'être dans le bottom alors qu'il est souvent super bien classé sur War Rider.
Pour légèrement corriger ce problème j'ai introduit une progression RELATIVE aux places.
En gros, si vous gagnez 10 places dans le top 100 ce sera 5 fois mieux que si vous gagniez 10 places dans le top 500.
Je le calcule comme cela :
(place de cette semaine - place de la semaine dernière) / (place de la semaine dernière)
Et je l'exprime en pourcentage. Remarque : si vous gagnez des places ce pourcentage devient négatif. Plus le nombre est grands dans les négatifs, meilleurs vous êtes.

Bien sûre il existe une meilleure manière de procéder à laquelle j'ai réfléchie mais qui est inapplicable sans un peu de programmation.
L'idée est la même que plus haut : comparer la croissance d'un joueur par rapport à celle de ses voisins. Mais on peut le faire autrement qu'en regardant juste le rang du joueur dans le classement, si on a les points de tout le monde (de la semaine en cours et de la semaine passée), on peu directement comparer la croissance d'un joueur à celle de ses voisins.

La méthode que je propose est la suivante :
On va faire le rapport entre la progression du joueur et une moyenne des progressions des autres joueurs.
Je dis UNE moyenne et pas LA moyenne car on ne va pas faire une moyenne 'standard', non on va faire une moyenne pondérée.
N'ayez pas peur de ce mot, en fait c'est simple. Au collège vous aviez des matières qui comptaient plus que d'autres, les matières avait des coefficients selon leur "importance". Ainsi les math étaient coeff 4 et les arts plastiques coeff 1.
Cela signifiait que les math comptaient 4 fois plus dans la moyenne.
On va faire pareille ici, on va donner plus d'importance à la progression des joueurs qui ont un score proche du joueur que l'on cherche à évaluer, et une importance plus faible aux joueurs qui ont un score éloigné.
Plus précisément on va donner à la croissance d'un joueur X le coefficient suivant : 1/(1 + nb points de X - nb points du joueur à évaluer)²
Deux-trois précisions :
_ Pourquoi l'inverse ? Et bien comme ça, plus X est éloigné, moins sa croissance compte dans la moyenne.
_ Pourquoi le carré ? Pour ne pas avoir de coefficients négatifs, et pour être sûre de ne pas, ou très peu, prendre en compte les joueurs éloignés.
_ Pourquoi +1 ? Pour éviter de diviser par 0.

Voilà, je pense que cette version d'évaluation d'un joueur serait parfaite, mais elle implique de connaitre chaque semaine le nombre de points de TOUT les joueurs de l'univers, ou du moins, disons des 20 voisins les plus proches de chaque joueurs de l'alliance.
Il est nécessaire pour faire ces calculs d'importer ces données depuis Ogame, et c'est chiant et il faut programmer tout ça.
Même si Ogame facilite l'accès à ces donnés que vous pouvez retrouver ici :

- ID et statu : s138-fr.ogame.gameforge.com/api/players.xml - Fréquence maj: 1 fois par jour
- Position : s138-fr.ogame.gameforge.com/api/universe.xml - Fréquence maj: 1 fois par semaine
- Joueur précis : s138-fr.ogame.gameforge.com/api/playerData.xml?id=n°ID - Fréquence maj: 1 fois par semaine
- Classement joueur : s138-fr.ogame.gameforge.com/api/highscore.xml?category=1&type=1 - Fréquence maj: Chaque heure
- Classement alliance : s138-fr.ogame.gameforge.com/api/alliances.xml - Fréquence maj: 1 fois par jour
- Pour les types de classements: s138-fr.ogame.gameforge.com/api/highscore.xml
- Options du serveur : s138-fr.ogame.gameforge.com/api/serverData.xml - Fréquence maj: 1 fois par jour
- Traductions : s138-fr.ogame.gameforge.com/api/localization.xml Ajouté dans la version 5.3.0 (Remplace techNames.xml)
- Liste des serveurs : s138-fr.ogame.gameforge.com/api/universes.xml - Ajouté dans 5.5 - Fréquence maj: 1x/j


Voilà je crois que j'ai tout dis ^^

Je suis trop nul en maths pour vraiment t'aider, mais je pense qu'on a tous conscience qu'il y a pas de méthode parfaite.
Perso ce que je préfère c'est constater la progression générale de l'alliance avec ta petite touche perso, je sais généralement qui sera dans le top chaque semaine eu égard au temps passé sur le jeu (et au classement plus ou moins élevé). Les mieux classés ont aussi eu leur heure de gloire un temps, après tout !

Peut-être qu'un matheux saura affiner ta méthode de calcul, y a peut-être même des ingénieurs chez les epfl qui passeraient par là, qui sait !
Certains ont pu faire des classements similaires sur d'autres unis avec une méthode légèrement différente, tu as essayé de regarder ?

Vu que j'ai une licence de math j'ai déjà les compétence d'un matheux, le pouvoir féminin en plus !
Par contre je n'ai pas, en effet, tenter de regarder ce qui pouvais se faire ailleurs.

On s’est posés la même question à l’EPFL
Depuis le début de l’alliance, on fait des classements mensuels sous forme :
- de la progression relative (%age des points gagnés par rapport aux points totaux de chaque membre) : là le classement correspond +/- à l’inverse du classement réel des membres dans l’univers.
- De la progression brute (nombre de points gagnés dans le mois) : là, le classement suit généralement +/- le classement réel des membres dans l’univers.
Ni l’un ni l’autre ne sont représentatifs de la progression réelle des joueurs. Du coup, j’ai personnellement opté pour la solution la plus simple : arrêter de faire des bilans de progression !

Ta formule semble pertinente, après…. seule l’expérience permettra de déterminer si le classement obtenu dans la pratique est vraiment significatif de la progression des joueurs ! Deux petites critiques cependant:

1- Le résultat obtenu va peut-être pas mal dépendre des voisins et donc laisser une part aléatoire plus importante. Notamment si beaucoup de nos voisins sont en mv… Pour optimiser ça, je pense qu'il faudrait ne pas tenir compte de tous les joueurs qui sont restés en mv toute la semaine en question.

2- Tu fais quoi si nb points de X = nb points du joueur à évaluer ? En dehors de ce cas de figure extrême, si 2 joueurs sont vraiment très proches en points, le calcul de la progression du joueur à évaluer risque de n'être impacté que par celle du joueur X, le coef de tous les autres joueurs étant alors négligeable... Donc dans ce cas, si le joueur X est vraiment super super fort, même si le joueur à évaluer est bon, bah il aura une progression pourrie. Et inversement si X fait une semaine complètement nulle. A mon avis, il faut fixer un seuil au-delà duquel les coefficients à appliquer seront les mêmes. Je mettrais bien ce seuil à 10%. Tous les joueurs ayant entre 90% et 110% du total de points du joueur à évaluer auraient alors le coefficient 1/(10% nb de points du joueur à évaluer)²

Par contre ça te demandera sûrement un peu de travail pour calculer tout ça, c’est sûr… Même si avec un petit niveau en informatique ça doit bien se faire, et une fois que le code est écrit, les MAJ chaque semaine seront faciles !

Perso par contre je trouve qu’un classement par semaine c’est beaucoup, à partir d’un moment, pour des comptes mineurs, rassembler les ressources pour monter une seule mine peut déjà prendre une semaine (…voire plus pour les mineurs les plus opiniâtres !)

Salut les Gardiens!
En effet question très intéressante, et Iguana a été plus rapide que moi pour répondre^^
C'est cool de voir que nous ne sommes pas les seuls à se poser ce genre de questions un peu pointues pour essayer de faire des podiums et récompenser les plus assidus.
Visiblement Bacrima tu as poussé la réflexion plus loin, et ce n'est pas pour en déplaire à notre statisticien à écailles

Je vous laisse discuter des détails techniques, mais je suivrais votre échange avec curiosité, car si vous trouvez une méthode quasi parfaite, nous pourrions vous l'emprunter pour continuer nos bilans mensuels

PS : quel site de stat préfères-tu pour récolter les données, vu que je ne vois pas le lien dans le post original?

PPS : si je comprends ce que dit Iguana, il suffit en effet d'une exception dans les voisins proches du joueur à évaluer pour risquer de fausser son score. Dans ce cas, pourquoi ne pas faire machine arrière à propos de la pondération, et comparer sa progression avec la progression "moyennée" de tous ses voisins en même temps? Ainsi diluer une exception dans un lot comprenant les 5 joueurs au dessus et les 5 en dessous du joueur à évaluer permet de limiter la casse non?
Désolé si c'est à peine compréhensible je suis chimiste pas mathématicien xD

Merci pour vos réponses ^^

Alors pour répondre à Iguana :

Iguana a écrit:

Le résultat obtenu va peut-être pas mal dépendre des voisins [...] .

En même temps c'est l'idée.

Iguana a écrit:

[...] il faudrait ne pas tenir compte de tous les joueurs qui sont restés en mv toute la semaine en question.

En effet très bonne suggestion !

Igiana a écrit:

Tu fais quoi si nb points de X = nb points du joueur à évaluer ?

Très bonne question, quand j'avais réfléchi au problème la première fois j'ai tenu compte de ce cas de figure en ajoutant 1 à la différence, évitant ainsi la division par 0. Mais j'ai perdu mes notes :-(. Du coups j'ai réécris ça de tête et j'ai oublier ce détail.
J'ai corrigé mon post du coups, merci d'avoir relever l'erreur ;-).

Igiana a écrit:

si 2 joueurs sont vraiment très proches en points, le calcul de la progression du joueur à évaluer risque de n'être impacté que par celle du joueur X, le coef de tous les autres joueurs étant alors négligeable... Donc dans ce cas, si le joueur X est vraiment super super fort, même si le joueur à évaluer est bon, bah il aura une progression pourrie. Et inversement si X fait une semaine complètement nulle. A mon avis, il faut fixer un seuil au-delà duquel les coefficients à appliquer seront les mêmes. Je mettrais bien ce seuil à 10%. Tous les joueurs ayant entre 90% et 110% du total de points du joueur à évaluer auraient alors le coefficient 1/(10% nb de points du joueur à évaluer)²

Je vois, on aurait alors la formule : MINIMUM( (1/(1 + nb points de X - nb points du joueur à évaluer)²) ; 0.1)
Mais en fait même là le problème se pose :s.
Le joueur très proche aurait un coefficient de 0.1 au maximum, mais si tout les autres joueurs sont à une distance d'au moins 1.000 points, leurs coefficients seraient d'au plus 0.001 :-(
Mais maintenant que tu m'y fais penser c'est un problème très embêtant . Peut-être qu'en prenant comme poids une gaussienne centrée sur le joueur à évaluer, mais reste à choisir la variance de cette gaussienne. Peut-être en faisant en sorte que la demi-largeur de la-dite gaussienne englobe les 10 joueurs les plus proches.
C'est un peu (beaucoup) bricolé mais cela évitera les absurdités qui arrive avec ma formule actuelle.
Mais en y repensant faire ceci est presque équivalent à ce que propose Anquietas, j'y reviens plus bas.

Igiana a écrit:

Perso par contre je trouve qu’un classement par semaine c’est beaucoup, à partir d’un moment, pour des comptes mineurs, rassembler les ressources pour monter une seule mine peut déjà prendre une semaine (…voire plus pour les mineurs les plus opiniâtres !)

Oui, pour les plus haut joueurs c'est pas ce qu'il y a de plus pertinent, mais dans notre alliance c'est encore pas trop incohérent de le faire hebdomadairement.



Pour répondre à Anquietas:

Anquietas a écrit:

quel site de stat préfères-tu pour récolter les données, vu que je ne vois pas le lien dans le post original?

J'avais mis une balise hide pour réduire la taille du post et permettre seulement aux plus curieux de consulter les liens, mais je n'avais plus pensé qu'elles n'étaient pas visibles pour les non-membres. Je ne m'attendais pas à avoir de réponse de l'extérieur de l'alliance en fait ^^.

Anquietas a écrit:

si je comprends ce que dit Iguana, il suffit en effet d'une exception dans les voisins proches du joueur à évaluer pour risquer de fausser son score. Dans ce cas, pourquoi ne pas faire machine arrière à propos de la pondération, et comparer sa progression avec la progression "moyennée" de tous ses voisins en même temps? Ainsi diluer une exception dans un lot comprenant les 5 joueurs au dessus et les 5 en dessous du joueur à évaluer permet de limiter la casse non?

C'est une très bonne idée en fait !
Mais pourquoi 5 joueurs ? C'est peut-être pertinent pour les haut niveau, mais pour les bas niveau c'est plutôt un entourage de 50 joueurs qu'il faudrait prendre.
En fait on pourrait plutôt prendre tout les joueurs qui on entre 2 fois plus et 2 fois moins de points que le joueur à évaluer.



En réfléchissant bien à tout ça j'ai peut-être une idée qui résout un peu ces problèmes de voisinage.
La source du problème c'est que mon coefficient se base sur une différence absolue entre les points des joueurs.
Je propose donc ce simple énoncé :
Si X a 2 fois plus ou 2 fois moins de points que le joueur à évaluer, alors il devrait compter 2 fois moins dans la moyenne.

Comme cela si X est très proche du joueur à évaluer, son coefficient sera au maximum de 1 tandis qu'un joueur qui a dix fois moins de points aura un coefficient de 0.1, et un qui a 100 fois moins de points aura un coefficient de 0.01.

Pour faire ainsi le coefficient est donc :
_ (points du joueur à évaluer) / (points de X) Si X a plus de points que le joueur à évaluer.
_ (points de X) / (points du joueur à évaluer) Si le joueur à évaluer a plus de points que X.

Mais là le problème est que je donne trop d'importance aux petits scores (qui sont tellement nombreux qu'ils compensent leur petits coefficient).
Du coups la meilleure solution que je vois est de couper dans le vif. On garde ces coefficients là mais on ne les appliques qu'au X qui ont au plus (respectivement au moins) 2 fois plus (resp. 2 fois moins) de points que le joueur à évaluer.

Je suis pas plus mathématicien que toi Anqui !

Alors pour répondre à tes réponses Bacrima :

1- Oui, c'est l'idée que ça dépende des voisins. Mais les voisins n'ont pas non plus une progression régulière, donc t'as beau faire une super semaine, si tes 10 voisins ont tous décidé de passer leur astro cette semaine là, tu vas te retrouver loin au classement, c'est ça que je voulais dire pour le côté aléatoire.

2-

Bacrima a écrit:

Je vois, on aurait alors la formule : MINIMUM( (1/(1 + nb points de X - nb points du joueur à évaluer)²) ; 0.1)

Nope, ce que je proposais c'était plutôt MINIMUM( (1/(1 + nb points de X - nb points du joueur à évaluer)²) ; (1/(1 + 0.1* nb points du joueur à évaluer)²))

C'est bien 10% du nombre de point du joueur à évaluer, sinon effectivement ça pose problème, là normalement on s'approche un peu plus de la Gaussienne (même si on est d'accord, on en est encore loin ^^)

3- Oui, la méthode d'Anquietas est correcte : elle a l'avantage d'être plus simple, mais en devient forcément moins complète. Et c'est difficile de savoir combien de joueurs au-dessus et en-dessous au classement prendre. Même avec 5 joueurs, tout le monde n'a pas forcément 5 joueurs devant lui au classement, et n'a pas non plus envie d'être comparé à Netrox alors qu'il a 2 fois plus de points ! xD
C'est une méthode qui fonctionne mieux pour les classements un peu plus bas, en prenant une cinquantaine de membres autour du joueur à considérer.

4- C'est fou, j'allais te proposer exactement la même chose comme nouveau coefficient :
min(x/y, y/x)²
A cela près qu'effectivement, j'aurais tout de même rajouté un carré pour diminuer encore l'importance des petits scores. Mais tu as raison, tenir compte uniquement des joueurs qui ont 2 fois plus/moins de points peut être une meilleure solution !

Cool !!
Un membre des gardiens (Je suis une fougere) va écrire un script pour récupérer les infos et faire les calculs, je lui donne du pseudo-code et je le laisse faire.
On l'encourage !!

Vu que le tchat d'Ogame est limité à 2000 caractère je poste ici le pseudo-code pour Fougère.


Ce serait génial d'avoir un fichier conf dans lequel on saisi le numéro de l'univers voulue et le TAG de l'alliance que l'on souhaite évaluée.


Pour commencer il faut un script qui créé un fichier sur l'ordinateur pour stocker les données de la semaine, appelons-le "highscore-Date.txt". (Ce serait bien que son nom contienne la date pour choisir le plus récent à chaque fois et ne pas écraser les données bêtement chaque semaine.)
Donc celles de cette adresse :

https://s138-fr.ogame.gameforge.com/api/highscore.xml?category=1&type=0

Si tu peux, utilise le fichier de conf pour récupérer le numéro de l'univers et l'introduire dans l'adresse. (pour nous c'est 138).



Ensuite il faut le script qui va faire tout le boulot à partir, entre autres, des données de la semaine passée (donc dans le fichier).

J'ignore comment sont structurées les données récupérée mais je vais supposer qu'elles sont dans un tableau de trois colonnes et plus ou moins 1500 lignes (une par joueur dans l'univers).
Dans la première colonne la position du joueur, dans la seconde son id, dans la troisième son score.

La première étape est de récupérer les données de la semaine passée depuis le fichier highscore.txt et d'ajouter une colonne au tableau pour y introduire la progression. (on est rendu à 4 colonnes)
On récupère ensuite les données du jour à la même adresse que plus haut.
Puis pour chaque joueur du premier tableau on calcul sa progression. Il faut chercher l'id du joueur dans le nouveau tableau puis faire son score actuel moins le précédent et ajouter ceci dans la colonne "progression" du premier tableau.
(P.S. pour optimiser la recherche tu peux trier le nouveau tableau par id, de toutes façon on ne s'en sert plus après)

Ensuite il faut créer la liste des id des joueurs de l'alliance à évaluer à partir de cette page : https://s138-fr.ogame.gameforge.com/api/alliances.xml
Il faut chercher l'alliance à partir du TAG de celle-ci, disponible dans le fichier conf. (Pour nous c'est "Gardien".)

C'est maintenant que les choses sérieuses commencent.
Créé un tableau de trois colonnes contenant les id des joueurs à évaluer, leur nom et leur "évaluation".
(P.S. pour récupérer le pseudo d'un joueur c'est ici : "https://s138-fr.ogame.gameforge.com/api/playerData.xml?id=" en ajoutant l'id à la fin.)
(P.P.S : désolé pour les underscore tout moche, ils n'affichait ni les espaces ni les tabulations :-( )


Pour chaque id de joueur à évaluer:

___//Il faudra créer la fonction "position" qui renvoient la position du joueur
___//à parir de son id, ainsi que "progression" et "score" donnant la
___//progression et le score à partir de la position.
___//La fonction dernier renvoi la position du dernier joueur du tableau.
___
___long posJoueur = position(id);
___long scoreJoueur = score(posJoueur);
___long progX = 0;
___long posX = posJoueur;
___long scoreX = scoreJoueur;
___long dernier = dernier();
___float sommePond = 0.0;
___float diviseur = 0.0;
___float evaluation = 0.0;
___
___if (posJoueur != 1) {
______while ( (posX > 1)  &  (scoreX < 2*scoreJoueur ) ){
_________posX += -1;
_________scoreX  = score(posX);
_________progX = progression(posX);
_________sommePond += progX * (min(scoreX/scoreJoueur;scoreJoueur/scoreX))^2 ;
_________diviseur += (min(scoreX/scoreJoueur;scoreJoueur/scoreX))^2;
______}
___}
___
___posX = posJoueur;
___scoreX = scoreJoueur;
___
___if (posJoueur != dernier) {
______while ( (posX < dernier)  &  (scoreX > scoreJoueur/2 ) ){
_________posX += 1;
_________scoreX  = score(posX);
_________progX = progression(posX);
_________sommePond += progX * (min(scoreX/scoreJoueur;scoreJoueur/scoreX))^2 ;
_________diviseur += (min(scoreX/scoreJoueur;scoreJoueur/scoreX))^2;
______}
___}
___
___evaluation = sommePond/diviseur;
___on ajoute l'évaluation au tableau du joueur actuellement évalué.

Fin Pour.

Pour terminer créer un fichier evaluation-Date-Date.txt qui donne chaque joueur et son évaluation entre la date du jour et la date du fichier utilisé. Puis exécuter le premier script pour enregistrer les nouvelles données de la semaine dans un fichier highscore-Date.txt

Ajout de dernière minute (enfin, après au moins 40 éditions de mon message plus haut quand même).
Ce serait cool que le fichier conf contienne une variable duréeEvaluation.
Comme cela le script choisirait le fichier highscore le plus récent parmi ceux âgés d'au moins duréeEvaluation jours.
Cette variable correspond à la durée minimum sur laquelle on veut évaluer les joueurs.
Cela permet de régler ça sur 1 semaine, ou 1 mois par exemple.
Enfin, encore faut-il avoir pensé à enregistrer les données le mois/semaine précédent(e).

Il me semble qu'il y a un probleme Bacrima avec la  fonction progression(posX) qui donne la progression en fonction de la position dans le classement. On est d'accord pour dire que la position, le score on le récupère dans  le tableau avec les dernières informations (celle du jour actuel)?
Or la progression est enregistré dans le tableau avec le classement de la semaine dernière (comme demandé).

Du coup quand tu demande la progression à une position X, je regarde sur le tableau de la semaine dernière (ce qui ne correspond pas au même joueur).

Dois-je donc enregistrer plutôt la progression dans le tableau avec le classement du jour afin de récupérer la progression de la mime personne ?


Tout ça prend forme encore un petit effort et Dimanche on aura un joli PH =) Bonne journée

Hâte de voir le résultats de vos manips dont je ne comprends pas grand chose en tout cas

Non fougère, la position et le score on le récupère dans les données les plus anciennes !

Le tableau à créer contient :
_La position de la semaine dernière
_Le score de la semaine dernière
_L'id du joueur
_La progression (score actuel - score de la semaine dernière)

Je me rends compte que j'ai merdé, il manque un truc à l'algo XD
En fait la vrai évaluation se calcule en divisant la progression du joueur concerné par la variable que j'ai appellé evaluation. En fait la variable évaluation actuelle donne la progression moyenne des joueurs autour du joueur à évaluer.

Les premiers résultats de Fougère :


C'est génial !
Pour l'interprétation :
Si tu as 2 tu es en moyenne 2 fois meilleurs que tes voisins durant le laps de temps choisi pour l'évaluation.
Si tu as 1 tu es en moyenne aussi bon que tes voisins.
Si tu as 0.5, tu es 2 fois plus mauvais !