C'est bien d'IA dont je parle, mais ça n'implique pas du tout de générer automatiquement du code... En gros, tu as un "prédicteur" avec des tas de paramètres, et ce sont uniquement ces paramètres qu'il faut déterminer... Tout le reste du code ne consiste qu'à effectuer cette tâche en fonction d'un critère. Et une fois que le "prédicteur" est au point, on peut ne plus toucher au code.Envoyé par Ludwig1
Intéressant, j'ai jeté un oeil sur le site en lien, ça ne m'a pas plus impressionné que cela, principalement parce que les tests ont été faits avec du hold'em . L'IA touche à tout en ce moment et c'est peut-être une bonne chose, mais dans le cas présent, c'est de PA qu'il faudrait parler. J'entends Psychologie Artificielle. Et là c'est pas gagné d'avance.
Maintenant, il est certain que l'on peut élever le niveau de nos ambitions et dépasser le vulgaire "Vidéo Poker" parce qu'avec ce dernier ni intelligence, ni psychologie ne servent à rien. La machine a engrangé une certaine somme d'argent, elle va sans doute en restituer une partie à un joueur, mais quand et à qui ? Même le programme ne le sait pas, car s'il le savait, je peux vous garantir que certains joueurs le sauraient aussi. Et ce sont plusieurs dizaines d'années à côtoyer et ces machines et ces joueurs qui m'ont appris cela. Mais je reste à votre écoute en espérant, moi aussi, apprendre des choses.
En fait je me suis trompé de lien, j'ai mis l'implémentation au lieu de mettre le lien sur le résultat. Le voici
http://www.sciencemag.org/news/2017/...t-humans-poker
Ce n'est peut-être que du texas hold'em (encore que... je vois pas en quoi c'est rabaissant), mais l'IA a battu des joueurs de renomé. Et en parlant de psychologie, l'IA a parfaitement su en jouer en bluffant ou en sachant décoder le bluff. Bref, on a toujours parlé du poker comme étant plus qu'un jeu de carte (comprendre par là impliquant aussi une psy du jeu) et l'IA est parfaitement capable de le lire ET de le reproduire avec grand brio.
L'algo d'IA pourrait d'ailleurs être adapté aux autres variantes, ça ne changerait finalement pas grand chose à la mise en oeuvre.
Je pense qu'il vaut mieux distinguer le calcul probabiliste et prédictif (que l'on peut demander au programme de faire), du style de jeu lié au bluff.
Sans la première étape, la deuxième ne sert à rien.
Et je reste convaincu de l’intérêt de trier avant l'application des tests logiques.
Ca simplifie grandement, sans parler du fait que c'est même probablement plus rapide de trier 5 Cartes que de subir les conséquences liées aux traitements d'un tableau Valeur/Couleur à deux dimensions (nécessité de le mettre à blanc etc etc).
Lorsqu'on parle d'algorithme performant de tri, il ne faut pas oublier d'autre part que la performance de ce dernier n'est que théorique... que sa performance réelle dépend de la quantité de données à trier ainsi que des performances liées au langage employé (ici, le Python).
Ah bon ? en quoi ?
Je peux te démontrer le contraire...
Complexité d'un sort : N * log(N)
Complexité d'une fenêtre courante : N
En stockant les cartes dans un tableau 2D, elles sont DEJA triées par leur coordonnées... Je trouve ça beaucoup plus simple. Sans même compter l'utilisation de l'as. Tu le mets à quelle position dans ton tri ? T'es obligé de faire plein de tests juste pour tenir compte de l'as... Avec un tableau, c'est une simple condition aux bords, hyper simple !
Comme le dit Evil.Salen, c'est faux. On parlait de complexité qui ne dépend de rien de tout ça.
Si on parle de performance dans l'absolu, dire que ça dépend du langage est toujours vrai. Et qu'elle dépend de la quantité de données est partiellement vrai... Bref, cela reste des généralités sans valeur ajoutée.
C’est une chose de trier les éléments d’une grosse base de donnée, et je comprends les réticences instinctives des pro de cette technique. Mais dans notre cas,comme LeMulet le signale, il ne s’agit que de 5 cartes. Rechigner à perdre quelques milli-secondes au début de chacune des donnes ne relève plus de la simple réticence, mais de l’aversion pure et simple.
Le problème de l’as est facilement résolu : si la première carte est un 2, que les autres sont ordonnées avec 1 comme raison et que la dernière vaut 13 (c’est un As) on a une Quinte.
Maintenant le débat semble se diriger vers un éventuel conflit entre l’usage du calcul des probabilité et celui de la prévisibilité. Autrement dit, si je ne me trompe, entre la Théorie des jeux et les stratégies exploitantes. Il est certain que la suite risque d’être intéressante mais tout de même notez que vous êtes bien loin des questions que se posait l’auteur du post. Celui ci voulait faire un Poker, vous, vous êtes déjà en train d’y jouer. Cependant, je crois le débat utile : faire une machine qui joue et qui est soumise aux lois de la Théorie des jeux, et qui donc va devoir se plier à la loi de la ruine du joueur ne peux que satisfaire son adversaire qui pourrait même se prendre pour la machine de l’expression Deus ex machina. Et contribuer à sa propre ruine !
Pour ma part j’ai plutôt opté pour la voie de la prévisibilité, ou de la stratégie exploitante comme le dit la littérature consacrée. Pourquoi ce choix ? Simplement parce qu’à la latitude à laquelle j’habite, on a tendance à croire que la solution la moins fatigante, reste la meilleure.
Ah oui je vois...
La forme plutôt que le fond.
Non, c'est le résultat qui compte (en tous cas c'est comme ça que je fais mes programmes lorsqu'il est question de performance), qui se mesure ensuite en temps réel de calcul.
Ca a déjà été montré, par le seul qui apparemment a déjà produit ce type d'application (Vérifier en ajoutant +1).
Ben oui, mais si n vaut 5... bof bof hein ?
Oui, mais il faudra effacer ce tableau avant réemploi.
Pas moi.
Si l'AS est compté comme 1 ou pas :
Celui qu'on veut...
Ce qui fait deux tests dans mon cas de figure... et deux tests dans le votre à minima aussi.
Ensuite, si vous voulez me parler de performance, et pour le cas qui nous concerne, soit 5 Cartes, il y a beaucoup beaucoup mieux, et sans tri.
Les histoires d'algorithmes c'est du snobisme à ce niveau.
C'est TOI qui parle de complexité et de vitesse, je te réponds au sujet de TON propre terrain.
Prenons un cas très concret: combien de tests il te faut pour trouver 1 paire ? Pour moi, avec 1 seul test je peux trouver : carré, brelan, full, 2 paires, 1 paire. C'est hyper simple.
Pour toi : il faut d'abbord faire un tri, tester pour les carrés (= plusieurs tests), tester pour les brelands (= plusieurs tests) et si rien ne sort, tester pour des paires. Admettons qu'il n'y ait qu'une paire, ton jeu trié est donc un de ceux là :
PPxyz, xPPyz, xyPPz, xyzPP.
4 tests en tout.
Pour tester 2 paires, c'est encore plus de tests
Mais c'est beaucoup plus simple que tu me dis
(Le ton monte sans raisons objectives autre que la facilité, dans les échanges écrits, à surinterpréter la volonté de l'autre à dénigrer sa propre personne. Connaissant ce biais, serait-il possible de faire un effort pour l'éviter?)
Un dernier mot sur le codage: je suis d'accord que celui que tu proposes est possiblement le meilleur à date pour évaluer des mains, mais si tu veux rentrer du machine learning alors il faut probablement repenser tout cela en fonction du programme visé. Par exemple, s'il y avait un convnet je suggèrerais un codage explicite de toutes les cartes selon un tableau tel que des rotations de (multiples de) 90 degrés correspondent à des permutations de couleur (tu connais probablement cette technique d'augmentation de la base de donnée, classique pour contrer le surapprentissage).
Plus important, je ne pense pas être d'accord avec ton analyse du comportement de cette IA. Pour moi elle utilise une stratégie défensive du type 'quel que soit le joueur je minimise mes pertes' plutôt qu'une stratégie offensive du type 'Voyons à quel pigeon on a affaire en l'appâtant avec des petits gains faciles et plumons le ensuite' (je crois qu'azad faisait un point un peu similaire). Pour moi cette stratégie est beaucoup plus intéressante, parce qu'elle nécessite de construire une représentation des intentions de l'autre, quitte à ce que soit 'bon lui son comportement montre que c'est un pro, je le sais, il sait que moi aussi, donc si on est tout seul je me retire, sinon on collabore pour plumer le type aux bretelles".
Le but du poker n'est pas de minimiser ses pertes, sinon on est sûr de perdre à tous les coups... Ce sera juste moins rapide en les minimisant.
Non non, le but est de maximiser le profits (gains - pertes), c'est à dire perdre le moins possible avec une mauvaise donne ET savoir faire fructifier au mieux les bonnes donnes. C'est là tout l'art du poker: tout le monde peut faire tapis avec une quinte flush royale, pas besoin d'être un champion. Le champion a 2 qualités supplémentaires: 1. il sait gagner la mise sans avoir le meilleur jeu; 2. il sait te faire miser quand il a le meilleur jeu.
Moi, je n'ai jamais parlé de complexité, mais de vitesse oui..
Peut-être n'ai-je pas compris votre proposition.
Je vais donc reformuler :
Vous proposez de faire un tableau à 2 dimensions.
Dimension 1 : Valeur
Dimension 2 : Couleur
Et vous "posez un flag à l'intersection" indiquant qu'une carte de ce type existe dans la main.
Là, déja on voit que pour la valeurs, on va avoir un problème avec l'AS.
Mais admettons.
Et donc à partir de ce tableau, vous arrivez à déterminer en 1 seul test que la main contient 1 paire ?? (faisons simple pour commencer)
Moi, je n'y arrive pas.
Maintenant, je vais vous montrer en quoi la complexité algorithmique est une notion à manipuler avec précaution, et qu'il vaut mieux comprendre ce qu'elle signifie si on veut obtenir de la performance...réelle.
Sans tri et en 1 seul test, je peux déterminer la VALEUR et le nom de la main.
Sachant que c'est la valeur de la main qui est déterminante, et que le nom de la main n'est qu'indicatif.
Je crée un tableau à 5 dimensions avec 52 entrées par dimension.
Exemple en Pascal
Je remplis ce tableau une fois pour toutes, selon les règles du jeu (qu'on peut changer à volonté).Code:Type TValeurMain = record V : byte; // Valeur de la main Nnom : byte; // Indice du nom de la main (à produire en amont bien entendu) end; Valeurs : array of array of array of array of array of TValeurMain; setlength(Valeurs, 52, 52, 52, 52, 52);
Je prend la main du joueur et recherche la valeur du tableau selon les indices de chaque type de carte (c1, c2, c3, c4, c5)
=> 1 Recherche indicée dans un tableau, même pas de test à effectuer (operation "instantanée")Code:v: TValeurMain; v:=Valeurs[c1, c2, c3, c4, c5];
Le tableau est gros, mais ça va pour 5 cartes, et il peut être compacté si on s'y prend intelligemment, si nécessaire.
De plus, l'interet d'un tel tableau, c'est de pouvoir prédire avec rapidité quelles sont les cartes à échanger pour augmenter la valeur de la main, etc, etc...
Il est où le trou ? Il est où ?
Remarquable !
J’avais au tout début de mon projet exploré cette piste car c’était la seule qui me permettait d’obtenir la solution au gros problème du Vidéo Poker. Ce problème étant de générer en fonction de l’état des "finances" du jeu quelques séquences consécutives sans aucun gain quelque soit le choix du joueur à la première donne. Ainsi les donnes 1 et 2 étaient déjà pré-programmées pour obtenir ce résultat. Et un tel tableau, même s’il occupe pas loin de 380Mo permet de sélectionner les 10 cartes ne présentant aucune combinaison gagnante quoi que l’on fasse.
Et puis j’ai abandonné pour d’autres raisons. Néanmoins il faut savoir que dans ce type de jeu il est des facteurs psychologiques très importants. Le joueur n’est pas troublé par une séquence sans gains de 6 ou 7 donnes consécutives, il a des références inconscientes et parmi elles, l’apparition d’un carré (qui paye 40 fois la mise) est importante. D’autant plus qu’il y a un Joker dans le jeu et qu’un carré complet assorti du Joker (combinaison appelée Five) paye elle mille cent fois (1100) la mise. Et on peut miser jusqu’à 8 !!!
Avec ce système le programmeur est conduit à écrire plusieurs tableaux supplémentaires uniquement composés d’une série de donnes prédéterminées conduisant à obtenir la moyenne (proportion entre les sommes entrées et les sorties dues aux gains encaissés) souhaitée par le programme. A tout hasard et pour vous éviter des essais inutiles, je vous signale que cette moyenne "instantanée" doit tourner autour de 78 % pour ne pas décourager le joueur. Avec ce pourcentage la moyenne réelle (100 OUT/IN) s’établi aux alentours de 55 %. Cela car un joueur n’encaisse pas toujours ses gains et continue à jouer, même si son compteur "crédit" grimpe à 100 fois son investissement initial voire plus. Seuls Five et QuinteFlush à l’as (500 fois la mise) l’incitent à quitter le jeu.
Mais pardon de cette digression, je revenais à mon dada.
Bonsoir les uns et les autres,
Etant donné que je ne connais pas le poker, quelqu'un voudra t'il avoir la gentillesse de m'expliquer
en quoi ça consiste afin que je puisse comprendre un peu l'aspect programmation merci par avance.
Cordialement
Ludwig
Hello, Ludwig1 !
Va faire un tour avec ton moteur de recherche, lis quelques articles et tu saisiras très vite le principe fondamental. Ce principe va ressortir assez rapidement car parmi la bonne dizaine de variantes possibles, il reste le point commun à toutes.
Comme dirait le célèbre philosophe Patrick Bruel, le poker c'est 5 minutes pour l'apprendre et une vie pour le maîtriser
Pour faire très très vite, avec la version texas hold'em, tu as 2 cartes (aléatoires) en main visible par toi seul (tes 2 seules cartes en main pour le reste de la donne). Puis le dealer (celui qui distribue les cartes) en pose 3 sur la table, visibles de tous. Puis il en pose une autre, et enfin une dernière. Après chaque distribution il y a des enchères possibles pour continuer à jouer, ou pas.
En très très bref, le but est d'avoir la meilleure combinaison possible de 5 cartes (2 en main + 5 sur la table, donc la meilleure combinaison de 5 cartes sur les 7 cartes en tout). Et voilà pour le principe.
Bien évidemment, il y a beaucoup de subtilités que je zappe ici, mais en 30 secondes tu as compris le principe de base, il te reste 4 minutes 30 pour saisir le reste et c'est vraiment pas sorcier. Tu peux jeter un oeil sur youtube et regarder une partie, en 3 donnes t'auras tout compris
Bonjour, j'ai pris connaissance de vos conseils et vous remercie du temps que vous avez consacré a nous répondre.
je pense me diriger vers un tableau comme nous l'a conseillé LeMulet, mais pourquoi 5 dimensions ? car nous avons 5 cartes ?
Auriez vous des compléments à nous apporter pour poursuivre dans cette voie ?
merci d'avance
Tout à fait, 5 cartes dans une main ça nous fait un tableau à 5 dimensions.
Chaque dimension allant de 1 à 52.
Par contre, vu la taille du tableau, il est important à mon avis d'optimiser le stoquage des valeurs.
Il faut bien choisir le format de donnée le plus adapté (malheureusement et de manière générale (je ne connais pas Python, donc à voir ici) la taille minimale des données est de 1 Octet).
52*52*52*52*52=380204032 soit environ 380 Méga Octets pour une donnée par indice de 1 octet.
La question de base est donc : Savoir évaluer numériquement la valeur d'une main.
Pour ce faire, je suggère de commencer par les valeurs les plus basses, la Hauteur, et de faire en sorte que la valeur numérique attribuée à la main rend compte de la règle suivante :
http://fr.pokerlistings.com/classeme...mains-du-poker
Vous voyez avec ce type de main que pour évaluer la valeur numérique de la main, ce n'est pas aussi évident qu'il n'en a l'air (mais c'est faisable, à mon avis)
D'autre part, vous constatez que pour remplir le tableau (qui est certes utile) avec les valeurs numériques, il vous faut quand même un algorithme d''évaluation. (Le système du tableau ne vous dispense donc pas de l'algorithme d'évaluation)
Et donc, si vous savez remplir le tableau... vous avez aussi la méthode pour évaluer une main à la volée, sans tableau.
Cette méthode "bourrin" qui est certes la plus rapide (et doit être employée si on veut une performance optimale) a de plus quand même ses limites (ici, avec 5 cartes, ca passe, mais si on avait 7 cartes... ça commence à faire un peu gros, donc nécessiterait d'employer une base de données, par exemple)
Et a vue de nez, les valeurs numériques de la main ne peuvent pas se coder avec moins de 2 octets (32768 valeurs)
Ce qui nous fait un tableau d'environ 900 Mega Octets (si on veut également stoquer le nom de la main)
