Sai esempio in cui i recenti motori di scacchi (Houdini, Rybka, Komodo, ...) non sono riusciti a trovare un scacco matto forzato.
Immagino che debbano trovare sempre il compagno 1 o 2, ma forse non riescono a essere creativi come umani a volte.
Sai esempio in cui i recenti motori di scacchi (Houdini, Rybka, Komodo, ...) non sono riusciti a trovare un scacco matto forzato.
Immagino che debbano trovare sempre il compagno 1 o 2, ma forse non riescono a essere creativi come umani a volte.
Risposte:
Positivo questa risposta in aggiunta alle risposte / commenti su tablebase ed endgames con compagni forzatamente ridicolmente lunghi.
White per muoversi e vincere (purtroppo non conosco l'autore di questo studio). I motori tenderanno a fallire su questo e problemi simili. Per quanto ho provato, tutti raccomandano di spostare hxg8 = Q. Alcuni mostrano 0,00 e presto stanno mettendo il nero in una situazione di stallo; alcuni mostrano un leggero vantaggio per il bianco e stanno provando a giocare lasciando che il nero attivi i suoi pezzi. Ulteriore spiegazione (e suggerimento per la soluzione) fornita nel blocco spoiler sotto il diagramma.
Spoiler di spiegazione:
Il compagno forzato non viene trovato perché i motori utilizzano l'euristica della potatura. Rimuove alcuni rami dall'albero di ricerca, dopo averli considerati irrilevanti per il risultato della ricerca (vedere: http://chessprogramming.wikispaces.com/Pruning ). Nel caso di questo enigma, la soluzione consiste in molti sacrifici successivi e il suo ramo tende a essere scartato durante la ricerca. Nota: possibilmente, con parametri ottimizzati ed euristica di ricerca accoppiata quando viene fornito il numero esatto di mosse richieste, potrebbero trovare la soluzione, ma non l'ho provato.
Spoiler della soluzione:
A seconda delle scelte di mossa del nero, esistono alcune soluzioni (l'idea è sempre la stessa, però e fino alla mossa 12 la linea è sempre la stessa). Ecco un esempio: 1. hxg8 = N d5 2. Bf3 d4 + 3. Kb4 d3 4. Nh6 gxh6 5. g7 h5 6. g8 = N h4 7. Nf6 exf6 8. e7 f5 9. e8 = N f4 10. Nd6 cxd6 11. c7 d5 12. c8 = N dxc4 13. Nb6 c3 14. dxc3 d2 15. Kb3 d1 = Q 16. Rxd1 axb6 17. a7 b5 18. a8 = Q b4 19. Be2 bxc3 20. Bf1 c2 21. Rc1 f3 22. Qxf3 Bf2 23. Bxg2 + #
Ci sono alcune posizioni difficili, in cui sembra che non ci sia soluzione, ma poi si scopre che il bianco deve essere in grado di prendere en passant. In queste posizioni i motori potrebbero trascurare il compagno, perché non hanno le informazioni sull'ultima mossa nera, mentre un essere umano può dedurre queste informazioni mediante analisi retrograda.
In questa posizione è impossibile determinare quale variazione porta all'accoppiamento in due. È possibile solo dimostrare che ci deve essere un compagno in due varianti. O il nero muoveva il pedone nella sua ultima mossa - poi prendere en passant porta al compagno. Oppure spostava il suo re o torre - quindi il re e6 conduce al compagno, poiché non è più possibile il castling.
Modifica: un'altra risposta, che è altrettanto irrilevante per tutti gli scopi pratici: Come tutti sappiamo grazie ai tablebase, c'è un gran numero di compagni di controllo forzati là fuori, che sono ben oltre l'orizzonte di calcolo di qualsiasi motore. Ovviamente possiamo usare i tablebase per rilevare quei compagni, ma non ci vuole alcuno sforzo d'immaginazione, per riconoscere l'esistenza di compagni di controllo forzati su migliaia di mosse, che non sono ora e probabilmente non verranno mai archiviate in un tablebase .