lichess.org
Donate

mindbogglingly Engine behaviour

#1
I analysed this endgame position where white gets a queen for a rook. I got confused that the engine only said +1.3 at depth 23 so i let it running and surely enough at deapth 24 it said + 24 and i was happy with the conclusion that the engine realises it is winning with a queen agianst a rook. But then at deapth 25 it jumped back to +1.3. I checked for some more minutes and every time the engine said +30something it jumped back to 1.3 with an only move for black until I reached the next deapth. Does anyone have an explination why this is happening? (its always an tablebasewin)

1r6/1P3P2/3K4/8/3k4/8/8/8 w - - 0 1
#2
pls try to win this against the engine (before you reach the 50 move rule ;) good luck!

so i think the engine cant know it will win as long as it cant precalc those moves, and thats a hard thing to do, even when you throw gigabytes of hash into the ring. your jump may indeed have to do with cachesize and cache and how it is filled already when you move back and forth.

Also in my test with a standalone version of current stockfish i dont see those jumps, it like constantly grows in eval, see: pastebin.com/MdKsBKpe

per line you can read the depth reched and the eval after cp in centipawns (tho its not real centipawns anymore, but the cp name stays because thats uci api)
#3
Engines aren't good at some things. One of those things is Q v R endgames (which Black can quickly force here!). This is why we have tablebases, and a real chess playing engine will of course just switch to the tablebase when the number of pieces is sufficiently low. Humans are also terrible at Q v R, just assume that the Queen wins if and only if she's up on time. (And maybe then with some randomness, too, if the players aren't high-level.)

Some QvR endgames are draws by 50-move rule, others are wins for the rook, just because they are. Just try to avoid situations where all your pawns can get taken to be certain.
#5
@enubbsenub said in #3:
> Engines aren't good at some things. One of those things is Q v R endgames (which Black can quickly force here!). This is why we have tablebases, and a real chess playing engine will of course just switch to the tablebase when the number of pieces is sufficiently low. Humans are also terrible at Q v R, just assume that the Queen wins if and only if she's up on time. (And maybe then with some randomness, too, if the players aren't high-level.)
>
> Some QvR endgames are draws by 50-move rule, others are wins for the rook, just because they are. Just try to avoid situations where all your pawns can get taken to be certain.

Are you sure you know what you're talking about? These endgames were believed to be a draw until the first engines discovered that the queen wins, and that was before endgame tables existed. Can you provide some specific positions where a draw happens because of the 50 move rule? Can you provide some where the side with the rook can force a win? As far as I know there's like three specific positions that are drawn, and in all the other cases the queen wins. This just sounds like you're making it up.
#6
@mortmann said in #2:
> pls try to win this against the engine (before you reach the 50 move rule ;) good luck!
>
> so i think the engine cant know it will win as long as it cant precalc those moves, and thats a hard thing to do, even when you throw gigabytes of hash into the ring. your jump may indeed have to do with cachesize and cache and how it is filled already when you move back and forth.
>
> Also in my test with a standalone version of current stockfish i dont see those jumps, it like constantly grows in eval, see: pastebin.com/MdKsBKpe
>
> per line you can read the depth reched and the eval after cp in centipawns (tho its not real centipawns anymore, but the cp name stays because thats uci api)
thank you for your answer

i konw how difficult Q vs R can be, i had this against somenoe 500 Elo below me OTB but he knew some defensive strategies and i barely maneged to win after a very long time and some luck since he blundered at some point

i am not very skilled with engine analyis so i am not able to read your link but i get your point. what is still curious to me is that i have the feeling that in previous versions of stockfish it always had a strong evaluation for material advantage, so Q vs R would be +4, B K and P against K with the wrong colored bishop would be +3 and so on

could it be that the evaluation progress has changed recently?
#7
@enubbsenub said in #3:
> and a real chess playing engine will of course just switch to the tablebase when the number of pieces is sufficiently low.
name one "real" chess engine, that comes with a tablebase for endgames.
stockfish certainly is no "real" chess engine then ;)
#9
@mortmann said in #8:
> yes. new evaluation since 15.1:
> stockfishchess.org/blog/2022/stockfish-15-1/
> and not long ago the disruptive shift to neural network replacing handcrafted eval function.

"+1 is now no longer tied to the value of one pawn, but to the likelihood of winning the game. With a +1 evaluation, Stockfish has now a 50% chance of winning the game against an equally strong opponent"

feels like a very hard change
#10
3q4/4k3/8/8/8/3K4/2P5/3R4 w - - 0 1 - position that takes over 75 moves to mate (however this one zeros just in time? I remember it not... maybe I have something in the wrong place, will look for better example)

3q4/3k4/8/8/8/8/4K3/6R1 w - - 0 1 - position where the rook obviously draws easily

8/8/4kq2/8/2K5/PR6/8/8 w - - 0 1 - position where the rook obviously wins easily

A/B engines predate tablebases. FIDE actually temporarily changed the 50 mover rule to 75 because the fate of these positions were unknown until tablebases. I actually programmed these things for awhile in college.

more importantly, please remain kind

This topic has been archived and can no longer be replied to.