Endgame fortress handling

Discussion of anything and everything relating to chess playing software and machines.

Moderator: Ras

User avatar
cdani
Posts: 2204
Joined: Sat Jan 18, 2014 10:24 am
Location: Andorra

Re: Endgame fortress handling

Post by cdani »

hgm wrote:I don't think having to search 10 moves (20 ply!) to recognize these positions as a draw is the right approach. Because they are all very easily recognizable as fortresses, they could already be recognized as draws at 0 ply. It is just a matter of having some knowledge in the eval, and wrapping it such that it won't take measurable time to apply it.
Yes, it's the approach I have in Andscacs and one that can be observed in many other engines. It's more concrete and sure.

Anyway I'm trying Lyudmil idea, but it's more difficult than one can think at the start, because the engine uses all the tricks to maintain the advantage to less than 300 cp :-)
Robert Flesher
Posts: 1292
Joined: Tue Aug 18, 2009 3:06 am

Re: Endgame fortress handling

Post by Robert Flesher »

Lyudmil Tsvetkov wrote:I take the liberty to open a new thread and repost 2 of my messages in the next thread, as the topic concerns solving endgame fortresses, and this is a very old and nasty problem with engines of all strength.

[d]8/8/4k3/4P3/2bP4/2P1K3/3B4/8 w - - 0 1

well, this is a draw. Presumably, no engine uses 7-men tbs, so, as a general eval rule does not help here, the only way to make your engine not look stupid is, if you see that, white having score advantage more than 3 full pawns, and the score does not rise by more than half a pawn in the next 10 moves, this is simply a draw.

No pawn sacrifices that could not be seen in the search.

In this case, after 10 played moves, your engine will show 0.0 score, no elo gain, but how nice to watch by a human?
Inasted, the other option is to shuffle another 50 moves with huge artificial winning scores.

[d]6k1/5p2/4r2p/8/3Q4/8/6P1/6K1 w - - 0 1

Typical endgame fortress.

Eval changes might solve similar fortresses, but you have to specify a lot.

Instead, simply declaring draw, when you see score is above 3 full pawns in late endgame and has not changed up by more than half a pawn in the last 10 moves, should be the right solution.

How nice to see an engine showing 0.0 here after 10 played moves!

Otherwise, without 7-men tbs, we are to witness 50 moves shuffling here and there, with scores trying to convince us white is winning.

Actually, I do not see an exception to this rule in late endgame, does anyone?

OK, this does not gain you elo, as it does not cut the tree, does not pick optimal moves, and might even lose half an elo or so, as an additional rule is specified, but play will certainly look much more appealing and human-like.

Actually, I am not certain specifying such a rule will lose more than 0.25elo.

[d][d]8/1b6/8/8/7p/3k2pP/6P1/5K2 w - - 0 1

Seemingly, the rule also applies in Vincent's position above: black leads by more than 3 full pawns in terms of score, the next 10 moves the score does not improve by more than half a pawn, therefore the game is a draw.

This is possible of course, as in the late endgame, where most fortress positions occur, there are simply no available subtle pawn breaks that the search could not easily see, in sharp distinction to rich mg positions, where such breaks mihgt be easily missed by engines.

So I really think the above rule is good to apply in engines, even if it loses 0.5 elo in the process.

Actually, does not that kind of solve most endgame fortress positions, a crux for computer chess for a very long time?

If you are close to such an endgame position in the tree, and history data after a search suggests that from ply 10 until ply 30 the score for this position in the tree does not increase by more than half a pawn, while your eval tells you you are leading by more than 3 full pawns, you might use this information to take pruning decisions; you know this is just a draw, and maybe there are other lines with smaller than 3 full pawns scores that should be preferred instead.

If this is the case, a similar patch with such a rule could even gain you some elo.

What do you think, Daniel?

Even if Daniel disagrees, I am sure Carl will support me on this. :)

So, in short, the suggestion to try solving most endgame fortress positions runs as follows:

you declare the game as a draw, whenever the following conditions are met:

- non-pawn material is less than 1/4 total non-pawn material
- you are leading by more than 300cps in score
- in the last 10 moves/20 plies the score has not improved by more than half a pawn

If you are close to such a fortress position in the tree, leading by more than 300cps, and from ply 5 until ply 25 the score has not increased by more than 50cps, you might even use this rule to take pruning decisions, abandoning this sterile drawish line, and instead preferring a line with a smaller eval score, but more probable to win.

So, after all, after appropriate tuning, this might even gain you elo.

What do you think of the above suggestions?


How about this one I post in 2009. Are the engines still clueless without tablebases?

[d]8/8/3r1kp1/1Q3p2/8/1K6/8/8 w - - 0 68
Robert Flesher
Posts: 1292
Joined: Tue Aug 18, 2009 3:06 am

Re: Endgame fortress handling

Post by Robert Flesher »

Or this I posted in 2010. :wink:


[d]8/8/6k1/5p2/5P2/5N1r/5K2/8 b - - 0 2
Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 12:41 pm

Re: Endgame fortress handling

Post by Lyudmil Tsvetkov »

cdani wrote:
Lyudmil Tsvetkov wrote:What do you think, Daniel?
That I will try :-)
Thanks.
Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 12:41 pm

Re: Endgame fortress handling

Post by Lyudmil Tsvetkov »

hgm wrote:I don't think having to search 10 moves (20 ply!) to recognize these positions as a draw is the right approach. Because they are all very easily recognizable as fortresses, they could already be recognized as draws at 0 ply. It is just a matter of having some knowledge in the eval, and wrapping it such that it won't take measurable time to apply it.

The positions you show have cheap and easy triggers:
*) unlike Bishops
*) connected passers vs Bishop
*) almost all value in a single piece
*) King trapped
*) interlocked Pawn chains of >6 Pawns

These are things that almost any evaluation looks at anyway (e.g. when evaluating King safety, Pawn structure or material balance). They could be used to trigger a slightle more elaborate analysis of the positions. Like if Queen and non-passer are your only possession, can you ever hope to gobble up an unprotected piece? (As even a 2-for-1 trade means the end of your ambitions.) Well, if every opponent piece is already protected (also something that can be easily checked), the chances for that seem slim. And your King is cutoff from his. (Slightly more difficult to figure out, but the chances that you would pass the lone-Queen + all-protected test are already so slim that you would virtually never have to do it.)

If engines do not see this, it just means they are stupid. As mentioned before, a high Elo is no cure against stupidity. There just aren't any cheap search tricks that can substitute for true knowledge. (Not even expensive ones!)
As said, there are simply so many different types of eg fortress positions, not to mention mg ones, that, in order to be consistent, and deal with all of them, or at least half, you will have to add 50 000 lines of eval code into your engine!

IMHO, impossible.
Therefore I think search should really try to see it somehow.

If the eval approach had been so easy, many engines would have implemented that by now, but we see that almost none recognizes similar patterns, for example in TCEC SF does not have a clue about Q vs R eg fortress.
Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 12:41 pm

Re: Endgame fortress handling

Post by Lyudmil Tsvetkov »

Robert Flesher wrote:Or this I posted in 2010. :wink:


[d]8/8/6k1/5p2/5P2/5N1r/5K2/8 b - - 0 2
Right, there are simply too many eg fortress positions of quite different types that could never be exhausted sufficiently and fully specified, and that is why I do not believe an eval aprroach will work.

- there are just pawn fortresses
- rook vs minor piece fortresses
- queen vs rook fortresses
- queen vs 2 minors fortresses
- queen vs rook + minor fortresses
- minor piece vs pawn fortresses
- fortresses based on stalemate
- many other types of fortresses

And, the worst thing is that for all of the abovementioned types of eg fortresses you should further specify quite a lot, as there are fortresses in the center, fortresses in the edge of the board, fortresses with many pawns and fortresses with few pawns, fortresses in blocked positions and fortresses in open positions...

Anf if you would like to further specify when the available pawns are...

... that simply makes some 50 000 lines of additional code. Wish you every success in following the eval approach. :)
Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 12:41 pm

Re: Endgame fortress handling

Post by Lyudmil Tsvetkov »

[d]6k1/8/7p/7P/8/3B3P/7P/6K1 w - - 0 1

Btw., this rule apparently sees also wrong bishop positions, based on stalemate.
Above, you can not make any substantial score progress in the next 10 moves.

Of course, many engines have eval rules for wrong bishop fortresses, but certainly even that simple rule could not quite be exhausted in this way.
Following the eval approach, you will miss at least half of all available wrong bishop fortresses, although wrong bishop positions are probably one of the simplest fortress positions.

[d]8/B7/8/7p/6p1/3k2P1/5PK1/1r6 w - - 0 1
one other rook vs minor piece eg fortress, just to underline that you really can not exhaust in eval all eg fortress positions
User avatar
cdani
Posts: 2204
Joined: Sat Jan 18, 2014 10:24 am
Location: Andorra

Re: Endgame fortress handling

Post by cdani »

Lyudmil Tsvetkov wrote: Right, there are simply too many eg fortress positions of quite different types that could never be exhausted sufficiently and fully specified, and that is why I do not believe an eval aprroach will work.
Of course you are right. Anyway the specific eval approach is better than nothing for at least the most often seen positions.

Who will be able to discover the way to understand that the engine is doing nothing?
Lyudmil Tsvetkov
Posts: 6052
Joined: Tue Jun 12, 2012 12:41 pm

Re: Endgame fortress handling

Post by Lyudmil Tsvetkov »

cdani wrote:
Lyudmil Tsvetkov wrote: Right, there are simply too many eg fortress positions of quite different types that could never be exhausted sufficiently and fully specified, and that is why I do not believe an eval aprroach will work.
Of course you are right. Anyway the specific eval approach is better than nothing for at least the most often seen positions.

Who will be able to discover the way to understand that the engine is doing nothing?
Basically, a score of the magnitude of 3 full pawns in late endgame when that score does not tend to change for quite a while should more or less convince you the engine is doing nothing.

But I understand of course, that implementation of any specific idea is very very difficult...

If you checked any of the positions I posted with Andscacs, does its score change a lot in the foreseeable future?

In a normal position with full 3 pawns advantage, real advantage I mean, I bet the score will increase with at least 60-70cps in 20-plies time, even more. And this happens every single time in a normal positions with sufficiently big advantage.

The bigger the score, the faster it tends to increase, I think this is obvious.

For example, you check the 2 below positions:

[d]6k1/5p2/6rp/8/8/2Q5/6P1/6K1 w - - 0 1
White has 400cps score advantage. Does Andscacs score increase noticeably, by more than 50cps, in the next 20 plies?

If no, you can safely conclude the engine is doing nothing and the positions is a draw.

[d]6k1/2p3r1/1p6/8/8/3Q4/6P1/6K1 w - - 0 1
another position with 400cps white advantage; this time there is no fortress, so this is a normal position

Does Andscacs score rise by more than 50cps in the next 20 plies?

I bet so. If this is so, then you might safely conclude this is a normal winning position, which does not fall under the category of fortress positions.

Maybe Daniel or someone else might provide us with engine output on the above 2 positions with depth 20 or 30, so we are able to draw our conclusions.
User avatar
hgm
Posts: 28543
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Endgame fortress handling

Post by hgm »

Lyudmil Tsvetkov wrote:As said, there are simply so many different types of eg fortress positions, not to mention mg ones, that, in order to be consistent, and deal with all of them, or at least half, you will have to add 50 000 lines of eval code into your engine!
You probably mean: "impossible for people that want to take an existing source of a 3000+ engine, change at most 100 lines, and then claim they have developed a fully original new top engine, just because it has a couple of extra Elo"...

What is wrong with adding 50000 lines of code? If you add 100 lines a day, it would take you less than two years. Where does this idea come from that engine development should not involve any hard programming effort? WinBoard/XBoard has more than 50000 lines of code...