Funny fortress position

[zullil]

In Stockfish's self-play there occured a funny fortress position:

[d]4kb2/2p3r1/1pP1P2Q/pP2K3/P7/8/8/8 w - - 0 93

Stockfish shows this as +4 for white. How about your favourite engine?

Black Diamond XI has Joe Ellis' fortress detection code built in.

Code: Select all

dep	score	time	(not shown:  nodes	tbhits	knps	seldep	)
 26	  0.00 	0:17.90	Kd8 e7+ Kxe7 Qh3 Kd8 Qf5 Bc5 Ke5 Bd6+ Kf6 Re7 Kg6 Be5 Qf8+ Re8 Qf7 Re7
 25	  0.00 	0:06.35	Kd8 e7+ Kxe7 Qh3 Kd8 Qf5 Bc5 Ke5 Bd6+ Kf6 Re7 Kg6 Be5 Qf8+ Re8 Qf7 Re7
 24	  0.00 	0:03.64	Kd8 e7+ Kxe7 Qh3 Kd8 Qf5 Bc5 Ke5 Bd6+ Kf6 Re7 Kg6 Bb4 Qf8+ Re8 Qf7 Re7
 23	  0.00 	0:01.37	Kd8 e7+ Kxe7 Qh3 Kd8 Qf5 Bc5 Ke5 Bd6+ Kf6 Re7 Kg6 Bb4 Qf8+ Re8 Qf7 Re7
 22	  0.00 	0:01.00	Kd8 e7+ Kxe7 Qh3 Kd8 Qf5 Bc5 Ke5 Bd6+ Kf6 Re7 Kg6 Be5 Qf8+ Re8 Qf7 Re7
 21	  0.00 	0:00.70	Kd8 e7+ Kxe7 Qh3 Kd8 Qf5 Bc5 Ke5 Bd6+ Kf6 Re7 Kg6 Be5 Qf8+ Re8 Qf7 Re7
 20	  0.00 	0:00.53	Kd8 e7+ Kxe7 Qh3 Kd8 Qf5 Bc5 Ke5 Bd6+ Kf6 Bf8 Qd3+ Ke8 Qd5 Re7 Qa2 Kd8 Kg6 Rg7+ Kf6
 19	  0.00 	0:00.48	Kd8 e7+ Kxe7 Qh4+ Ke8 Qh5+ Kd8 Qh3 Re7 Qh8 Ke8 Qh5+ Kd8
 18	  0.00 	0:00.30	Re7 Qh5+ Kd8 Qf5 Ke8
 17	  0.00 	0:00.27	Re7 Qh5+ Kd8 Qf5 Ke8
 16	  0.00 	0:00.25	Re7 Qh5+ Kd8 Qf5 Ke8
 15	  0.00 	0:00.20	Re7 Qh5+ Kd8 Qh8 Ke8
 14	 -0.80 	0:00.10	Kd8 Qf6+ Ke8 Qh4 Re7 Qh5+ Kd8 Qh8 Ke8 Kc4 Rg7 e7 Rxe7 Kd5 Rg7 Qh5+ Kd8 Qf5 Bd6 Qf6+ Re7 Kc4 Ke8 Qh8+ Kf7 Qh5+ Kg7 Qf5 Re5 Qb1
 13	 -1.05 	0:00.08	Kd8 Qf6+ Ke8 Qh4 Re7 Qh8 Rg7 Qh5+ Ke7 Qh4+ Ke8 Kd4 Re7 Qh8 Rg7 Qh5+ Kd8 Qd5+ Ke8 e7 Rxe7 Qh5+ Kd8 Qh8 Ke8 Kd5 Rg7 Qh5+ Kd8 Qf5 Bd6 Qf6+ Re7 Kc4 Ke8 Qh8+ Kf7
 12	 -0.69 	0:00.06	Re7 Qh5+ Kd8 Qh8 Ke8 Kc4 Rg7 e7 Kxe7 Qh5 Kd8 Qf5 Bd6 Qf6+ Re7 Kd3 Be5 Qf8+ Re8 Qf7 Re7 Qg8+ Re8 Qg5+ Re7 Kc4 Bg7 Qd5+ Ke8 Qh5+ Rf7
 11	 -0.97 	0:00.03	Re7 Qh5+ Kd8 Qh8 Ke8 Kc4 Rg7 e7 Rxe7 Kd4 Rg7 Qh5+ Kd8 Kd3 Re7 Kd2 Bg7 Qd5+ Ke8 Qg8+ Bf8 Qg4 Kd8 Qd1
 10	 -1.52 	0:00.03	Re7 Qh8 Rg7 Qh5+ Ke7 Qh2 Ke8 e7 Rxe7 Qh8 Rg7 Qh5+ Kd8 Qf5 Bc5 Qf6+ Re7
  9	 -3.15 	0:00.01	Rg8 Qh5+ Kd8 Qf7 Rg5+ Ke4 Be7 Qh7 Ke8 Qh8+ Bf8 Kf4 Rg7 Kf5 Rg1 Qe5
  8	 -3.20 	0:00.01	Rg1 Qf4 Rg7 Qf6 Re7 Ke4 Bg7 Qg6+ Kd8 Kf4 Bb2 Qb1
  7	 -3.37 	0:00.01	Rg8 Qf6 Rg7 Qe5 Kd8 Qh5 Re7 Ke5 Re8 Kf6 Be7+ Kg7
  6	 -3.75 	0:00.01	Rg1 Qf4 Rg7 Qf6 Re7 Qg6+ Kd8
  5	 -3.79 	0:00.01	Re7 Qg6+ Kd8 Ke5 Bg7+ Kf5 Bd4
  4	 -3.12 	0:00.01	Rg1 Qf4 Rd1+ Kc4 Bc5 Qf7+ Kd8
  3	 -3.45 	0:00.00	Rg1 Qh4 Rd1+ Ke4
  2	 -3.03 	0:00.00	Rg1 Qh5+ Kd8 Qf3
  1	 -3.17 	0:00.00	Rg1 Qh5+ Ke7
  0	#

Available here
https://github.com/MichaelB7/Stockfish/releases/tag/XI

But that's search-based-detection, right? Not much help when the position occurs at the leaf of a middlegame search.

Is Black Diamond's static eval the same as Stockfish's? i.e. about +5?

[jhellis3]

Well, when someone creates a perfect eval, I'll be happy to implement that and do away with search entirely. I mean hey, it is just 32m TBs... easy right?

[zullil]

Well, when someone creates a perfect eval, I'll be happy to implement that and do away with search entirely. I mean hey, it is just 32m TBs... easy right?

Just asking for better static evals of near-tablebase positions . Yes, this is very hard, and not particularly interesting. This is currently the greatest source of weakness of engines (IMHO), since such positions are now being routinely reached as leaf nodes of searches of early middlegame positions.

[Uri Blass]

Well, when someone creates a perfect eval, I'll be happy to implement that and do away with search entirely. I mean hey, it is just 32m TBs... easy right?

Just asking for better static evals of near-tablebase positions . Yes, this is very hard, and not particularly interesting. This is currently the greatest source of weakness of engines (IMHO), since such positions are now being routinely reached as leaf nodes of searches of early middlegame positions.

If you allow expensive evaluation then it is easy to produce a better static evaluation.

What about the following evaluation to detect fortess positions?
Let stockfish to play against itself at depth d for some fixed d.
The position should get close to a draw evaluation if the result of the game is a draw.

[Ovyron]

What about the following evaluation to detect fortess positions?
Let stockfish to play against itself at depth d for some fixed d.
The position should get close to a draw evaluation if the result of the game is a draw.

Doesn't work in practice, you can get 100% draws just because the engine fails to find the only move that wins in some deep position which mates it possible to break the fortress every time, and make it lose.

[Uri Blass]

What about the following evaluation to detect fortess positions?
Let stockfish to play against itself at depth d for some fixed d.
The position should get close to a draw evaluation if the result of the game is a draw.

Doesn't work in practice, you can get 100% draws just because the engine fails to find the only move that wins in some deep position which mates it possible to break the fortress every time, and make it lose.

This is only evaluation.

If you search deep enough in that type of positions you search also the move that break the fortress and in that case the result of the game is not going to be a draw.

Of course searching deep enough with an expensive evaluation can take a lot of time that you practically do not have but
I still think that the expensive evaluation can be productive as a second opinion about the position.

If engines give evaluation of +4 pawns I would like to verify that the expensive evaluation does not detect some fortress to have more confidence that the +4 pawns really means winning the game.

[Ovyron]

I still think that the expensive evaluation can be productive as a second opinion about the position.

Probably extra cores could be used for this. Say on a 4CPU, you have 3 cores searching normally as to not slowdown the search, and the last core is checking for fortresses to see if the eval of the other three is real with expensive eval.

[jhellis3]

Just asking for better static evals of near-tablebase positions .

Bruh, that is 12m.... we don't even have 8m. Meanwhile, the method I implemented handles arbitrary piece count.... Bonus: If you happen to read the code, you will see it accomplishes the results it does by altering the static eval .

What about the following evaluation to detect fortess positions?
Let stockfish to play against itself at depth d for some fixed d.
The position should get close to a draw evaluation if the result of the game is a draw.

That is essentially what the pathological search extension does already, in trivial game cycles it extends until it hits a cutoff.

[zullil]

Just asking for better static evals of near-tablebase positions .

Bruh, that is 12m.... we don't even have 8m. Meanwhile, the method I implemented handles arbitrary piece count.... Bonus: If you happen to read the code, you will see it accomplishes the results it does by altering the static eval .

I have no doubt that your method is effective and robust. But at leaves there's no option left for searching. And if the static eval gives +5 rather than something like 0, the engine is not gonna find it's way to that fortress draw.

[jhellis3]

But at leaves there's no option left for searching.

Bruh... again. Sure there is... you extend the search. Crystal doesn't have trivial game cycle leaves which are not hard cutoffs .

Of course you can't do this for every trivial cycle node due to practical time considerations (so it is limited in non-pv instances to shallow depths), but I guarantee that, if you did such a search, it would complete infinitely quicker than generating, storing, and referencing proper evals for every position.

At any rate, in Crystal, any such nodes on the PV are recursively extended until resolution. It may not be perfect, but I am unaware of any other solution which performs better. If one is known and available, I am happy to implement that.

And if the static eval gives +5 rather than something like 0, the engine is not gonna find it's way to that fortress draw.

Which (again) is why the code alters the static eval .