Bug in Stockfish 15.1?
In mijn rubriek van 11 februari staat een probleem van Jac. Haring: mat in 10. Ik check dat dan altijd met de computer, maar opmerkelijk genoeg vindt mijn Stockfish 15.1 de oplossing niet.
Zelfs na lang rekenen op 1 thread komt ie niet in de buurt van de oplossing, terwijl het toch maar 19 ply diep is. Is de stelling dan zo moeilijk? Nee, want Stockfish 14 (en ouder) vindt de oplossing wel. Hoe komt dit? Een bug in 15.1?
Als u het met uw eigen engines wilt controleren, de FEN-string is 4N3/8/8/6pR/4B3/3p2p1/3Pp1p1/4K1kb w – – 0 1 .
Het zou natuurlijk een bug kunnen zijn, maar ik verwacht van niet, niet in ieder geval iets dat door de ontwikkelaars van Stockfish als bug beoordeeld zou worden.
Het is niet de bedoeling van Stockfish om iedere denkbare stelling correct te beoordelen, en al helemaal niet als dat om studies gaat. Het doel is om zo veel mogelijk partijen te winnen. Om dat te doen worden bij iedere wijziging duizenden, soms honderduizenden, partijen gespeeld om te beoordelen of deze wijziging postitief is. Tegenwoordig is een verbetering van maar 1 ELO al erg mooi.
En als dan door een wijziging deze stelling niet meer wordt opgelost, maar 2 andere wel, dan is dat dus winst. Kennelijk heeft de wijziging die er voor zorgde dat deze stelling niet meer snel wordt opgelost, elders tot meer gewonnen partijen geleid.
Ziet Stockfish 15 wel gelijk een mat in 11 of meer? Dan maakt het, zoals Ton al schreef, niet uit gezien het waarschijnlijke doel van de ontwikkelaars.
Mijn oude Fritz10 ziet het mat in 10 binnen 2 seconden (al probeert hij er later, merkwaardig genoeg, toch een mat in 11 van te maken), maar zal in een match over tien partijen hoogstwaarschijnlijk zelfs geen enkele remise halen tegen SF15.
Tim Krabbé heeft beschreven hoe zijn software (al lang geleden) een afwikkeling koos naar een voor mensen moeilijke tablebasewinst, omdat die eerder te bereiken was dan het opgelegde mat (of materiaalwinst, dat weet ik niet meer). Voor die software was er blijkbaar geen wezenlijk verschil tussen mat of een tablebasewinststelling.
Nee, een ander mat wordt vanuit de beginstelling ook niet gezien. Er wordt 1. Th3 gespeeld, de Toren wordt geruild tegen de drie g-pionnen en de Lopers gaan er af. Paard en pion tegen 2 pionnen is daarna mat in 23.
Maar het vinden van het snelste mat vanuit elke stelling is dus niet het doel van de ontwikkelaars. Het doel is het winnen van de meeste partijen. Dat dat daarnaast tot gevolg heeft dat heel veel stellingen het snelste mat wel wordt gevonden, is mooi meegenomen 🙂
Er zijn forks van Stockfish die sterker zijn in het oplossen van problemen, maar die zijn dan vaak wel een paar honderd ELO zwakker in normaal spel.
Het is geen studie maar een probleem, een belangrijk verschil. Stockfish 15.1 maakt er op diepte 83 mat in 30 van. Het zou inderdaad kunnen dat de nieuwe versie overgang naar een gewonnen eindspel goed genoeg vindt en dan te lui is om het mat uit te rekenen.
Het verschil tussen probleem en studie kijk ik later nog wel eens na, maar maakt voor Stockfish niet uit, die kijkt alleen naar stellingen die aangeboden worden.
Engine is niet te lui om door te rekenen, er wordt net zo lang verder gezocht totdat dat door gebruiker wordt gestopt. Probleem bij deze stelling lijkt te zijn dat de eerste zet die tot mat leidt niet (diep genoeg) wordt bekeken, waardoor het zoeken naar het mat plaatsvindt bij zetten waar dat mat in 10 niet te vinden is.
Een sterk punt van Stockfish is juist de ‘pruning’, het mechanisme waarop delen van de zoekboom worden beperkt, waardoor in de overblijvende delen dieper gezocht kan worden. Het huidige mechanisme snijdt in deze stelling kennelijk een takje teveel af.
Mijn engine (laatste SF dev) vond het ook niet…
Wat ik opvallend vind is dat zodra je Th8 aan de engine geeft als eerste zet hij wel gelijk het mat vind…
Engines staan erom bekend om in eerste instantie ALLE zetten te bekijken…
Na Th8 heeft zwart ook maar 1 zet zodat het dus ook niet veel extra rekenkracht kost om varianten daarna te berekenen…
Wat de engine dus blijkbaar niet gelijk ziet is de zigzag manoeuvre met Lh7 etc om pat te voorkomen…
Dat is als mens juist het eerste waar je naar kijkt omdat je gelijk ziet dat de zwarte koning weinig zetten heeft en je dus op moet passen voor patwendingen…
Ik vraag me af wat stockfish (heb ik niet) met het mat in 203 zetten van Jörgensen doet (en.chessbase.com/post/longest-dual-free-direct-mate-problem#:~:text=The%20longest%20dual%2Dfree%20direct,the%20problem%20to%20203%20moves. Chessbase 5/12 2015). Het ‘prunen’ lijkt me eenvoudig: als je zwart even loslaat, wint hij eenvoudig – er komt dus steeds maar Ă©Ă©n zet voor wit in aanmerking als hij wil winnen. Of gaat stockfish voor driemaal dezelfde stelling? Er is hier immers geen andere, langer durende oplossing zoals in het probleem van Haring.
Overigens is dit fenomeen mogelijk een klein beetje goed nieuws voor prijsvragen: valsspelende oplossers kunnen met dit soort meerzettige problemen blijkbaar niet meer volledig op hun computer vertrouwen…
Na een half uurtje rekenen komt Stockfish nog niet verder dan de zetherhaling.
Ben wel benieuwd of dit inderdaad geforceerd mat in 203 zal zijn. Zal niet de eerste keer zijn dat na computer controle een eerder gedachte oplossing toch nog niet waterdicht bleek.
Prunen is wellicht eenvoudig als je weet dat de uitslag 1-0 is. Er zijn dan ook wel speciale versies gemaakt (matefinder bv) speciaal met dit doel, waarbij delen van die pruning uitgezet werden.
Maar als je dat niet weet, en je een engine maakt die in zoveel mogelijk gevallen, zo snel mogelijk (want de klok tikt) de winnende zet moet produceren, blijkt aggressief prunen meer winstpartijen op te leveren dan minder aggressief. De inspanning in het verbeteren van de ‘Search’ zit’ m dus in welke situaties moeten wel, en welke niet bekeken worden.
Het lijkt me waarschijnlijker dat Fritz10 een potje van Stockfish15 wint dan dat er een fout zit in dit probleem. De essentie van dit soort veelzettige problemen is juist dat er heel weinig variatie mogelijk is. Het zijn machientjes die, eenmaal aangezet, vanzelf blijven lopen. Als er al een fout in zou zitten, lijkt het me waarschijnlijker dat een mens dit ontdekt dan dat een engine dit doet.
Ik ben niet (meer) zo verbaasd dat de sterkste engines van vandaag het er bij dit soort problemen soms nauwelijks beter of zelfs slechter vanaf brengen dan veel oudere, ‘dommere’ software. Zie wat dat betreft ook het rondspringende paard uit het artikel pas geleden van Herman Grooten. Ik vind het wel interessant om te kijken hoe die moderne engines werken. Het maakt ze blijkbaar niet uit of iets een mat in 10 of in 11 is. Ze kunnen relatief snel heel diep rekenen door zich niet met dit soort ‘futiliteiten’ bezig te houden. Maar daar zit dus een grens aan, zelfs bij een voor mensen redelijk simpel mat in 203. Je hoeft bijna alleen het mechanisme zien waarmee je jezelf steeds aan zet brengt.
Een volgende stap zou kunnen zijn om te kijken of stockfish het mat uiteindelijk wel vindt in een partij. Hij denkt dat in de beginpositie driemaal dezelfde stelling het beste resultaat is, maar in een partij zal hij waarschijnlijk kiezen voor tweemaal dezelfde stelling en vervolgens een zet die niets verpest. Gezien het karakter van het probleem – los van het herhaalde patroon heeft wit een beperkt aantal koningszetten en kan zwart alleen pionzetten doen – lijkt het me dat stockfish uiteindelijk mat zal zetten. Maar op welk moment geeft hij aan een geforceerd mat te zien? Dat zal ongetwijfeld een functie zijn van de tijd die je hem per zet geeft, maar dat is dan weer vergelijkbaar met anderssoortige problemen.
Ik vraag me af vanaf hoeveel ply zouden we het -wel- ernstig zouden vinden? Ik vind 19 ply vrij ernstig voor een schaakengine. Ook al kan het daarnaast andere winnende varianten vinden.
Een eenvoudig mat in 10 niet vinden is een zeer ernstige fout in Stockfish 15.1, daar kunnen we kort over zijn.
Zoals Ton eerder aangaf is Stockfish niet ontworpen om het snelste mat te vinden, maar om zoveel mogelijk partijen te winnen tegen de eerdere (master) versies…
In het probleem van Dimitri vind hij nog steeds snel een winst… Alleen niet het snelste mat…
Dat lijkt me een stuk minder erg dan in het probleem van Frits waar hij ipv een geforceerd mat remise geeft door zetherhaling…
Het probleem wordt veroorzaakt door het Neural Network, zo te zien. Als ik de optie Use NNUE uitschakel, dan vindt mijn SF 15 versie het mat in 10 onmiddellijk.
Waar SF 15 ook voor ontworpen is, het blijft hoogst opmerkelijk. Zelfs Chess Genius (in feite een Engine uit de negentiger jaren) vindt de mat binnen enkele seconden op m’n iPad…
Bij wijze van experiment heb ik de diagramstelling uit het artikel drie keer gespiegeld:
– Horizontaal gespiegeld ten op zichte van de verticale middenlijn van het bord
– Verticaal gespiegeld ten opzichte van de horizontale middenlijn van het bord, met verwisselde kleuren
– Diagonaal gespiegeld ten opzichte van het middelpunt van het bord, met verwisselde kleuren
Hierbij had ik de hoop dat SF 15 met NNUE de matoplossing wel zou vinden, maar dat bleek toch niet het geval.
Wel zag ik dat SF voor de vier spiegelingen, die in feite identiek zijn, met verschillende varianten kwam in het evaluatieproces.