BRM Aggressif et simulation $200-$10K Noter le sujet : 7 Votes

[Leadan]

Yop all,

je viens de m'amuser à créer un BRM très aggressif:
On move up dès qu'on à 6 BI pour la limite supérieure.
On move down dès qu'on moins de 4BI de la limite actuelle.

En gros ça donne ceci:

Limite	Move down	Move up
NL5	broke	60
NL10	40	150
NL25	100	300
NL50	200	600
NL100	400	1200
NL200	800	2400
NL400	1600	4800
NL600	2400	7200
NL1000	4200	10000

J'ai fait un petit code en C pour avoir certains résultats en partant avec des individu qui ont $200 de BR (en nl25 donc)
J'ai introduis une notion "taux de gain de cave" qui est une valeur qui est sensé représenter en quelque sorte l'edge de vilain. Cela représente le nombre de caves gagnés pour 100 caves (gagnés ou perdus). En gros le joueur qui a un taux de 50 est even, il gagne 50 caves au même rythme qu'il en perd 50.

J'ai fait 1000 test pour chaque ratio de 25 à 75 et voici les résultats:


frequenceUp c'est le fameux ratio, nbReussis c'est le nombre de fois où le challenge est réussi (l'individu à win $10k et quand il réussi pas, c'est qu'il est broke) et nbCavesMoyen c'est le nombre moyen de caves par tests (caves gagnées ou perdues). La valeur de nbCavesMoyen n'est pas répresentative mais simplement à comparer avec les autres, plus elle est petite moins il y a eu de swings et de changement de limites et plus vite le challenge a été fini.

Bref, ça montre bien qu'il y a un edge nécéssaire pour pouvoir réussir ce challenge et que plus notre edge est grand plus notre risque de ruine est petit et plus vite on finira le challenge (ça semble logique ) mais ce qui m'a frappé c'est à quel point la proba de réussir son challenge varie brutalement suivant l'edge!
En gros entre 50 et 57 c'est la que ça varie vraiment.

Après le soucis c'est que le taux dont je parlais tout à l'heure essaie de représenter l'edge mais c'est plus qualitatif qu'autre chose. Toutefois je trouvais ça tout de même intéréssant.

Au passage voici la simu lancé sur 3 tests avec une frequenceUp de 50, les 3 tests ont échoués ici (normal on voit qu'à 50 ça réussi pas très souvent). En abcisse, evolution augmente à chaque fois qu'une caves a été gagné ou perdue


Je vais essayer de faire la même choses mais à la place de raisonner en terme de caves gagnés ou caves perdues, je vais tenter de prendre en compte le winrate et la standard deviation.

Bon et sinon, le plus imporrtant, qui est in?

Ce message a été modifié par Leadan : 16 janvier 2010 - 04:21

[just1_béber]

Ouvrir ce topic à 4h30 du matin, ça pique grave les yeux.

Mais VGG pour ton taff

[Leadan]

Yeeeeeeah, trop fier de mon nouveau résultat en prenant en compte le bb/100 et la standard deviation, je quote les result vite fait avant de faire des ptit graph ou des truc comme ça.

Dans l'ordre bb/100, nb challenges réussis (1000 essai) et nombre de mains moyen (le nombre de mains est assez réaliste après je dis pas que mon truc est à 100% proche de la réalité, ce n'est qu'une simulation basé sur une génération aléatoire suivant une loi gaussienne).

L'écart type est de 50bb/100 pour cette première simu.

-5	  6	   32473
-4	  8	   38254
-3	  7	   48018
-2	  13	  61741
-1	  21	  87020
0	   37	  136702
1	   160	 226219
2	   580	 262093
3	   892	 189928
4	   966	 123632
5	   985	 92904
6	   985	 71167
7	   990	 58316
8	   990	 48112
9	   992	 41988
10	  997	 37543

Edit:
Donc voilà les résultats respectivement pour une standard deviation de 60, 90 et 120.





Bref si les résultats sont juste c'est pas super encourageant si les calculs sont juste. En gros avec une sd à 90bb/100 on à environ 1 chance sur deux de réussir sur on a un bb/100 de 6. Il faut compter en moyenne 80k mains. De plus le winrate est supposé uniforme à toutes les stakes! (quoique je pourrais modifier ça facilement).

Ce message a été modifié par Leadan : 16 janvier 2010 - 06:40

[St4t.fr]

oula. trop compliqué pour moi à cette heure ci ^^

mais c'est bien d'essayer.

[Leadan]

Et voilà pour finir un exemple avec 10 tests winrate = 6bb/100 et sd = 90bb/100 (paramètres pour lesquels on a environ 50% de réussite au challenge cf. plus haut)

Ce message a été modifié par Leadan : 16 janvier 2010 - 06:56

[qamiqaz]

good job

sinon c'est bien beau les graphs... mais faut s'y mettre now ; )

[tiresias]

ce que je retiens de ton dernier graphe c'est qu'avec ton br management, et les paramètres que tu donnes (6bb/100 --> joueur raisonnablement gagnant et une sd de 90 bb/1100) bin seule 3 joueurs parviennent au "graal"


tu pourrais essayer avec les mêmes paramètres mais un br management plus smooth (on grimpe avec 30 caves et opn descend lorsqu'on en a plus que 20 par exemple)

a priori avec ces paramètres on devrait en retrouver disons 9/10 en nl1000

d'autre part pour améliorer ton algo il faudrait tenir compte du fait que lorsqu'on monte de limite le wr diminue alors que la sd augmente. a priori en faisant ça, on va avoir moins de joueurs broke (car lorsqu'ils descendent de limite ils améliorent leur wr et diminuent la sd) , mais par contre il vont mettre un temps très grand pour rejoindre la nl1000 (ça devient plus difficile lorsqu'on monte)

ps: y'a des articles sur la sd qui trainent? je me rappelle plus comment c'est définit et sur combien de mains on peut en calculer une valeur à peu près fiable

Ce message a été modifié par tiresias : 16 janvier 2010 - 09:55

[Byshop]

Si tu veux pousser la simulation encore plus loin, faudrait que le WR d'un joueur soit en rapport avec le nombre de mains qu'il a joué et a quelle limite il les a jouées. Ceci afin de prendre en compte qu'on prend plus d'expérience en NL100 qu'en NL10 et que même si la variance a joué contre nous, l'expérience s'est toujours accumulé en notre faveur.

Tu peux aussi mettre un facteur tilt, par exemple si un joueur perd rapidement quelque caves du fait de la variances, alors son WR s'en trouve affecté.

Ce qui serait intéressant c'est de pouvoir mettre en balance la variance et le WR. Si t'arrive à démontrer qu'un jeu plus nit, donc avec un wr moins elevé en bb/100 permet, du fait d'une variance moins importantes, d'avoir un BRM plus aggro avec un RoR identique et donc un WR supérieur en $ par rapport à style de jeu plus LAG qui aurait un WR en bb/100 plus élevé t'aura résolu la problématique du BRM

Alors bonne chance

(je sais pas si j'ai été clair ?)

[pietrodito]

 Capturer.JPG (22,3Ko)
Nombre de téléchargements: 162

Est ce que bosser sur cette simulation fait gagner un peu d'équité dans les tirages COULEUR ???

Ce message a été modifié par pietrodito : 17 janvier 2010 - 02:05

[Skip]

Faudrait juste que tu adaptes l'edge à la limite et ca serait complet.

Imo si un joueur est à 6bb/100 en NL50, il sera loin des 6bb/100 en NL1000, surtout en si peu de temps.

[JoN]

plutot intéressant, je tenterais bien l'expérience sur une BR sans importance pour voir.

[Bast]

tain exactement le même brm que moi !

[Leadan]

tiresias, le 16/01/2010 à 09:47, a dit :

ce que je retiens de ton dernier graphe c'est qu'avec ton br management, et les paramètres que tu donnes (6bb/100 --> joueur raisonnablement gagnant et une sd de 90 bb/1100) bin seule 3 joueurs parviennent au "graal"

Oui mais si tu regardes sur les graphs au dessus pour les mêmes paramètres et sur 1000 essais, on arrive 500 fois au graal. Donc 50% de réussité normalement avec ces paramètres (mais là oui, sur les 10 tests, seuls 3 ont réussis)

tiresias, le 16/01/2010 à 09:47, a dit :

tu pourrais essayer avec les mêmes paramètres mais un br management plus smooth (on grimpe avec 30 caves et opn descend lorsqu'on en a plus que 20 par exemple)

Oui je peux faire ça avec plein de br management, suffit juste de donner des régles de moves down et move up. Je peux le faire avec 30 et 20 comme tu dis, et je vais peut-être essayer de le faire selon les critères de kelly (j'aurais pas le temps today).
Quelques infos en vrac sur les critères de Kelly concernant le BRM:
http://www.cardschat.com/f11/win-rates-sta...ur-edge-157433/

tiresias, le 16/01/2010 à 09:47, a dit :

d'autre part pour améliorer ton algo il faudrait tenir compte du fait que lorsqu'on monte de limite le wr diminue alors que la sd augmente. a priori en faisant ça, on va avoir moins de joueurs broke (car lorsqu'ils descendent de limite ils améliorent leur wr et diminuent la sd) , mais par contre il vont mettre un temps très grand pour rejoindre la nl1000 (ça devient plus difficile lorsqu'on monte)

Oui j'en ai parlé au dessus, je vais le faire ce sera rapide. Pas contre au contraire je pense qu'il y aura plus de broke si on diminue le winrate et on augmente la sd lors de la progression dans les limites.

tiresias, le 16/01/2010 à 09:47, a dit :

ps: y'a des articles sur la sd qui trainent? je me rappelle plus comment c'est définit et sur combien de mains on peut en calculer une valeur à peu près fiable

Rapidement j'ai trouvé ça là, qui fait un petit rappel, mais il doit y avoir des trucs bien plus détaillé sur le net.
http://jaspoker.blogspot.com/2008/10/la-vr...calculs-et.html

Byshop, le 16/01/2010 à 14:30, a dit :

Si tu veux pousser la simulation encore plus loin, faudrait que le WR d'un joueur soit en rapport avec le nombre de mains qu'il a joué et a quelle limite il les a jouées. Ceci afin de prendre en compte qu'on prend plus d'expérience en NL100 qu'en NL10 et que même si la variance a joué contre nous, l'expérience s'est toujours accumulé en notre faveur.

Yep

Byshop, le 16/01/2010 à 14:30, a dit :

Tu peux aussi mettre un facteur tilt, par exemple si un joueur perd rapidement quelque caves du fait de la variances, alors son WR s'en trouve affecté.

Euh, pas à l'ordre du jour pour l'instant, vous avez qu'à pas tilter

Byshop, le 16/01/2010 à 14:30, a dit :

Ce qui serait intéressant c'est de pouvoir mettre en balance la variance et le WR. Si t'arrive à démontrer qu'un jeu plus nit, donc avec un wr moins elevé en bb/100 permet, du fait d'une variance moins importantes, d'avoir un BRM plus aggro avec un RoR identique et donc un WR supérieur en $ par rapport à style de jeu plus LAG qui aurait un WR en bb/100 plus élevé t'aura résolu la problématique du BRM

Alors bonne chance

(je sais pas si j'ai été clair ?)

lol, je vois à peu près ce que tu veux dire. Ouais je peux me preter à plein de simulation différente. Là j'ai programmer vraiment à la rache mais si je faisais le truc bien (graphiquement, avec saisie des paramètres etc...) on pourrait très certainement rapidement tirer des conclusions.

Skip, le 16/01/2010 à 15:36, a dit :

Faudrait juste que tu adaptes l'edge à la limite et ca serait complet.

Imo si un joueur est à 6bb/100 en NL50, il sera loin des 6bb/100 en NL1000, surtout en si peu de temps.

Re-Yep, c'est ce que je vais faire en premier vu que ça à l'air unanime

[Dromz]

Le mec en rouge du premier post est vmt nul a chi**.

[tiresias]

autofail

Ce message a été modifié par tiresias : 16 janvier 2010 - 17:15

[Alex_Joy]

Moi je suis d'accord, il faut pratiquer un BR management aggressif, venez tous vite jouer en nL400.

[zemetique]

Alex_Joy, le 16/01/2010 à 17:16, a dit :

Moi je suis d'accord, il faut pratiquer un BR management aggressif, venez tous vite jouer en nL2k sur boss.

FYP

[Patrocle]

Juste pour mon info, car j'ai des articles à pondre sur le sujet, et j'aimerais les illustrer avec des graphes.
Qu'est-ce que tu utilises pour effectuer les sorties graphiques ?
Comment génères-tu les graphes ?
Si tu as du temps on peut en parler en messages perso.

[Leadan]

On peut en parler en perso, hier j'ai vraiment tout fait à la rache vite fait, j'avais rien sur mon PC j'ai installer MinGW pour compiler en C et j'ai cherché sur google un truc pour faire des plot en 2D.
J'ai trouvé ça, c'est hyper basique et pas super mais je m'en suis contenté, je pense refaire le tout propre bientôt en utilisant Qt (donc en C++) qui est un framework que j'adore

http://sourceforge.n...rojects/plot2d/
http://qt.nokia.com/products

Si tu as des articles et d'autres trucs sur le sujet c'est sympa, moi j'ai juste farfouillé un peu hier sans mettre trop penché sur la question auparavant.

[niflon]

Mais vous êtes des grands malades les mecs

non c'est classe si ça peut aider du monde ou en faire avancer certains mais balancer ça à 4h du mat, c'est chaud quand même

nolife ?!

Ce message a été modifié par niflon : 16 janvier 2010 - 18:45

[Patrocle]

Leadan, le 16/01/2010 à 18:43, a dit :

On peut en parler en perso, hier j'ai vraiment tout fait à la rache vite fait, j'avais rien sur mon PC j'ai installer MinGW pour compiler en C et j'ai cherché sur google un truc pour faire des plot en 2D.
J'ai trouvé ça, c'est hyper basique et pas super mais je m'en suis contenté, je pense refaire le tout propre bientôt en utilisant Qt (donc en C++) qui est un framework que j'adore

http://sourceforge.n...rojects/plot2d/
http://qt.nokia.com/products

Si tu as des articles et d'autres trucs sur le sujet c'est sympa, moi j'ai juste farfouillé un peu hier sans mettre trop penché sur la question auparavant.

Pour les trucs classiques, il y a le maths of poker.
Sinon, pour des trucs il va falloir attendre, mais je vais pas tarder
Je rebondis sur ta proposition: c'est un peu bourrin d'utiliser QT, non ? Il doit
quand même exister un peu plus simple pour sortir des graphes

Ce message a été modifié par Patrocle : 16 janvier 2010 - 20:04

[Flopus]

Patrocle, le 16/01/2010 à 18:19, a dit :

Qu'est-ce que tu utilises pour effectuer les sorties graphiques ?
Comment génères-tu les graphes ?

MATLAB

[Leadan]

Ouais matlab je peux l'utiliser en vpn + ssh via mon école, mais pour en mode console. Si je veux utiliser la version graphique (utile pour générer les graphs) ça rame beaucoup et c'est normal.

Sinon oui il y a forcément plein de solution et il y a beaucoup de bibliothèques graphiques que ce soit pour le C/C++/Java, c'est juste que une fois que tu connais Qt tu peux t'en servir. Apprendre à se servir de Qt juste pour ça j'avoue que c'est pas génial.
Exemple en vrac:
http://c.developpez....?page=graphique
http://plplot.sourceforge.net/

[kipik]

OP vient de me réconcilier avec l'espèce humaine

[tomasssss]

kipik, le 16/01/2010 à 23:00, a dit :

OP vient de me réconcilier avec l'espèce humaine

Maintenant il ne reste plus qu'à espérérer que l'espèce humaine se réconcilie avec toi.