|
| Une idée d'amélioration pour les programmes par ins12537 le
[Aller à la fin] |
| Informatique | |
Une idée qui vient de me passer par la tête. Outre l'évaluation brute de la position les programmes ne devraient ils pas prendre en compte la probabilité d'erreur de l'adversaire ?
Imaginons une position, blancs aux trait, avec 2 coups candidats :
- Coup 1 évalutation +0.14
- Coup 2 évaluation +0.10
Pas beaucoup de différence mais le programme va choisir le 1er coup, celui qui lui donne le plus gros avantage.
Maintenant regardons les coups candidats des Noirs
sur le coup 1 ils ont 3 coups candidats dont les évaluations sont +0.14 +0.18 +0.20
sur le coup 2 ils ont 3 coups candidats dont les évaluations sont +0.10 +0.30 +0.45
Il me semble que le programme aurait tout intérêt à jouer le 2ème coup même si son évaluation brute est plus faible.
|
|
|
Un module ne "voit" pas l'évaluation de son adversaire.
|
|
|
Le module ne cherche pas les meilleures chances pratiques mais le meilleur coup concrèetement. Un module évaluant les meilleures chances pratiques est sûrement plus compliqué à faire(à partir de quelle valeur sacrifier un peu d'évaluation pour une meilleure chance pratique ?), et ne sera pas plus performant(et peut-être même prendra des raclées contre les autres modules)
|
|
|
@lefouduroi : bien sûr qu'un module voit l'évaluation de son adversaire, c'est à dire qu'il évolue la position après le coups des deux joueurs et en ressort la ligne optimale pour les deux joueurs.
@Sonik31 : "le module ne cherche pas les meilleures chances pratiques" : c'est justement ce qu'on peut reprocher aux modules et un domaine dans lequel ils pourraient progresser.
Ceci vaut d'ailleurs aussi bien quand un module joue contre un joueur humain (dans ce domaine il pourrait même devenir redoutable en entraînant les humains dans des pièges) que contre un autre module.
Ce dernier point peut sembler surprenant mais les modules ne font pas tous, loin de là, les mêmes évaluations des positions. Comme un joueur chaque module a en quelque sorte sa propre conception du jeu. Un module peut donc "se tromper" par rapport à un autre module et alors pourquoi un module ne chercherait-il pas à imposer sa conception du jeu en attirant l'adversaire dans des pièges ? Quand je parle de piège il ne s'agit pas de prendre un risque en espérant que l'adversaire fasse une gaffe mais de faire une petite concession sans grand risque pour augmenter les chances que l'adversaire choisisse une variante douteuse pour lui.
Tu demandes à partir de quand sacrifier un peu d'évaluation pour de meilleures chances pratiques ? Je ne vois pas le problème, les modules évaluent déjà les positions sur la base de nombreux critères auxquels ils attribuent des valeurs numériques arbitraires (valeur des pièces, structures des pions, sécurité du roi, activité des pièces, etc...) Ce ne serait qu'une valeur arbitraire supplémentaire, pas plus difficile à fixer.
Dans l'exemple que je donne, même entre deux modules le 2ème coup, celui qui donne une meilleure chance de provoquer l'erreur de l'adversaire me semble la meilleure.
Tout dépend dans tout ça si on considère que le but d'un module est de rechercher la ligne mathématiquement optimale ou les meilleures chance de victoire pratique.
Dans le cas où le module est dans une mauvaise position, voire très mauvaise plutôt que de perdre mathématiquement il pourrait prendre un risque en espérant la faute adverse.
|
|
|
Ca pourrait marcher contres les humains oui, mais contre les autres modules je ne vois pas trop l'idée vu que plus il y a d'écarts entre le 1er choix et les autres plus un module est susceptible de jouer ce 1er choix.
Ce que je me demande c'est pourquoi chercher à améliorer le jeu des modules contres les humains sachant qu'ils sont déjà largement supérieurs ? :-)
|
|
|
Cela a peut-être (sans doute?) déjà été testé? Cela revient juste à modifier le routine de tri des coups lorsqu'on dispose de l'évaluation, j'ai bien peur que certains y aient pensé. Le tout c'est de définir un ordre, peut-être basé sur l'écart type sur les 4/5 première évaluations?
As tu fait un essai pratique?
Il faudrait d'abord exagérer en trouvant une position bien piégeuse?
(Je pense que ça ne doit pas être un nouveauté puisque les fabricants d'échiquiers éléctroniques allaient jusqu'à modifier leurs programmes lorsqu'ils les faisaient participer à un tournoi informatique pour s'adapter au jeu contre d'autres machines, certains avaient un jeu favorisant les sacrifices (chess tiger je crois), etc...)
Plusieurs points quand même:
* En moyenne 35 coups possibles, pas deux...
* Si le nombre de coups est très faible (échec) les progs peuvent sans doute calculer la ligne très loin?
* Je ne sais pas si l'idée est compatible avec l'élagage alha-bêta (l'algo ne calcule pas en profondeur les coups "stupides"), les évaluations n'ont pas toutes la même "qualité" (les logiciels laissent d'ailleurs passer des mats dans les problèmes, hihihi).
* Le coup qui donne la meilleure évaluation est déjà une ligne calculée sur une vingtaine de coups, elle contient sans doute par nature plein de coups difficiles.
|
|
|
Effectivement, je ne crois pas que la solution passe par l'alpha-beta, puisque cet algo écarte tous les noeuds d'un groupe dont l'évaluation est inférieure ou supérieure à une valeur seuil, en fonction du niveau ; parmi les noeuds écartés, peuvent très bien se trouver les variantes "piégeuses" que vous voulez favoriser.
Mais cette idée est très intéressante. Je crois qu'il faut plutôt s'appuyer sur la notion de "turbulences". Je rappelle qu'une position est jugée turbulente lorsqu'elle survient après une prise, un échec, un clouage absolu ou relatif, une fourchette, une menace de promotion, etc... En bref, toutes les lignes de jeu susceptibles de provoquer un désiquilibre matériel, ou positionnel, propres à renverser l'évaluation du programme, et surtout, de faire chuter le joueur humain. C'est ce qui nous intéresse ici.
C'est grâce à cette notion de turbulences - en opposition avec les lignes de jeu "calmes" - que le programme détermine s'il doit, oui ou non, approfondir sa recherche dans l'arbre de décision. Il doit être possible d'envisager qu'il puisse aussi comptabiliser les lignes de jeu turbulentes et, toutes autres considérations plus ou moins égales (c'est le développeur qui déterminera l'amplitude du "plus ou moins"), les favoriser.
Qu'en pensez-vous ?
|
|
|
...déséquilibre, pardon...
|
|
|
En plus, on peut imaginer d'affiner cette "fonction pragmatique" avec des paramètres externes à l'arbre de décision, comme la force du joueur humain. Soit par l'intermédiaire d'un classement Elo stocké dans un profil, soit par la consultation de l'historique de parties du programme. L'idée est que ce dernier ne favorise pas une ligne pouvant amener une faute adverse de niveau 1600, alors que l'adversaire vaut 2400 ! Cela peut devenir vite très compliqué, c'est vrai...
Mais je trouve que cette idée est à creuser ; elle pourrait permettre "d'humaniser" un peu le jeu cybernétique.
|
|
|
Mais bon, on ne peux pas se couper complètement de l'élagage alpha beta, sinon on va calculer a une profondeur de 8 coups au lieu de >20.
En général il y a une première phase (combien de coups) en calcul total avant l'élagage, mais cela sert-il de trier les valeurs des coups si on en supprime une partie et qu'on relance l'évaluation à une plus grande profondeur après?
Je reste dubitatif. Quelqu'un a-t'il une partie de Tal sous la main? ;)
|
|
|
Je répète ce que j'ai écrit un module ne "voit" pas l'évaluation d'un autre module qui lui est opposé, ni pendant que celui-ci calcule, ni quand celui-ci a effectué son coup. Un module ne se base que sur ses propres évaluations.
|
|
|
Et où est le problème par rapport à l'idée de JLuc74 ?
|
|
|
Comment un module peut-il évaluer "la probabilié d'erreur de l'adversaire" s'il n'a pas accès aux évaluations de celui-ci?
|
|
|
La probabilité d'erreur de l'adversaire se ferait à partir de ses propres lignes d'analyse.
|
|
|
Et comment cela ?
Sur quelles bases ?
|
|
|
Dans le principe, l'alpha-beta calcule jusqu'à un premier palier de profondeur - c'est encore différent en cas de raffinement progressif - à partir duquel il doit déterminer s'il est nécessaire d'appronfondir la recherche, en fonction de la notion de turbulence. N'est-il pas possible de stocker cette information pour chaque coup candidat, une espèce de compteur ?
Ensuite, imaginons que la fonction d'évaluation retourne, à l'issue de l'exploration complète de l'arbre par l'alpha-beta, trois coups à la valeur très proche ; on va dire que l'on reste dans une fourchette d'un "tiers de pion". Plutôt que de choisir le premier d'entre eux - comme le font habituellement les programmes - pourquoi ne pas favoriser celui qui a provoqué le plus de turbulences, celui dont le compteur est le plus élevé ?
Je pense que je me rapproche de l'idée de JLuc74. Evidemment, je ne suis pas catégorique ; c'est juste une hypothèse qui peut très bien ne pas tenir la route. Mais il me parait assez logique de favoriser cette notion de turbulences, si l'on veut provoquer une erreur humaine ; les erreurs sont plus rares à partir de positions plates !
|
|
|
Je voulais pondre un texte pour essayer d'expliquer, mais je me suis aperçu que j'ai aussi du mal à comprendre. Je suis plutôt réticent en tout cas.
|
|
|
Akiba, si le module avait une profondeur de calcul parfaite, pourquoi pas. Mais là sachant qu'il y a quand même une marge d'erreur, le module dans une position compliquée ayant plus de chance de se planter tout ça en choisissant un coup qui n'est même pas le meilleur. Et tout ça dans quel but ?
Contre les autres modules qui calculeraient approximativement aussi bien que lui, sacrifier un peu d'evaluation peu nuire à la partie
Pour l'analyse de partie, chercher la variante la plus compliquée sachant que la personne concernée est un humain qui n'aura jamais la capacité de calculer comme le module, donc aucun intêret a compliquer la position.
Et enfin pour les parties contre un joueur humain lambda(qui n'est à mon avis pas l'usage premier d'un module), ce n'aura sûrement pas d'influence sur le resultat final.
|
|
|
Oui, tu as raison ; il faut imposer un cadre plus restrictif. Alors juste une partie homme vs machine ?!
|
|
|
La plupart des modules ont déjà, dans les paramètres, la possibilité de réglages permettant de changer radicalement leur comportement.
Le problème est de trouver le paramétrage qui convient.
|
|
|
Comment un module peut évaluer la probabilité d'erreur d'un module adverse ? Ce n'est pas exactement ce qu'il cherche à faire mais à envoyer l'adversaire en terrain miné plutôt que de lui offrir le choix entre de nombreux coups.
Il faut prendre mon exemple pour comprendre. Entre une évaluation à +0.10 et une évaluation à +0.14 la différence est infime, les deux coups sont très probablement jouables mais si ensuite le coups le plus "faible" limite les choix de l'adversaire et l'oblige à une plus grande précision ça vaut sans doute le coup.
Je parle de 4/100 de pion, à vu de nez je pense que ça peut marcher très correctement jusque 20/100, au delà ça pourrait toutefois permettre de créer des styles d'adversaire plus agressifs mais si dans l'absolu ils sont moins forts il seraient particulièrement redoutables pour des joueurs humains.
En laissant tourner Houdini 1.5 sur la position de départ j'obtiens
1.e4 +0.19
1.d4 +0.13
1.Cf3 +0.10
Ca montre le peu d'importance que représentent quelques dixièmes de pion
|
|
|
@ABrobecker : tes arguments montrent que tu n'as pas compris ce que je propose.
Déjà, il est évident qu'il y a une trentaine de coups en moyenne dans chaque position mais je n'ai donné que des coups candidats, je n'ai pas parlé des coups où on donne sa dame en 1 coup sans compensation.
Ca n'augmenterait pour ainsi dire pas le temps de calcul puisqu'il s'agirait de calculer l'arbre tout à fait normalement, sans prendre en compte ma proposition. Il n'y a que juste avant de jouer le coup que le module se poserait la question : "Est-ce que je joue le meilleur coup calculé ou est-ce que je joue le 2ème ou le 3ème qui offrent moins de choix de réponse à mon adversaire ?"
C'est un moyen que je pense simple et peu couteux d'améliorer la créativité des programmes.
|
|
|
L'idée est intéressante au premier abord mais il me semble qu'il y a au moins deux inconvénients sérieux:
1) technique: pour les programmes, seules les notes des coups des variantes principales sont justes en général. Un coup est écarté dès que l'on prouve qu'il est moins bon que le meilleur coup actuel. Concrètement, le programme analyse le coup 10) CxF et trouve une première réponse de l'adversaire, 10) ..., exC qui donne -1. Il regarde ensuite une deuxième réponse pour l'adversaire, 10) ..., TxC et trouve un coup qui la réfute avec par ex une éval à -1,5. Il arrête aussitôt d'analyser cette suite car elle n'est pas suffisante mais la note réelle de ce deuxième coup est peut être -5 et non -1,5. Il ne prend simplement pas le temps de chercher la meilleure réfutation, une seule lui suffit, mais il ne connais pas la vrai valeur du coup.
2) de principe: Le postulat de départ est qu'il est difficile de trouver un coup unique dans la position. Cela me semble faux en général. Au contraire, il est souvent plus facile de trouver le bon coup quand il n'y en a qu'un. Le programme risque en suivant ce principe d'aller vers les suites avec des menaces simples, un peu comme un débutant qui fait des menaces en un coup. On risque de perdre significativement en force en suivant ce principe.
|
|
|
@pc
1) Je viens d'expliquer que ça ne modifiait en rien le calcul de l'arbre, qu'il ne s'agissait que d'une décision prise ensuite. Le programme ne va simplement pas jouer le coup qu'il estime le meilleur après le calcul de l'arbre mais va jouer un coup à l'évaluation très proche, quasi-équivalente, quand ce coup offre une position plus compliquée pour son adversaire.
2) Ce n'est pas si rare que ça, je pense mettre rendu compte de cette possibilité en suivant des parties en live sur internet et en regardant l'évaluation de l'ordinateur pour les 3-4 meilleurs coups. Le joueur ne joue pas toujours la meilleure évaluation de l'ordinateur mais ça ne l'empêche pas d'emmener son adversaire dans des positions délicates parce qu'il a très peu de bons coups. Les ordinateurs ne font pas ça, ils devraient.
|
|
|
@Jluc74
Tes 2 points répètent ta proposition initiale mais ne répondent pas à ce que je dis.
1) Tu bases ton raisonnement sur un examen des notes des coups candidats de l'adversaire mais elles sont fausses en général. Seule le meilleur coup a une évaluation exacte, les autres sont des bornes. Quand il n'est pas dans la ligne principale, un ordinateur essaie de réfuter les coups, pas de les évaluer exactement, ce qui est beaucoup plus coûteux. C'est le principe de base d'alpha beta.
Donc quand tu dis,sur le coup 2 ils ont 3 coups candidats dont les évaluations sont +0.10 +0.30 +0.45, seul le 0.10 est sûr, le deuxième coup est peut être en fait réellement à -5. Il est possible de calculer ces notes exactement mais alors on va diminuer significativement la force de l'ordi.
2) Il ne me semble pas évident que jouer des coups avec un seul bon coup en réponse pour l'adversaire lui rende la tâche plus difficile.
|
|
|
@JLuc94: sauf erreur il me semble qu'un petit détail t'échappe. Comme le souligne pc, le "second coup d'évaluation presque identique au premier" peut, dans certains cas, être en réalité loin en dessous. Exemple: le meilleur coup est un coup tranquille à 0.1, et en second t'as une possibilité qui perd la dame en 3 coups. Seulement comme toutes les branches ne sont pas évaluées, il se peut bien qu'en dehors de la capture de la dame les lignes renvoient une éval à 0.05, et que l'ordi s'arrête là, tout simplement car il a déjà un meilleur coup (+0.1).
L'autre point est embêtant également. J'avoue que l'idée me plaisait beaucoup au début, mais ça semble de plus en plus délicat à implémenter. Peut-être en oubliant l'alpha-beta, et en codant "autre chose". Mais les essais en dehors de cet algo n'ont pas été concluants je crois. "The problem with type B is that it relies on the program being able to decide which moves are good enough to be worthy of consideration ('plausible') in any given position and this proved to be a much harder problem to solve than speeding up type A searches with superior hardware and search extension techniques." [from wikipedia].
EDIT: en gros la dernière phrase dit qu'il est plus fructueux de descendre très loin dans l'arbre en coupant plein de branches que d'évaluer une position "humainement" pour déterminer une poignée de coups candidats; ce qui serait pourtant plus pratique pour la méthode envisagée. Enfin faut voir à quel point ça dégrade le jeu. Si ça se trouve pour un match homme-machine c'est largement suffisant. (Mais ça ne dit pas comment coder les choix ^^)
|
|
|
"second coup d'évaluation presque identique au premier peut, dans certains cas, être en réalité loin en dessous.". Il peut également être au dessus, quelques centièmes de pion c'est largement dans la marge d'erreur des évaluations. +0.10 ou +0.14 c'est plus ou moins pareil et d'ailleurs si tu changes de moteur tu auras des évaluations très différentes alors que les moteurs sont de très très haut niveau. Et souvent les évaluations seront inversées, un module fait un choix, un autre en fait un autre. Ca n'arrive pas dans les suites tactiques obligatoires mais dans le jeu calme c'est très courant.
Que tu parles d'alpha-béta montre bien que tu n'as pas compris que ça n'avait rien à voir avec le calcul de l'arbre. Il s'agit d'une phase supplémentaire, une fois que les meilleurs coups ont été calculés.
Si je reprends ton exemple et que tu as un coup à +0.10 et plusieurs coups à +0.05 c'est peut être l'un de ses coups qui est le plus intéressant parce qu'il demandera plus de précision à l'adversaire que le coup à +0.10 qui offre une bonne demi douzaine de réponses avec une évaluation très proche.
|
|
|
@JLuc94:
Tu confonds deux choses :- L'algorithme en lui-même, qui étant donné sa fonction d'évaluation te garantit (à 100%) que SES évaluations des coups suivants sont inférieures à celle du meilleur coup. Donc non, le second coup ne peut pas être "quelques centièmes au dessus".
- L'évaluation véritable, "parfaite" de la position, qui elle de toutes façons est soit -infini, soit 0, soit +infini.
"Que tu parles d'alpha-béta montre bien que tu n'as pas compris que ça n'avait rien à voir avec le calcul de l'arbre. Il s'agit d'une phase supplémentaire, une fois que les meilleurs coups ont été calculés."
Je dirais "une fois que LE 'meilleur' coup a été calculé" (et encore, en pratique l'alpha-beta s'applique évidemment aussi dans le sous-arbre du meilleur coup). Je ne suis pas un expert du domaine mais bon j'ai tout de même codé cet algo plusieurs fois.
Intéressant de choisir un coup qui donne la dame en 3 ? Hum. On ne doit pas avoir la même conception du jeu :) Mais mon exemple est un peu extrême c'est sûr.
|
|
|
Tu n'as pas compris ce que je disais, l'évaluation de l'ordinateur peut être fausse, elle l'est même en général et donc "en réalité" un coup considéré comme inférieur pour l'ordinateur peut être supérieur. Effectivement les seules évaluations réelles qui existent sont -l'infini, +l'infini ou 0 mais l'ordinateur peut se tromper et c'est peut être son deuxième choix qui mène au gain et pas le premier. La marge d'erreur est telle que des évaluations proches de l'ordre de quelques centièmes de pion sont équivalentes.
Ton exemple de donner la dame en 3 est tellement extrême qu'il est hors propos. Avec des évaluations à +0.10 et +0.14 l'ordinateur n'a pas plus de raison de penser qu'il a plus de chance pour un coup que pour l'autre de devoir donner du matos au delà de sa profondeur de calcul.
|
|
|
"La marge d'erreur est telle que des évaluations proches de l'ordre de quelques centièmes de pion sont équivalentes."
Bien sûr, mais, à condition que ces évaluations ne soient pas, comme l'indique pc, de simples bornes. Après tu peux calculer très précisément les évaluations pour un petit groupe de coups candidats, mais deux nouveaux problèmes surgissent :- lesquels choisir ?
- ça va ralentir l'algo, et donc la profondeur diminue
EDIT: je suis d'accord qu'en pratique les coups affichés à la suite du meilleur sont souvent assez bons aussi, mais on n'a (a priori) pas de garantie là-dessus.
|
|
|
Je ne sais pas si on se comprend bien mais
1) calculer très précisément n'est pas possible, il ne s'agit que d'une évaluation basée sur des critères empiriques. Il est faux de croire qu'entre +0.10 et +0.14 il y ait une différence
2) Ce que je propose ne ralenti pas du tout le calcul (enfin si, une infime fraction de seconde pour choisir le coup à jouer une fois l'arbre calculé)
Tu dis qu'on n'a pas (a priori) de garantie sur la valeur des coups secondaires, on n'en a pas plus sur le meilleur coup. On ne peut pas affirmer qu'un coup ayant un estimation de quelques centièmes de pions de plus qu'un autre est meilleur.
|
|
|
@pc, je ne suis pas d'accord avec ce que tu dis "Seule le meilleur coup a une évaluation exacte, les autres sont des bornes"...
A savoir, que tu fasses une évaluation exhaustive avec un min-max ou une évaluation élaguée avec un alpha-beta, la note des coups SERA IDENTIQUE, puisque la fonction d'évaluation est la même. Seule la profondeur de calcul peut modifier la note d'un coup candidat.
J'ai pas trop compris ton histoire de borne ; tu fais référence à la valeur seuil de l'alpha-beta ? De plus, comme le dit JLuc74, il n'est pas question de modifier cet algo. La décision de favoriser tel ou tel coup se fait APRES son exploration de l'arbre.
|
|
|
@JLuc94: Non, mais on peut affirmer (et on le fait ^^) qu'on l'a calculé avec plus de soin. C'est ce que j'entends par "calculer très précisément" (modulo la profondeur limite et les imperfections de la fonction d'évaluation).
Ce que tu proposes multipliera sans doute le temps de calcul par une petite constante, peut-être 2 ou 3, car tu veux une évaluation "soignée" de tous les coups candidats. Pas dramatique. Mais il faut aussi ajouter le temps nécessaire pour choisir ces candidats. On peut par exemple prendre les meilleurs coups de la profondeur précédente, mais bon, ça me semble pas évident.
Je pense que là où on ne se comprend pas bien, c'est sur le fameux "calcul de l'arbre". On ne peut pas le dérouler en entier, donc faut bien élaguer un peu et approximer [de + en +] :)
EDIT: je commence à me demander si je n'ai pas confondu quelque chose. En effet on réordonne les coups suivant les évals, donc il faut qu'elles soient précises. Hum. Ah mais non : c'est l'évaluation des coups de l'adversaire (sur chacun des notres) qui elle est potentiellement fausse. Donc ouf je n'ai pas raconté que des bêtises (ce qui précède tient toujours, faut juste remplacer le niveau n par n+1). Et comme c'est le coup de l'adversaire qui nous intéresse, y'a toujours un souci.
|
|
|
Note: c'est assez bien expliqué sur cette page. Et si on obtient des évaluations correctes pour nos coups (au premier niveau), c'est parce qu'on relance un alpha-beta à chaque fois. Donc il faudrait en relancer un sur chaque groupe de coups candidats adverses, d'où le facteur multiplicatif, ...etc. ça rejoint ce que je disais, mais en mieux justifié :)
|
|
|
@JLuc74:
* Oui ok pour l'histoire du 35 coups, désolé. J'espère que tu as quand même suivi le lien, le travail de François Labelle est fantastique.
* Je te cite "il s'agirait de calculer l'arbre tout à fait normalement".
Beaucoup de monde signale que ce n'est justement pas possible avec l'élagage alpha bêta, puisque l'arbre n'est pas calculé "normalement" dans ce cas... C'est un sous-arbre qui est parcouru et évalué. Les zones les plus turbulentes (et donc les plus intéressantes pour ton point idée?) ont peut-être été coupées très tôt et tu n'auras pas tes évaluations au coup d'après...
Mais bon, plutôt que d'argumenter, et puisque tu pourras déjà implémenter ta modification de l'ordre des coups avec un algo plus simple de min/max (negamax plutôt), quand est-ce que tu nous programme cet algorithme?
|
|
|
Il y a juste un petit problème. Les évaluations concernent toute la variante et pas seulement le premier coup de la variante.
|
|
|
Dans un match entre deux GMI humains , notamment si l'un des deux joueurs est en zeinot, il peut en efffet etre interessant de jouer le second ou 3 eme coup candidat sur l'echiquier, si le premier coup appelle une réponse automatique de la part de l'adversire .
faire jouer une position compliquée à un adversaire en zeinot , revient en pratique à l'idée initiale, c'est que le joueur en manque de temps, pourra se tromper dans une variante comportant plusieurs pieges discrets tendus comme des collets pour un lapin .
maintenant , je me souviens de mes premieres lecons d'echecs et de la phrase " joue le coup que tu penses etre le meilleur, et considere que ton adversaire trouvera aussi la meilleure reponse, ne joue jamais un coup en esperant une erreur de l'dversaire qui ne viendrait pas, et qui te conduirait à jouer une position inferieure ..."
il me semble me souvenir que dans le match kasparov contre un ordinateur surpuissant, kasparov avait perdu car il n'etait pas dans le bon etat d'esprit par rapport à une partie normale , contre un humain, il avait confiance dans ses analyses et jouait les meilleurs coups dangereux, contre la machine, il avait tellemeent peur d'avoir faitune erreur de calcul, qu'il perdait du temps à verifier plusieurs fois les coups qu'il avait envie de jouer, et meme nosait pas jouer de bons coups contre l'ordinateur car il craignait une refutation qu'il n'aurait pas vu ...
cela me rappelle aussi une phrase apprise lors de mes premeires pas aux echecs : si tu vois que ton adversaire a laissé un pion en prise, verifie que ce n'est pas un piege, et si tu ne trouves pas le piege, prend le pion !!! souviens toi de l'ombre du fromage avec le corbeau et le renard ...
pour en revenir enfin au sujet initial, lors de nombreuses parties jouees entre logiciels, j'ai pu observer en effet que le logiciel le lus faible pouvait en effet sur un coup , jouer un coup formidable , qui lui donnait un excellent evantage , car le programme plus fort etait tombé dans un piege ... mais j'ai aussi souvent vu, que au final le programme plus faible perdra , car il ne saura pas exploiter au mieux par la suite, l'avantage qu'il a obtenu, et le logicel le plus fort pourra remonter la pente coup apres coup ...pour finir d'equilibrer la position, avant de reprendre l'avantage...
ce post met le point sur une difference fondamentale de penser les echecs entre un humain , et un logiciel programmé pour jouer les coups qu'il croit les meilleurs ...
|
|
|
@Benji3000 "Ce que tu proposes multipliera sans doute le temps de calcul par une petite constante, peut-être 2 ou 3". Tu n'as vraiment rien compris, ça ne multipliera pas le temps de calcul par un quelconque facteur puisque la majeur partie du temps de calcul c'est le calcul de l'arbre et l'évaluation des coups et ça je n'y touche pas du tout. Comme je l'ai expliqué déjà une demi-douzaine de fois je prends juste une fraction de seconde au moment de jouer le coup pour me demander si je n'ai pas plus intérêt à jouer mon deuxième ou troisième choix qui ont des évaluation quasi identiques mais qui laissent moins de choix de réponse à l'adversaire. Ca ça prend peut être 0,00001s à chaque coup, c'est donc sans conséquence sur le temps de calcul.
|
|
|
@JLuc74: comme on te l'a rappelé une bonne demi-douzaine de fois, tu ne disposes pas d'évaluations fiables des coups adverses. à moins de relancer un alpha-beta après chacun d'eux. En pratique Houdini n'a aucun intérêt à se préoccuper des évaluations exactes des réponses adverses r1, r2 et r3 s'il peut déterminer rapidement qu'elles sont inférieures à r0 évalué en premier.
Je te suggère vraiment de lire le lien que j'ai posté dans la dernière intervention, notamment le passage "[...] A est par contre un niveau maximisant, qui a déjà provisoirement la valeur 5. La valeur issue de B2 (4 ou moins) ne présentera donc pas d'intérêt, car si l'ordinateur s'oriente vers là, il sait que l'adversaire peut l'amener à une position de valeur 4 (ou moins). La branche B2 peut d'ores et déjà être éliminée, car moins intéressante que B1, qui, si l'adversaire répond au mieux, amènera au pire à une position valant 5. [...]"
|
|
|
Je vous trouve patients :)
|
|
|
@Benji3000 : Ah oui, je viens de comprendre ce que tu veux dire, tous les coups de l'adversaire ne sont pas analysés donc difficile d'appliquer à la lettre ce que je propose... Hum... Il faut que j'y réfléchisse.
|
|
|
@El Cave: Oui, nous le fûmes...
|
|
|
