Calcul des points : la faille

Alors, après 2 semaines et demi sur ces tableaux, qu'est-ce que vous en pensez ?

Une question : c'est normal qu'on peux avoir - de 100 points records ?

Djon :

Une question : c'est normal qu'on peux avoir - de 100 points records ?

Bien sur ! Tu trouves cela pas normal ?

Non c'est parce que j'avais cru voir quelque part qu'on voulait mettre 100 minimum pour le dernier

niconoe :

J'attends beaucoup de retour sur ce doc, afin qu'on puisse vraiment savoir si vous trouvez des incohérence, etc...

si on cherche une nouvelle formule, c'est qu'il y a quelque chose qui ne va pas avec la formule actuelle, si j'ai bien suivi, il y a deux soucis avec la formule actuelle:
1)à partir de 340 ou 350 membres, le dernier marque 0 point
2)si on regarde le score du dernier joueur en fonction du nombre de joueurs, il décroit, puis recroit avant de décroitre à nouveau.
il me semble que ce sont là les deux reproches faits à la formule actuelle, or, quand on regarde tes tableaux niconoe:
1) on ne voit les scores que pour 200 membres, donc difficile de savoir ce qui se passe au delà.
2) on constate le même phénomène qu'avec la formule actuelle, exemple du score du dernier pour k=22:
de 1 à 7 posts, son score croit, logique, c'est voulu pour inciter les membres à poster leurs scores sur des records où il y a peu de posts.
de 7 à 38, son score baisse, logique, il s'enfonce dans les profondeurs du classement.
le problème, c'est qu'au delà de 38 membres, le score du dernier remonte en flèche (pic à 1136).
3)la base de 1000 me parait trop, nous sommes tous attachés à la base 100, et je pense qu'il faudrait la garder, avec une base 1000, le leader du site aura bientôt 100 millions de points...

après, je trouve que la distribution des points est bonne, et le score nul est atteint à partir de 23 membres, ce qui est très bien.
en fait, pour résumer, je trouve cette formule ni mieux, ni moins bien que l'actuelle, et comme nous cherchons la formule parfaite, pour moi, elle n'en est pas!

Merci pour ces retours, au moins, ça me permet d'avancer...
Pour ton 1) sur ma formule, j'ai fait un test pour k = 1 et le dernier sur 500 marque 67 points.

La base 1000 a été choisie pour permettre d'éviter de tomber trop vite vers 0 : plus on démarre de haut, plus on peut s'étendre... je pense que la base 100 n'est pas assez souple et qu'il faut pour moi, la monter à une base 1000.
Je vais essayer de trouver un moyen de réduire les écarts pour faire en sorte que la \"courbe du dernier\" ne soit pas ↑↓↑, mais juste ↑↓... et pour ça, j'ai du boulot, mais une petite idée aussi :)

Au passage, aucun score nul n'est attribué : les 0 sont présent uniquement pour révéler l'impossibilité (24ème / 23 par exemple) :)

Ah j'avais complétement oublié... Voyons donc :

Je pense que ma base 1000 n'est pas à conserver, nous tenons tous à la base 100. Cependant, si tu pars d'une base 1000 et que tu divise par 10 au final, d'un côté tes calculs seront en base 1000, et de l'autre on aurait nos scores en base 100, nan ?

Si oui, va falloir trouver un moyen pour éviter les vagues du dernier...

67 points sur une base 1000, c'est vraiment pas beaucoup, mais en même temps 500°/500, on peut le dire, c'est un score de m**de! donc \"why not\".
après, Okamiama77 a raison, nous tenons tous à conserver la base 100.
j'avoue ne pas m'être penché sur ta formule niconoe, mais si je regarde les chiffres de tes tableaux, et que je les divise tous par 10, ça devrait marcher ou non (à cause des arrondis...) ?

Le problème vient effectivement des arrondis :
être 500/500 => 67 pts en base 1000 => 7 points en base 100
être 499/499 => 68 pts en base 1000 => 7 points en base 100

Voila se dont je parlais quand j'employais le terme de \"souplesse\". Et puis, je pense que le concept de base 1000 n'est pas si difficile à appréhender que cela : tous les multiples utilisés pour tous les unités finissent par aller de 1000 en 1000, nous comptons très souvent en \"kilo\" et non en \"hecta\"

Je pense surtout que c'est une question d'habitude pour cette base, et je souhaiterais conserver cette base de 1000 car cela permet la souplesse de l'échelle sans pour autant aller taper dans des milliards de points...

Nous comptons bien en hectares pourtant

Je pense que l'on devrait d'abord trouver une formule presque parfaite puis après se pencher sur les bases...

Je pense au contraire que la modification de la base de poit nous permet une meilleure visibilité dans la souplesse de la formule...
J'ai une idée pour l'améliorer mais je n'ai pas encore eu le temps de la tester avec mes développement en cours... Si un matheux de service veut bien me donner un coup de main et me proposer une amélioration que je puisse retenter ce genre de tableau, ça serait idéal !

Merci !

Tu as peut-être raison...

J'aurais bien aidé mais j'ai peur de ne pas m'y connaître suffisamment ^^
Bonne chance à toi en tout cas

niconoe, as-tu trouvé quelque chose d'intéressant ?

Il va falloir ré-envoyer ton tableau, MU n'étant plus là, pour que l'on puisse de nouveau travailler dessus.

Après réflexion, peut-être devrions-nous effectivement passer en base 1000. Nous sommes tous attachés à cette base 100, mais je pense que nous arriverons à nous habituer à cette nouvelle base avec le temps.

Pour te répondre après 2 mois d'attente, je n'ai pas pu aller plus loin dans ma recherche de formule parfaite car à chaque fois, tout devient trop compliqué pour mon cerveau qui supporte de moins en moins les maths...

Je pensais à une formule toute bête du coup, un truc du genre base*nbJoueurs / position mais les écarts sont un peu chaud...

Si c'est encore possible, pourrait on voir le top 100 points avec l'ancienne formule ?

Est-ce que tu as malgré tout toujours ton tableau ?

@Djon : Tu veux voir Tails à 10M de points ?

niconoe :

Pour les scores qui combinent plusieurs score/temps, j'avais déjà répondu plus haut :P.

Mais je comprends la problématique que tu soulèves shark : mon idée prennait en compte les scores d'un point de vu relatif mais si l'on joue sur une accélération ou décélération de vitesse de croissance des points d'un jeu, la relativité ici n'est plus correctement respectée.

Je suis actuellement en train d'étudier la formule de TigrN :

f(i,n) = C*n*(1+(0,21*(i-1)-0,0025*(i-1)²)/k)^(-k) pour 1<=i<40
f(i,n) = C*n*(1+(0,01*(i-1)+4)/k)^(-k) pour i>=40
Avec:
f(), l'application qui donne le nombre de points à attribuer sans prendre en compte les égalités ;
i, la position du joueur ;
n, le nombre de joueur ;
C, la constante initiale (actuellement C=100 mais pour plus de précision lié aux divers élément de cette formule, on pourrait imaginer C=1000 ou C=10000)
De manière générale, un joueur seul sur un score gagne C ptsRecord
k, le paramètre de \"réduction de croissance d'écart\"
Plus k est grand, plus l'écart du nombre de points à distribuer entre les joueurs aux positions i et i-1 sera petit (d'après ce que j'ai compris, corrige moi TigrN si je me trompe)

Ainsi, comme je pense que le mieux serait d'avoir un écart relativement plus grands sur les premières places que sur les dernières, je propose l'utilisation de (i) comme valeur à k.
Malheureusement, mes compétence mathématiques m'empêche de savoir si le fait que k ne soit pas constant ne pose pas de problème logique à l'établissement du nombre de pointsRecords gagnés...

TigrN, peux-tu nous éclairer sur ce point ?

Citation de moi-même, désolé, ça fait un peu égocentrique, mais après avoir relu le post très constructif de TigrN, je pense qu'on est pas loin du but avec ça...

Pour rappel, se trouve ici la formule sans prendre en compte les égalités (qui seront géré par la moyenne relatives aux positions identiques).

Je reviens sur la variable la moins facile à comprendre et à déterminer : k

Pour vulgariser, plus k est petit dans cette formule, plus l'écart de point entre les joueurs sera grand, et inversement. Par exemple (valeurs fausses), avec un k = 0,000000001, on aurait un 1er à 600 points, un 2ème à 2 points, etc... tandis qu'avec un k = 10000000000, on aurait un 1er à 600 points, un 2ème à 599 points, etc...

Par conséquent, je pense que fixer cette variable à une certaine valeur n'est pas du meilleur goût : en effet, les gens se plaignent souvent que \"on ne gagne pas assez de point en montant dans le classement quand on est en bas de tableau\" ou encore \"que l'écart de points entre les premiers est trop important\". Donc, faisons varier cet écart en fonction des positions des joueurs !

Prendre, comme je le disais il y a X mois, i pour valeur à k (ou tout coefficient à multiplier à i) serait déjà un bon test à faire. Mais je me disais également que cet écart devrait être de plus en plus important en fonction également du nombre de joueur total. Du coup, (i/n) pour valeur à k (ou tout coefficient à multiplier à i/n) serait, je pense, encore plus représentatif.

Gros problème : Assure-t-on qu'une telle fonction conserve les 3 points importants signalés par TigrN, à savoir :

TigrN :

1) À n fixé, f(i,n) décroît avec i :
C'est le minimum : mieux je suis classé, plus j'ai de points.

2) À n fixé, f(i+1,n)-f(i,n) décroît avec i (convexité) :
Plus je me rapproche de la première place, plus le gain d'une seule place rapporte de points.

3) À i fixé, f(i,n) croît avec n :
Si un nouveau participant arrive et que son score est inférieur au mien, je gagne des points.

Merci de m'apporter ces précisions avant que je fasse des tests poussé pour établir un coefficient k le meilleur possible. :)


Sinon, @Djon : Il faudrait faire un recalcul, ce qui est plutôt casse c***lle
@Okami : Je n'ai plus mon tableau non, mais justement, je compte en refaire un (mieux j'espère) selon les explications de ce post.

Je vais attendre le nouveau tableau alors

Arf ok mais il n'est pas possible par exemple de changer juste la formule à un endroit sur une version de developpement de VGR et non de production pour avoir le classement ?

Si, c'est possible, mais ça demande du temps. Autant investir ce temps dans la réalisation d'une nouvelle formule plutôt que de voir à quoi ressemblait l'ancienne :)