|
Bug dans Stockfish par Le***78**12432 le
[Aller à la fin] |
| Informatique | |
Bonjour
Demandant à Stockfish (version 6) d'analyser la position obtenue à la fin de cette suite de coups
1. e4 e5 2. Nf3 Nc6 3. Bb5 Nf6 4. O-O d6 5. Re1 Be7 6. h3 O-O 7. c3 Bd7
8.d4 exd4 9. cxd4 a6 10. Ba4 b5 11. Bb3 Na5 12. Bc2 c5 13. d5 Qc7
14. Nc3 Rac8 15. Bg5 Rfe8 16. Qd2 Nc4 17. Qc1 b4 18. Nd1 a5 19. Ne3 Nxe3
20. Qxe3 Bd8 21. Nd2 Nxd5 22. Bxd8 Nxe3 23. Bxc7 Nxc2 24. Bxd6 Nxa1
25. Rxa1 Red8 26. Be7
j'ai eu la surprise de voir qu'il propose un coup assez stupide (genre 26... Fb5) alors que tout joueur (et tout autre logiciel) propose le coup naturel, obligatoire, et totalement gagnant 26...Te8
En fait, visiblement Stockfish pense qu'il y a match nul dès qu'une position, avec même trait, se présente pour la seconde fois !
C'est tout de même incroyable, je dois me tromper, non ?
|
D'autres modules font la même chose:
Analysis by Komodo 9 64-bit:
26...Fb5 27.Fxd8 Txd8 28.Cf1 Td4 29.Ce3 Txe4 30.b3 Te5 31.a3 h6 32.axb4 axb4 33.Ta7 f5 34.g3 Fe8 35.Ta8 Rh7 36.Ta7 Fc6 37.Tc7 Ff3 38.Rh2 Rg6 39.Ta7 Fd5 40.Cxd5 Txd5 41.Tc7 Rf6 42.Rg2 g6 43.Tc6+ Rg5 44.h4+
-/+ (-0.75) Profondeur: 29 00:04:07 667mN, tb=1088
Analysis by Deep Fritz 14 x64:
26...Fb5 27.Fxd8 Txd8 28.Cb3 c4 29.Cxa5 Ta8 30.Cb7 b3 31.a4 c3 32.Cc5 Fc4 33.bxc3 b2 34.Tb1 Tb8
-/+ (-0.98) Profondeur: 27 00:00:11 27328kN
Analysis by Critter 1.6a 64-bit:
26...Fb5 27.Fxd8 Txd8 28.Cf1 a4 29.Tc1 c4 30.Ce3 b3 31.Cd1 Fc6 32.axb3 cxb3 33.f3 Td2 34.Tb1 Fb5 35.Cc3 Fd3 36.Ta1 f5 37.Txa4 Txb2 38.Tb4 Rf7 39.exf5 Fxf5 40.Tb7+ Rf6 41.Rf1 Fd3+ 42.Re1 h5 43.g4 g6 44.Td7 Fc2 45.Cd5+ Re6
-/+ (-0.85) Profondeur: 25/63 00:07:16 1443mN
Sauf "l'ancien" Deep Shredder 12:
Analysis by Deep Shredder 12 x64:
26...Te8 27.Fd6 c4 28.e5 c3 29.bxc3 bxc3 30.Cb3 Fe6 31.Cc5 Ted8 32.Cxe6 fxe6 33.Tc1 Td7 34.Tc2 Tb7 35.Fa3 g5 36.Fc1 Rf7 37.g4 Rg6 38.Rg2 Tc4 39.Rf3 Tb5 40.Re2
-+ (-3.74) Profondeur: 28/64 00:49:30 3458mN, tb=11, bb=76
|
|
C'est un bug visiblement répandu !
Le concepteur préfèrent programmer la nulle dès la seconde même position au lieu de la troisième : je ne comprends pas pourquoi, mais il paraît que modifier le code n'en vaudrait pas la chandelle...
|
|
Il n'est pas question de nulle dans aucune analyse et surtout pas par répétition de position. Pour Stockfish non plus.
|
|
C'est marrant si on rentre directement la position Stockfish propose bien Te8 (+2.87). En jouant la partie, il ne voit plus Te8 car il "évalue" Fd6 comme amenant à la nulle par répétition (ce que veut sans doute dire Leon1789). Donc il préfère les autres coups de fou qui gardent un avantage noir.
PS : en fait ça semble courant, et ça intervient juste dans l'analyse. Ca ne baisse pas le niveau de l'engine car dans une de ses parties, il ne jouerait jamais un coup qui le force à répéter ensuite pour changer. Plein de liens en cherchant par exemple dans google "stockfish bug draw by repetition too early"
|
|
Ok vu comme ça.
|
|
J'avais déjà remarqué cette façon d'évaluer la position pourtant je n'utilise pas Stockfish mais Houdini 1.5 qui (étrangement) propose correctement 26...Te8 dans ce cas là. Si je revois ça avec Houdini je vous en ferais part.
Je n'appellerais pas ça un bug à proprement parlé mais une volonté de la part du développeur d'évaluer immédiatement comme nulle tout coup emmenant à une première répétition de position. Stockfish ne joue jamais 25...Ted8 parce que après 26.Fe7 il n'y a pas mieux pour les Noirs que 26...Te8 permettant la répétition de coup 27.Fd6 donc la position est évalué 0.00 alors que d'autres coups comme 26.Fb5 donne d'après lui une position légèrement favorable aux Noirs. Si le meilleur coup mis à part 26...Te8 donnait l'avantage aux Blancs, ne serait-ce que +0.01, il jouerait 26...Te8 (à vérifier).
Il est assez logique qu'un ordinateur évalue une position comme nulle dès la 1ère répétition. Contrairement à l'être humain il n'est pas sensé évaluer 2 fois différemment la même position et trouver le bon coup au deuxième essai, par tâtonnement.
|
|
" Je n'appellerais pas ça un bug à proprement parlé mais une volonté de la part du développeur d'évaluer immédiatement comme nulle tout coup emmenant à une première répétition de position. "
Je suis d'accord. C'est ce que je voulais dire, même si j'ai appelé cela un bug.
Certes, comme vous l'avez expliqué, dans la position après 25.Txe1, un programme ne jouera pas 25...Ted8, c'est vrai.
Cela dit, pour moi, l'analyse du programme après 26.Fe7 reste anormalement faussée : la position est à l'avantage des noirs (par 26...Te8 qui gagne) et non un léger avantage (par 26...Fb5, qui n'est pas certain de gagner).
|
|
" Ca ne baisse pas le niveau de l'engine car dans une de ses parties, il ne jouerait jamais un coup qui le force à répéter ensuite pour changer. "
Je ne suis pas convaincu.
Si le temps d'analyse est suffisamment long, ok.
Mais dans une partie, il y a certains aléas qui influent sur la prise de décision.
Il faut par exemple respecter le temps alloué à la réflexion, et là, si le programme doit jouer (trop) vite, il peut commettre une imprécision qui demanderait un retour sur la position initiale.
Typiquement, dans des positions particulières, il n'est pas rare de voir l'évaluation d'un programme baisser brutalement d'un coup au suivant (genre passer de +2.5 pour le coup n à +0.5 pour le coup n+1) : dans ce cas, pourquoi ne pas répéter la position (si possible) pour tenter une variante qui avait l'air d'être probablement meilleure (genre +1.5 pour le coup n) au lieu de continuer dans une position moins bonne (à +0.5) ? Il faudrait trouver un exemple concret pour illustrer le phénomène...
|
|
Voilà, je reviens sur ce problème de programmation de Stockfish...
Dans la position ci-dessous, trait aux noirs, Stockfish évalue la position à 2.17 en faveur des noirs.
Je joue 1... Ff6 (qui n'est pas un bon coup : le bon coup est Cxc3).
Le module répond logiquement 2. Ce4 : évaluation 1.32 pour les noirs.
Du coup, je reviens avec 2...Fe7 (pas le meilleur coup non plus).
Le module répond alors 3.Cc3 , en évaluation la position à 0.00, alors que ce coup est très mauvais, laissant faire 3...Cxc3 avec une évaluation de 2.17 pour les noirs (cf position de départ). Meilleur est 3.Cg5 (mais Stockfish ne le joue pas) avec une évaluation de seulement 1.33 pour les noirs.
Les évaluations que je donne sont liées à la version de Stockfish, la durée de réflexion, etc, mais je pense que le même phénomène se reproduit avec n'importe quelle version et et n'importe quel ordi dans la position décrite ici.
Fen : 1r4k1/2q1bppp/p1b1p3/2pn4/2N2P2/P1N1P3/2Q3PP/2BR2K1 b - - 0 22
|
|
J'ai mis la dernière position avec Stockfish 7. Même chose: Ff6 Ce4 Fe7 Cc3.
En revanche avec Fritz 13: Ff6 Ce4 Fe7 Cg5!
C'est très étrange, Stockfish considère que la position sera forcément répétée, et donc l'évalue à 0.00, ce qui décide de son coup. "Erreur" de programmation donc, mais pas universelle.
|
|
En effet, erreur commune, mais pas universelle, car de mon coté, je constate :
AnMon, (deep) Rybka, Gull, Hermann, Ifrit, Komodo, Ruffian, Spike, Stockfish, Strelka, Toga jouent 3.Cc3?
Critter, Fire, Fritz, Houdini, Igorrit, IvanHoe, Robbolito, Senpai, SOS jouent 3.Cg5!
Par ailleurs, je reviens sur mon avis erroné de 2...Fe7 : cela a l'air d'être le meilleur coup noir.
Bien sûr, Stockfish ne le trouve pas pendant la partie (puisqu'il évalue 0.00 la variante 2...Fe7 3.Cc3 et préfère le coup 2...Fb5 évalué à 1.14), mais il le trouve à l'analyse de la position, une fois celle-ci isolée de la partie (il évalue 1.39 la variante 2..Fe7 3.Cg5)
|
|
En fait Stockfish et Komodo jouent 26..Te8 si on leur colle le FEN de la position sans l'ensemble de la partie. Intéressant car je pensais qu'effacer les hashtable suffisait.
|
|
Le problème sur mon premier exemple est que la partie n'est pas jouée par Stockfish : c'est une partie entre deux joueurs analysée par le module. On peut donc expliquer, à juste titre, que le module n'aurait pas joué 25...Ted8 , etc. Ce qui permet de justifier qu'il n'y a pas vraiment "bug".
Mais dans mon second exemple, on ne peut plus dire que le module aurait joué différemment, car c'est bien Stockfish qui joue les coups 2.Ce4! puis 3.Cc3? . Là, clairement le module joue de manière fausse (contrairement à d'autres programmes, pourtant réputés moins forts).
|
|
Dans ton deuxième exemple après 22..Ff6 23.Ce4 Fe7
Nouvelle partie
1r4k1/2q1bppp/p1b1p3/2pn4/2N1NP2/P3P3/2Q3PP/2BR2K1 w - - 0 1
Analysis by Stockfish 7 64:
1. = (0.00): 24.Cc3
2. -/+ (-1.43): 24.Cg5 g6 25.Ce5 Fe8 26.e4 Cf6 27.Cc4 h6 28.Cf3 Dc6 29.Te1 Da4 30.Dxa4 Fxa4 31.Fb2 Ce8 32.f5 Tb3 33.fxg6 fxg6 34.Tb1 Cd6 35.Cxd6 Fxd6 36.Cd2 Tb7 37.Cc4 Fe7 38.Ce5 Rh7 39.Cc4
3. -/+ (-1.48): 24.Fd2 f6 25.Fa5 Dd7 26.Te1 Fa4 27.De2 f5 28.Ced2 Ff6 29.Df3 Fc6 30.Df2 Fb5 31.Tc1 g6 32.Df3 Dg7 33.Dg3 Df8 34.Df2 De7 35.h3 Dg7 36.Cf3 Fxc4 37.Txc4 De7
Il est normal que Stockfish préfère 24.Cc3 qui lui donne la nulle plutôt que 24.Cg5 qui le fait perdre. Il analyse cette ligne dans le deuxième ligne, la troisième 24.Fd2 est considérée comme encore inférieure.
D'ailleurs si tu laisses analyser du côté des Noirs il préfère jouer des coups gagnants plutôt que de répéter la position.
Avec les Blancs, il est dans une position perdante, c'est sûr qu'il préfère la nulle si tu lui laisses la possibilité (en jouant des coups de répétition) plutôt que de perdre!
|
|
"Nouvelle partie
1r4k1/2q1bppp/p1b1p3/2pn4/2N1NP2/P3P3/2Q3PP/2BR2K1 w - - 0 1
Analysis by Stockfish 7 64:
1. = (0.00): 24.Cc3 "
Je ne suis pas d'accord : dans la situation d'une "nouvelle partie" (ie une position de départ), Stockfish ne donne pas l'évaluation 0.00 au coup Cc3, mais l'évaluation -2.17 .
Il donne l' évaluation 0.00 à Cc3 quand il joue réellement la partie, et c'est là le hic.
"Il est normal que Stockfish préfère 24.Cc3 qui lui donne la nulle plutôt que 24.Cg5 qui le fait perdre."
En réalité 24.Cc3 ne donne pas la nulle : c'est un coup qui donne un gros avantage aux noirs (et Stockfish s'en aperçoit juste après avoir joué 24.Cc3)
Si, pendant la partie, Stockfish préfère 24.Cc3 en pensant obtenir la nulle, c'est parce qu'il y a bug dans la programmation (suite à une répétition de coups dans la partie), d'après ce que je comprends.
"Avec les Blancs, il est dans une position perdante, c'est sûr qu'il préfère la nulle si tu lui laisses la possibilité (en jouant des coups de répétition) plutôt que de perdre !"
Même si la situation est difficile, la position n'est peut-être pas si perdante que cela avec les blancs, à condition de jouer 24.Cg5 par exemple. Or le bug du module l'envoie directement sur le coup 24.Cc3 qui lui est davantage perdant. On préfère un coup qui donne une évaluation de +1.3 à l'adversaire, plutôt que +2.2 :)
|
|
Et ouais... Il semble que ce soit là où on voit toute la différence entre un module joueur d'échecs et un module d'analyse... Mais tant que les développeurs iront sur le champ de bataille pour le plus fort ELO...
|
|
Midi,
vous voulez dire que ce "bug" (dont l'impact est très négligeable, tant par sa fréquence que par ses conséquences) fait suite à une optimisation des calculs (dont l'impact est important pour monter le niveau global du module) ?
|
|
"vous voulez dire que ce "bug" (dont l'impact est très négligeable, tant par sa fréquence que par ses conséquences)[...]
Le problème c'est que pour être sûr que ce genre de bug est rarissime, il faudrait vérifier les variantes sorties par le logiciel, auquel cas ce n'est plus la peine de l'utiliser.
|
|
@Leon1789
Le niveau de jeu d'un module se repose sur un résultat statistique et, comme il n'est pas question de modules d'analyse au sens fort du terme mais plutôt de modules joueur d'échecs, il ne faut pas s'étonner des divers aléas rencontrés au cas par cas dans une analyse de position en mode infini.
|
|
Certes, mais là, il ne s'agit pas du problème d'une analyse en mode infini versus jeu en temps réel.
En fait, dans les situations précisées ci-dessus, le temps de réflexion n'a aucune importance, le "bug" apparaît dès le premier instant de calcul (avec 3.Cc3 par exemple) et ne pourra pas être compensé en laissant le module calculer pendant un temps infini car le module est enfermé dans une fausse croyance de "partie nulle réglementaire" simplement à cause du bug.
A contrario, les modules Critter, Fire, Fritz, Houdini, Igorrit, IvanHoe, Robbolito, Senpai, SOS évitent tout de suite le mauvais coup 3.Cc3 (et trouvent le coup 3.Cg5 après quelques secondes de réflexion).
|
|
@Leon1789
Je viens de faire un copié-collé de la position [1r4k1/2q1bppp/p1b1p3/2pn4/2N1NP2/P3P3/2Q3PP/2BR2K1 w - - 0 1] dans mon interface Fritz et j’ai activé la fonction Outils -> Entraînement -> Entraînement par thème pour verrouiller la position et lancer l’analyse infinie et j’obtiens avec Stockfish 7 32 bit :
Nouvelle partie
1r4k1/2q1bppp/p1b1p3/2pn4/2N1NP2/P3P3/2Q3PP/2BR2K1 w - - 0 1
Analysis by Stockfish 7 32bit:
-/+ (-1.14) 1.Fd2 Tb7 2.Ce5 Fe8 3.Cc4 h6 00:00:00
-/+ (-1.27) 1.Fd2 h6 2.Ce5 Fe8 3.Dc4 a5 4.h3 00:00:00
-/+ (-0.74) 1.Cg5 Fxg5 2.fxg5 Ce7 3.Fb2 Cg6 4.a4 Db7 00:00:00
-/+ (-0.86) 1.Cg5 Fxg5 2.fxg5 Cb6 3.Cxb6 Dxb6 4.Td6 Db7 5.Dd1 00:00:00
-/+ (-1.15) 1.Cg5 g6 2.Ce5 Fe8 3.e4 Cxf4 4.Cgxf7 Fxf7 5.Fxf4 g5 6.Cxf7 Dxf4 00:00:00
-/+ (-1.01) 1.Cg5 g6 2.Ce5 Fe8 3.e4 Cf6 4.Fe3 h6 5.Cxg6 fxg6 6.Cxe6 Dc8 7.f5 gxf5 00:00:00
-/+ (-1.22) 1.Cg5 g6 2.Ce5 Fe8 3.e4 Cf6 4.Fb2 h6 5.Cxg6 fxg6 6.Cxe6 Dc8 7.f5 gxf5 00:00:00
-/+ (-1.11) 1.Cg5 Fxg5 2.fxg5 Cb6 3.Cxb6 Dxb6 4.Td6 Db7 5.Dxc5 Fxg2 6.Da5 Tf8 7.Txa6 Db1 00:00:00
-/+ (-1.26) 1.Cg5 g6 2.Fd2 Fb5 3.Te1 Tb7 4.Fa5 Db8 5.Fd2 Fxc4 6.Dxc4 Tb1 7.Txb1 Dxb1+ 8.Rf2 Fxg5 9.fxg5 Df5+ 10.Rg1 00:00:00
-/+ (-1.37) 1.Cg5 g6 2.Fd2 f6 3.Ce4 Dd7 4.Te1 Fa4 5.Dc1 Db5 6.Ccd6 Dc6 7.Cc4 Cb6 8.Fa5 Dxe4 9.Fxb6 Fb5 00:00:00
-/+ (-1.37) 1.Cg5 g6 2.Te1 Fb5 3.Fd2 Fxc4 4.Dxc4 Tb5 5.Td1 Dd8 6.Dc2 Db8 7.Da4 Rg7 8.Dc2 Tb2 9.Fc3+ Cxc3 10.Dxc3+ e5 11.a4 00:00:01
-+ (-1.47) 1.Cg5 g6 2.Te1 Fb5 3.Fd2 Fxc4 4.Dxc4 Tb5 5.Cf3 Ff6 6.e4 Cb6 7.Dc1 c4 8.Fb4 Fe7 9.Fxe7 Dxe7 10.Rf1 Dc5 00:00:03
-+ (-1.54 --) 1.Cg5 g6 00:00:03
-+ (-1.47 ++) 1.Cg5 00:00:04
-+ (-1.54 --) 1.Cg5 g6 00:00:04
-+ (-1.53) 1.Cg5 g6 2.Te1 Fb5 3.Cf3 Cb6 4.Cxb6 Dxb6 5.Fd2 Fe8 6.Fc3 Db3 7.Dc1 Fc6 8.Cd2 Dd5 9.e4 Dd3 10.Fb2 f6 11.Fc3 c4 12.Rh1 00:00:04
-+ (-1.46 ++) 1.Cg5 00:00:05
-+ (-1.53 --) 1.Cg5 g6 00:00:05
-+ (-1.46 ++) 1.Cg5 00:00:06
-/+ (-1.31 ++) 1.Cg5 00:00:06
-+ (-1.43 --) 1.Cg5 g6 00:00:06
-/+ (-1.27 ++) 1.Cg5 00:00:08
-+ (-1.48 --) 1.Cg5 g6 00:00:08
-/+ (-1.19 ++) 1.Cg5 00:00:09
-/+ (-1.32) 1.Cg5 g6 2.Ce5 Fe8 3.e4 Cf6 4.Cc4 Dc6 5.Te1 Da4 6.Dxa4 Fxa4 7.e5 Cd5 8.Cd6 Tb1 9.g3 Fxd6 10.exd6 c4 11.Ce4 Fc6 12.Cc5 c3 00:00:09
-/+ (-1.29) 1.Cg5 g6 2.Ce5 Fe8 3.e4 Cf6 4.Cc4 Dc6 5.Te1 Da4 6.Dxa4 Fxa4 7.e5 Cd5 8.Cd6 Fxd6 9.exd6 c4 10.Ce4 c3 11.Rf2 Td8 12.Cc5 Fc6 13.Ce4 f5 14.Cc5 Txd6 15.Txe6 00:00:11
-/+ (-1.36 --) 1.Cg5 g6 00:00:11
-+ (-1.43 --) 1.Cg5 g6 00:00:12
-/+ (-1.36 ++) 1.Cg5 00:00:12
-+ (-1.44) 1.Cg5 g6 2.Ce5 Fe8 3.e4 Cf6 4.Cc4 Dc6 5.Te1 Da4 6.Dxa4 Fxa4 7.e5 Cd5 8.Cd6 Fxd6 9.exd6 c4 10.Ce4 c3 11.Cc5 Fc6 12.Cxa6 Td8 13.Rf2 Txd6 14.Cb4 Rg7 15.Cxd5 00:00:13
-/+ (-1.37 ++) 1.Cg5 00:00:14
Pas de 1. = (0.00): 1.Cc3 à l’horizon !
|
|
"Pas de 1. = (0.00): 1.Cc3 à l’horizon !"
oui, c'est exactement ce que je dis dans mon message du 07/02/2016 - 23:29:34 ci-dessus :
Si, comme vous venez de le faire, on part de la position initiale
Fen : 1r4k1/2q1bppp/p1b1p3/2pn4/2N1NP2/P3P3/2Q3PP/2BR2K1 w - - 0 1
alors Stockfish ne joue pas 1.Cc3, et préfère 1.Cg5, ce qui est normal.
Mais si, pendant une vraie partie, on a la position
Fen : 1r4k1/2q1bppp/p1b1p3/2pn4/2N2P2/P1N1P3/2Q3PP/2BR2K1 b - - 0 22
et que l'on (nous, humains) joue 1...Ff6 , alors Stockfish répond 2.Ce4 , on (nous, humains) poursuit avec 2...Fe7 arrivant à la position clef... Et là, contrairement à l'analyse que vous présentée ci-dessus, Stockfish répète la position par 3.Cc3 pensant obtenir le nul par répétition de coup. Et se faisant, il rate un meilleur coup, à savoir 3.Cg5 comme vous l'avez noté avec l'analyse que vous présentée ci-dessus.
|
|
Cg5 n'est pas meilleur.
2. -/+ (-1.43): 24.Cg5 g6 25.Ce5 Fe8 26.e4 Cf6 27.Cc4 h6 28.Cf3 Dc6 29.Te1 Da4 30.Dxa4 Fxa4 31.Fb2 Ce8 32.f5 Tb3 33.fxg6 fxg6 34.Tb1 Cd6 35.Cxd6 Fxd6 36.Cd2 Tb7 37.Cc4 Fe7 38.Ce5 Rh7 39.Cc4
|
|
D’accord avec Leon1789. J’avais déjà remarqué cet affichage intempestif d’évaluations à = (0.00). Ce bug semble anodin lors d’une analyse lorsqu’on sait la chose, mais il est susceptible, à mon sens, en situation de partie, de fausser gravement les estimations et de générer des bévues très préjudiciables, de la part de Stockfish et de Komodo, les 2 seuls que j’ai testés (mais c’est tout de même le haut du panier, non ?).
Imaginons le petit scénario suivant :
Un joueur humain, avec les Blancs, obtient cette position écrasante contre Stockfish qui a le trait. Le module donne +- (51.08) sur 1…Dd1+, mat en 6 sur 1…Rg8 et mat en 1 sur tout autre coup. Les Noirs jouent donc :
1…Dd1+
Les Blancs doivent maintenant couvrir avec 2.Fe1 pour dévier la dame de la case d6 avant de se réfugier en h2 avec leur roi. Le module propose 2.Fe1 Dxe1+ 3.Rh2 De5+ ou Rg8 et mat en une vingtaine de coups. Mais l’homme est faillible. Imaginons, pour la vraisemblance, qu’il ne dispose que de quelques secondes à la pendule pour boucler son 40ème coup ; d’autre part le sacrifice 2.Fe1 n’est pas un de ces coups qu’on joue spontanément en zeitnot.
2.Rh2 ??
La gaffe qui laisse échapper le gain. Stockfish se précipite évidemment et joue :
2…Dd6+
Maintenant les Noirs vont rafler le pion g6 et annuler la partie. Après 2.g3 ou n’importe quel coup du roi blanc (pas vraiment, on le verra), le module donne = (0.07). Nulle donc malgré le pion de mieux, surtout si l’on tient compte aussi des paramètres pions doublés et fous de couleur opposée.
Mais le joueur qui a les Blancs a bouclé son 40ème coup et dispose désormais de tout son temps. Il voit qu’il a loupé 2.Fe1. Il a lu le fil de Leon1789 et connait donc le point faible de la bête. Une idée lui vient:
3.Rh1 (!!)
Et Stockfish tombe dans le panneau :
3…Dd1+ ??
Effrayé par le nano-avantage blanc = (0.07) après 3…Dxg6, il choisit de prendre la nulle (croit-il…) en répétant la position une seule et unique fois et en affichant bien sûr = (0.00). Ce faisant, il laisse les Blancs retirer le pénalty. Ceux-ci en profitent évidemment pour jouer :
4.Fe1 et ils gagnent la partie comme vu plus haut.
Proprement stupéfiant de perdre ainsi ½ point lorsqu’on a un tel niveau ! Komodo réagit de la même manière. J’ai essayé plusieurs positions de ce type où les 2 modules permettent au camp qui a manqué le gain mais conserve un minuscule avantage, de gommer sa gaffe. Ça marche à tous les coups.
Je n’y comprends rien en programmation, mais peut-être ce bug risque-t-il d’influer en permanence sur les analyses de ces 2 modules en agitant sans cesse, en aval de la partie, ce spectre ridicule de la répétition unique annulante. Et donc, lorsque Stockfish propose un premier choix à = (0.25), qu’est-ce-qui me garantit qu’il n’a pas occulté un coup à +- (2.60) du fait de son interprétation loufoque des règles de la répétition ? Auquel cas il faudrait vérifier "à la main" toutes les lignes proposées (notamment les = (0.00)), ce qui serait évidemment très fastidieux.
|
|
je ne pense pas qu'il s'agisse d'un bug. C'est certainement handicapant pour analyser une partie si on cherche le meilleur coup, mais probablement pas un bug.
En effet, dans l'optique d'obtenir le meilleur résultat possible dans une partie, mieux vaut aller dans une position évaluée à -2 si on considère que l'adversaire va peut-être répéter les coups (par exemple s'il ne voit pas qu'il a une meilleure suite) que de choisir une position à -1 où celui-ci sera obligé de jouer.
Cela est encore plus vrai dans une partie entre modules : si l'adversaire cybernétique a raté une première fois la bonne variante, il est quasi certain qu'il la ratera une seconde fois (je n'ai pas encore vu implémentée la répétition pour gagner du temps chez les modules). Comme on sait que de nos jours, pour évaluer les modules, on ne les fait jouer qu'entre eux, il ne faut pas être surpris de cette attitude terre à terre.
|
|
Hum... Je ne suis sûr de rien, dan31, mais je constate que dans le cas de figure que je propose, Stockfish lâcherait tout de même 1/2 point dans le cadre d'une partie jouée contre un humain, non?
D'autre part je crois bien que je dis une ânerie dans mon dernier paragraphe. Impossible, si c'est lui qui joue la partie, qu'il occulte un coup à +- (2.60) pour en jouer un à = (0.25). Car pourquoi n'aurait-il pas joué ce fort coup au moment où la position, qu'il craint maintenant de répéter, est apparue pour la première fois sur l'échiquier? Sauf à supposer qu'il ne joue pas pour son propre compte, qu'il analyse une partie jouée par des humains et que ce fort coup a bien été effectué une première fois par le joueur mais qu'il n'a pas su exploiter l'avantage qui en découlait.
|
|
@regicide : je n'ai pas lu ton message avant d'écrire le mien, il était probablement en cours de rédaction. J'ai besoin de temps pour le lire et le comprendre mais ça a l'air intéressant !
Je me risque quand même à une réaction rapide après lecture en diagonale (désolé si elle est hors-sujet) : je pense que les programmeurs ne programment de nos jours que pour jouer contre d'autres modules. En effet l'homme est largement battu et ce qui fait foi pour faire de la publicité pour son propre programme est le classement elo des machines basé sur des parties entre modules, comme les listes elo CCRL et CEGT.
Pour le programmeur, il n'y a aucune raison que l'adversaire de son programme (un module aussi !) ne répète pas un coup qu'il a déjà joué (les modules ne font pas encore de coups psychologiques). En effet, si la répétition est possible une fois, c'est que la nulle est dans la poche, et autant dans ce cas éviter les autres possibilités plus désagréables.
|
|
@Lefouduroi
Disons que Cg5 (évalué à -1.3 ou -1.4) est théoriquement nettement moins mauvais que Cc3 (évalué à -2.2). Donc un module devrait jouer Cg5 et non Cc3.
@regicide
C'est un exemple comme le vôtre que j'aurais aimé présenté ! Rater un résultat nul assuré (en défendant correctement), en croyant l'obtenir simplement par répétition. :)
Mais, pour le nec plus ultra, j'espérais tomber dans une telle situation lors d'une partie, pas à partir du position artificielle (pour éviter certaines contestations).
@dan31
Je suis d'accord avec vous, quand vous dîtes que les modules sont (malheureusement !) programmés pour jouer contre d'autres modules et non contre des humains. Et en effet, dans ce cas de confrontation machine-machine, il n'y a pas de répétition de position, je pense, a priori. Mais attention, le temps de réflexion pourrait avoir un impact : peut-être qu'un module pourrait jouer un coup en manque de temps, puis l'instant d'après (bénéficiant d'un temps supplémentaire) préférer revenir à la position pour jouer un coup différent, un peu comme nous parfois... Enfin, là, je fais un peu dans la supposition, j'en conviens.
|
|
@Leon1789 :"peut-être qu'un module pourrait jouer un coup en manque de temps, puis l'instant d'après (bénéficiant d'un temps supplémentaire) préférer revenir à la position pour jouer un coup différent, un peu comme nous parfois..."
C'est tout à fait possible, mais une fois sur combien de parties ? Il faut déjà qu'il y ait une répétition, puis être dans une configuration très rare au niveau des temps de réflexion.
Les programmeurs sont pragmatiques : à mon avis, plutôt qu'un bug, c'est quelque chose qui améliore les résultats moyens de la machine. En effet, le programme va y gagner assez souvent : en jouant Cc3 au lieu de Cg5 dans votre exemple, il annulera quasiment à coup sûr contre un module adverse (qui n'a aucune raison de ne pas se tromper une deuxième fois s'il s'est déjà trompé une première fois en jouant Ff6). S'il avait joué Cg5, il aurait eu plus de chance de perdre.
Il faut savoir que les modifications mineures de programme (comme celle qui ferait disparaître ce soi-disant bug) sont testées en faisant jouer des milliers de parties à vitesse ultra rapide à la machine (le plus souvent contre elle-même, en tout cas pour stockfish !). On garde une modification du code informatique si la performance elo après modification, évaluée sur ces milliers de parties, est améliorée. On ne cherche donc pas la vérité échiquéenne mais la performance elo contre une adversité donnée. Il y a fort à parier qu'avec ce bug, la machine est plus performante et qu'il est laissé volontairement.
|
|
Oui, je comprends bien (cf mon message du 10/02/2016 - 13:32:57)
Mais d'un autre coté, les modules comme Houdini n'ont pas le même "bug volontaire". Je pense pourtant qu'ils sont, eux aussi, optimisés après une multitude de tests. Du coup, je trouve que tout cela n'est pas si net que ça... :)
|
|
@Leon1789
Je me suis permis de revenir sur la première partie de l’article pour quelques informations complémentaires.
Copier-collé position :
2rr2k1/3bBppp/8/p1p5/1p2P3/7P/PP1N1PP1/R5K1 b - - 0 26
Copier-collé partie :
[Event "?"]
[Site "?"]
[Date "????.??.??"]
[Round "0"]
[White "Blancs"]
[Black "Noirs"]
[Result "*"]
[PlyCount "0"]
1. e4 e5 2. Nf3 Nc6 3. Bb5 Nf6 4. O-O d6 5. Re1 Be7 6. h3 O-O 7. c3 Bd7
8.d4 exd4 9. cxd4 a6 10. Ba4 b5 11. Bb3 Na5 12. Bc2 c5 13. d5 Qc7
14. Nc3 Rac8 15. Bg5 Rfe8 16. Qd2 Nc4 17. Qc1 b4 18. Nd1 a5 19. Ne3 Nxe3
20. Qxe3 Bd8 21. Nd2 Nxd5 22. Bxd8 Nxe3 23. Bxc7 Nxc2 24. Bxd6 Nxa1
25. Rxa1 Red8 26. Be7 *
Je n’ai pas du tout de 26.… Te8 gagnant mais plutôt d’autres coups pour les noirs cherchant le gain à l’exception de Shredder qui joue ce coup. Quand on utilise diverses générations de modules de 2000 à 2016 (comme par exemple de Fritz 5.32 à Stockfish 7), on obtient nettement dans cette position un résultat relatif à l’évolution des algorithmes des modules, ce qui est normal.
L’intervention de guitov, le 04/05/2015 - 23:12:52 semble justifiée car effectivement en passant d’un copié-collé de la partie à la position on obtient bien respectivement avec Stockfish 6 26.… Fb5 ou 26.… Te8 dans ce cas où on change les conditions de départ pour l’analyse. Dans un premier temps, le problème semble avoir à l’origine la relation protocolaire interface-module, l’output analysis du module. Mais voilà, en analyse infinie Stockfish 6 propose 27. Fd6 = (0.00) et il enchaîne tout de suite avec 27… Tc6 - + (-2.46), ce qui est absurde. Il semble que l’on puisse parler de bug ou pour le moins dans le doute d’anomalies manifestes pour ce qui est de la sortie du coup en fonction du mode d’analyse dans l’interface d’une part et pour l’estimation de la position d’autre part.
|
|
en trainant sur les forums, on peut trouver la réponse de l'auteur de stockfish : https://groups.google.com/forum/#!topic/picochess/gNEk0vVNBaw
"I am aware that SF marks a position as draw the at the first repetition. This works well in parctice (modulo patological cases) and
is considered the standard approach.
Pelase feel free to try [to fix] but I will commit any "fix" only if it has
zero performance hit. "
Traduction :
Je sais que Stockfish évalue une position comme nulle dès la première répétition. Cela marche bien en pratique (modulo quelques cas pathologiques) et cela est considéré comme l'approche standard. Vous pouvez essayer de corriger le code mais je ne m'engagerai dans cette voie que si cela ne dégrade pas la performance.
|
|
CQFD :)
|
|
Il y a semble t-il plus intéressant que Stockfish pour l'analyse.
Le nouveau module venu Komodo (avec sa version gratuite 7a, récente et très forte) est téléchargeable sur le site des auteurs. Il estime les positions avec plus de régularité. Il est vrai que l'équipe de développeurs est composée d'un professionnel du jeu d'échecs qui est grand maître international et chargé entre autres de vérifier l'estimation des positions effectuées par Komodo.
|
|
|
|