|
| Le problème informatique du dimanche par Vi***nt**2012 le
[Aller à la fin] |
| Informatique | |
Soit le diagramme ci-dessous. Rien à dire c'est mat certain pour les noirs. D'ailleurs Fritz 8 ne s'y trompe pas et annonce après 62.f4 un mat en 6 (-6#) débutant par 62...Dg1+
Mais là où je ne comprends pas le chess engine, c'est qu'une fois joué 62...Dg1+, il annonce mat en 8 (-8#) avec la réponse 63.Rh3
Faut-il en déduire qu'il existe un effet d'horizon même sur les mats ?
VincentB, dimanche dubitatif
|
|
|
Pour vous faciliter la tâche ...voici le FEN :
8/8/8/4R2p/1r3P1P/2k3K1/5P2/1q6 b - - 0 62
VincentB, prévenant
|
|
|
Vérifie l'utilisation du processeur tu constateras que dès qu'une ligne de mat est trouvée, le module arrête de travailler.
Les modules de jeu ne sont pas des modules de recherche de mat. Pour eux il suffit de trouver une ligne gagnante, ce qui met fin à leur calcul.
Les différentes versions de l'interface Fritz sont livrées avec un module spécialisé pour la recherche de mat. Pour le mettre en oeuvre: Outils-Analyse-Recherche de mat.
Il existe des modules plus performants disponibles également en version UCI comme ChestUCI 5.1 ou Popeye 1.7 (voir en fin de liste sur la page suivante).
|
|
|
C'est une bonne remarque Mais je ne suis pas sûr qu'elle réponde à la question:
Cela expliquerait que le nombre de coups avant le mat diminue (de plus que 1) après avoir joué un coup, mais pas qu'il augmente.
Ici si la machine c'est arrêtée dès qu'elle a trouvé un mat en 6 par Dg1 pour les noirs, c'est que ce mat doit bien exister, sur toute réponse blanche (même s'il y a peut-être plus rapide). Si ensuite la machine voit un mat en 8 sur 2.Rh3, elle devrait continuer à chercher un meilleur coup pour les blancs.
Ah, ou alors, peut-être y a-t-il bien une ligne qui fait mat plus rapidement après 2.Rh3, mais Fritz arrête de calculer ce coup dès qu'il trouve un mat forcé pour les noirs ensuite, fut-il plus long? Mis les moteurs n'ont-ils pas à présent de sfonctions "mémoires" qui leur évite de recalculer après chaque demi-coup, et qui fait qu'il n'aurait dû "oublier" le mat rapide déjà calculé après Rh3 ?!
Bon, je ne sais pas si tout le monde m'a suivi, mais ce qui est clair, c'est que je n'entrave goutte à ces logiciels.
|
|
|
il existe 1... Qg1+ 2. Kh3 Rxf4 3. Re3+ Kd2 4. f3 Rg4 5. Re2+ Kxe2 6. fxg4 hxg4# (6...
Qxg4+ 7. Kh2 Kf1 8. Kh1 Qg2#) *
Rybka 3 donne bien le mat en 6, mais à un coup du mat, il donne en première variante le mat en 2 (la variante commençant par Dxg4), ensuite un mat en 3 puis le mat en 0 (hxg4)
|
|
|
Ref puch Avec les mêmes réserves que toi en ce sens que je sens plus les trucs qu'autre chose...
Ce qui coûte le plus de temps lorsqu'un logiciel tourne, ce ne sont pas les calculs du processeur mais les temps d'enregistrement en mémoire. C'est la raison pour laquelle ceux-ci interviennent seulement lorsque cela peut, au final, constituer un gain de temps. Sinon on laisse le calculateur refaire ses calculs car c'est en fin de compte plus rapide comme ça.
Pour éviter de disperser trop rapidement la capacité de calcul des moteurs, on oriente leur profondeur d'analyse sur les coups leur paraissant plus prometteurs au premier abord. Ce qui fait qu'il trouvera d'abord un mat en 8 dans une variante où les choses lui semblent bien engagées plutôt qu'un mat en 6 dans une variante où il a l'impression, par exemple, de commencer à filer du matériel sans réelles compensations.
Dans l'exemple de VincentB, il peut privilégier dans un premier temps une variante qui le conduit à trouver un mat en 6, puis, au demi-coup suivant, alors qu'il reprend tout à zéro, privilégier une autre variante qui le conduira à trouver en premier un mat en 8.
Ce que les moteurs enregistrent systématiquement, dans le cadre de leur analyse sur une position donnée, ce sont les différentes positions rencontrées et leurs évaluations en fin de calcul. L'intérêt étant, de ne pas recalculer un nombre colossal de fois une position déjà examinée. Les couteux temps d'enregistrement sont alors pleinement justifiés.
Lorsque le moteur tourne en mode de recherche de mat, là, par contre, il ne privilégie aucune variante et il calcule et enregistre tout. Il trouvera donc forcément le mat le plus rapide mais cela lui prendra généralement plus de temps qu'un mat "quelconque", qui est quand même d'un plus grand intérêt pratique.
J'espère n'avoir pas dit trop de bêtises...
|
|
|
Mat c'est mat Pour un logiciel un mat est un mat. En phase de jeu, il ne lui importe pas de faire mat en 6, 8 ou 16. Toutes les 3 solutions sont des gains.
Il se pourrait que l'option "Persistent Hash" de Rybka puisse remédier à cela. Il faudrait essayer.
Comme je le précisais plus haut, il y a des modules spécialisés pour les recherches de mat.
|
|
|
