Improving evaluation of passed pawns

[Gerd Isenberg]

I don't think so. Human knows that he has a winning position because he can instantly calculate this line: 1. b6 cxb6 2. cxb6 axb6. 3. axb6 (a6). It is not enough just to look at position, especially if black king is on e6 rather then on f5. Point is that human knows when a position is not stable, so why not put programming effort in that direction. Static evaluation of your engine looks good enough.

Many evaluation terms which would essentially resemble the search part are already statically calculated in many engines, for instance unstoppable pawns, "mate at a glance", etc.

Ending with passers and candidates are extremely unstable. What if white pawn is on c6 instead on c5? You never know if pawn will reach last row with check or not. Sometimes king is in pawn square but can not catch the pawn because of obstacles, etc. As far as I know Stockfish does not use unstoppable pawn evaluation anymore (for good reason).
I think you should be careful with a big penalties.

Yes, search instability due to knowledge holes is an important issue. Even if you have the correct knowledge for instance a "winning score" about the sacrifical pawn breakthrought pattern with an advanced trio on the fifth rank versus an opponent trio on the seventh rank, you need to evaluate all intermediate positions until a passer is established with winning score as well, even if up to two pawns down temporary. For instance if one evaluates (1) "correctly", but fails to evaluate (2) correctly both with white to move ...

[d] 8/ppp5/8/PPP5/8/8/8/8 w - -
[d] 8/p7/pp6/2P5/8/8/8/8 w - -

Huge scores always have the risk that there are some exceptions and errors, f.i. with unstoppable pawns considering multiple threads alá Réti Study. But here, in Ben-Hur Carlos' position, the advanced open candidate even with up to two opponent guards but same number of helpers, may already be treated as passer, and since the opponent king is outside the candidates square b5-e5-e8, its evaluation score should be already "winning" or at least close to this position:

[d] 8/8/6pp/1P3k2/8/4PK2/8/8 w - -

Gerd

[bhlangonijr]

I don't think so. Human knows that he has a winning position because he can instantly calculate this line: 1. b6 cxb6 2. cxb6 axb6. 3. axb6 (a6). It is not enough just to look at position, especially if black king is on e6 rather then on f5. Point is that human knows when a position is not stable, so why not put programming effort in that direction. Static evaluation of your engine looks good enough.

Many evaluation terms which would essentially resemble the search part are already statically calculated in many engines, for instance unstoppable pawns, "mate at a glance", etc.

As far as I know Stockfish does not use unstoppable pawn evaluation anymore (for good reason).
I think you should be careful with a big penalties.

You are right. The code is there but unreferenced in the eval function.

I only evaluate unstoppable pawns in pawns endings. In that case is pretty safe:

Code: Select all

   if (isPawnFinal) {
		const Rank rank = color==WHITE?RANK_8:RANK_1;
		const Square target = board.makeSquare(rank,squareFile[from]);
		const int delta1 = squareDistance(from,target);
		const int delta2 = squareDistance(otherKingSq,target);
		const int otherMove=board.getSideToMove();
		if &#40;std&#58;&#58;min&#40;5,delta1&#41;<delta2-otherMove&#41; &#123;
			eval += UNSTOPPABLE_PAWN_BONUS;			
		&#125;
	&#125;

[bhlangonijr]

But here, in Ben-Hur Carlos' position, the advanced open candidate even with up to two opponent guards but same number of helpers, may already be treated as passer, and since the opponent king is outside the candidates square b5-e5-e8, its evaluation score should be already "winning" or at least close to this position:

[d] 8/8/6pp/1P3k2/8/4PK2/8/8 w - -

Gerd

Thanks Gerd. I am no good expressing myself.
That was exactly what I was trying to say with my original post. You should translate my original position into the one you posted in terms of evaluation of the candidate passer. In that case it is more valuable than the opponent's connected passers.

[jacobbl]

I was wondering if there are any good testsuits for pawn endings? I'm thinking if you have a set of positions and a score saying if it is a win, draw or lose, it would be interesting to check it against the evaluation function. Hoping one would find high scores for the winning positions and low scores for the losing positions.

[Dann Corbit]

I was wondering if there are any good testsuits for pawn endings? I'm thinking if you have a set of positions and a score saying if it is a win, draw or lose, it would be interesting to check it against the evaluation function. Hoping one would find high scores for the winning positions and low scores for the losing positions.

This is a surprisingly difficult problem. Most pawn dominated positions that I have are either locked pawn (therefore deep search) positions or endgame positions easily resolved by endgame table base.

[Don]

Komodo gives this -19.

It's really tricky evaluating king and pawn endings. In fact I don't think humans even do it that well without some analysis, even if it's not a structured search. We have the ability to understand sections of the board and then reason about it. For example the big theme here is that white can create an outside passed pawn. But knowing that this is more important than the passers black has is challenging, because black has them now and white doesn't. Of course this is the very reason our program have search.

It's way more important to try to create a balanced evaluation function that will be a good estimator of the chances given what is actually on the board. On the queen side white does have a pawn majority, and your program should be giving a nice bonus for that, above and beyond the fact that there is a pawn. It's especially important to recognize crippled majorities so that you don't mis-evaluate. I think it's correct that a program should view black as being better unless it really does understand clearly what is going on without search.

A very important term in Komodo is a king distance to the square in front of any passed pawn which in this position would prevent it from thinking black had a really big advantage. Where the distance can be 0 to 7 we are using (sqrt( distance + 1) - 1) * weight. and the weight is some penalty for how far away you are. The weight is zero in the middle game. We are using different values for the weight depending on whether this is a friendly pawn or enemy pawn where we consider it more important for a king to get in front of the other sides pawn.

Is there any engine that evaluates correctly the position bellow?

[D] 8/p1p5/6pp/PPP2k2/8/4PK2/8/8 w - - 0 43

Stockfish gives me the static score -24

My engine' s static evaluation is -61

In my case the wrong evaluation is due to the bigger bonuses for the connected passers, but a human can instantly see it is a winning position for white.

This specific position is an easy win which the static eval can be fixed to work correctly, as we have only pawns left in the board and because the opponent king is far from the promotion line of the candidate passed pawn. Although if there is left some minor piece from the opposite side things become more difficult to evaluate it statically.

The next given position my engine reasonably evaluates as 11:

[D] 8/p1p2p2/6pp/PPP2k2/8/4PKP1/8/8 w - - 0 43

Stockfish gives the same score for this one: -24.

I wonder if there is a better for evaluating statically such positions. I think it might not increase significantly the size of the code and may be worth a few Elo points.

One quick & dirty way of fixing that would be giving bigger bonuses for candidate passers when there is only pawns left in the board and the opposite king is away from the promotion line.

Bellow, another position which is evaluated incorrectly:

[D] 8/p1p2p2/6p1/PPP2k1p/K2P4/4P3/8/8 w - - 0 43

Stockfish static score: -80
In my case my engine evaluates this position as -1400 because of the many unstoppable pawns in the black side. ( It is such a huge bonus... )

Any thoughts?

Regards,

[bob]

Is there any engine that evaluates correctly the position bellow?

[D] 8/p1p5/6pp/PPP2k2/8/4PK2/8/8 w - - 0 43

Stockfish gives me the static score -24

My engine' s static evaluation is -61

Crafty says -0.06, but a simple 3 ply search sees the eval skyrocket for white as it should. I don't like letting the eval try to handle this. This is a "dynamic" issue that is best left to the search, because there are so many special cases to deal with.

In my case the wrong evaluation is due to the bigger bonuses for the connected passers, but a human can instantly see it is a winning position for white.

This specific position is an easy win which the static eval can be fixed to work correctly, as we have only pawns left in the board and because the opponent king is far from the promotion line of the candidate passed pawn. Although if there is left some minor piece from the opposite side things become more difficult to evaluate it statically. BTW the 3 ply score is +6.something in 0.00 seconds. By the time we get to depth 13 at 0.05 seconds, eval is roughly +11.0

The next given position my engine reasonably evaluates as 11:

[D] 8/p1p2p2/6pp/PPP2k2/8/4PKP1/8/8 w - - 0 43

Stockfish gives the same score for this one: -24.

Crafty says +.28 statically. a .02 second search says +10.0...

I wonder if there is a better for evaluating statically such positions. I think it might not increase significantly the size of the code and may be worth a few Elo points.

One quick & dirty way of fixing that would be giving bigger bonuses for candidate passers when there is only pawns left in the board and the opposite king is away from the promotion line.

This is dangerous. The opponent might have a pawn that can't "run" by the square of the pawn rule, but the king can be positions such that the pawn can't be stopped, and it promotes before the "unstoppable passer" and wins. This gets to be _very_ problematic if the eval spits out grossly wrong answers. And trying to determine all the special cases is a pain. I don't have the position handy, but there is a position where it appears black can't possibly win because its king is too far from white's passed pawn. Black has two choices. It can move its king up to help it's own passed pawn promote, but then white defends with a king move. Or it can move it's king toward the enemy passer but it can't stop it. The winning plan is to do both at the same time. Move the king toward both it's own passer and the opponent's passer, so that white can't take the time to push its passer or black will also promote, and white's passer can't win because the black king is closer to supporting its own pawn and will draw. It is a classic that will blow your mind if you have not seen it before. And doing that statically would be one complicated piece of code. yet a search can solve it in milliseconds, as it should...

Bellow, another position which is evaluated incorrectly:

[D] 8/p1p2p2/6p1/PPP2k1p/K2P4/4P3/8/8 w - - 0 43

Stockfish static score: -80
In my case my engine evaluates this position as -1400 because of the many unstoppable pawns in the black side. ( It is such a huge bonus... )

Any thoughts?

Regards,

One can always "compute" where the candidate turns into a passer, and use that for the square of the pawn calculation. But it is complex and dangerous. Crafty says -6.0 statically but +8 after less than 0.05 seconds.

I suppose it is all about whether you want your static eval to handle dynamic considerations..

[Gerd Isenberg]

Is there any engine that evaluates correctly the position bellow?

[D] 8/p1p5/6pp/PPP2k2/8/4PK2/8/8 w - - 0 43

Stockfish gives me the static score -24

My engine' s static evaluation is -61

Crafty says -0.06, but a simple 3 ply search sees the eval skyrocket for white as it should. I don't like letting the eval try to handle this. This is a "dynamic" issue that is best left to the search, because there are so many special cases to deal with.

In my case the wrong evaluation is due to the bigger bonuses for the connected passers, but a human can instantly see it is a winning position for white.

This specific position is an easy win which the static eval can be fixed to work correctly, as we have only pawns left in the board and because the opponent king is far from the promotion line of the candidate passed pawn. Although if there is left some minor piece from the opposite side things become more difficult to evaluate it statically. BTW the 3 ply score is +6.something in 0.00 seconds. By the time we get to depth 13 at 0.05 seconds, eval is roughly +11.0

The next given position my engine reasonably evaluates as 11:

[D] 8/p1p2p2/6pp/PPP2k2/8/4PKP1/8/8 w - - 0 43

Stockfish gives the same score for this one: -24.

Crafty says +.28 statically. a .02 second search says +10.0...

What does Crafty eval say without a-pawns and/or c-pawns?

I wonder if there is a better for evaluating statically such positions. I think it might not increase significantly the size of the code and may be worth a few Elo points.

One quick & dirty way of fixing that would be giving bigger bonuses for candidate passers when there is only pawns left in the board and the opposite king is away from the promotion line.

This is dangerous. The opponent might have a pawn that can't "run" by the square of the pawn rule, but the king can be positions such that the pawn can't be stopped, and it promotes before the "unstoppable passer" and wins. This gets to be _very_ problematic if the eval spits out grossly wrong answers. And trying to determine all the special cases is a pain. I don't have the position handy, but there is a position where it appears black can't possibly win because its king is too far from white's passed pawn. Black has two choices. It can move its king up to help it's own passed pawn promote, but then white defends with a king move. Or it can move it's king toward the enemy passer but it can't stop it. The winning plan is to do both at the same time. Move the king toward both it's own passer and the opponent's passer, so that white can't take the time to push its passer or black will also promote, and white's passer can't win because the black king is closer to supporting its own pawn and will draw. It is a classic that will blow your mind if you have not seen it before. And doing that statically would be one complicated piece of code. yet a search can solve it in milliseconds, as it should...

Bellow, another position which is evaluated incorrectly:

[D] 8/p1p2p2/6p1/PPP2k1p/K2P4/4P3/8/8 w - - 0 43

Stockfish static score: -80
In my case my engine evaluates this position as -1400 because of the many unstoppable pawns in the black side. ( It is such a huge bonus... )

Any thoughts?

Regards,

One can always "compute" where the candidate turns into a passer, and use that for the square of the pawn calculation. But it is complex and dangerous. Crafty says -6.0 statically but +8 after less than 0.05 seconds.

I suppose it is all about whether you want your static eval to handle dynamic considerations..

The point here in a pawn ending, the advanced candidate with an open frontspan on the fifth rank has the same number of helpers than sentries, which makes the candidate almost as valuable as it would already be a passer. The sentries are forced to exchange versus the helpers, white does not lose any tempo. Additionally, the candidate's frontspan is not blocked by own king and has the opponent king outside the candidate's square.

Guess you refer the Réti Endgame Study, yes there many cases where static knowledge might fail due to multiple threats and all kind of interactions and counter threats. But again, here with the mentioned conditions it is safe to treat the b5-candidate already only slightly worse than a passer, as each pair of sentry/helper can be canceled out here.

[bhlangonijr]

One can always "compute" where the candidate turns into a passer, and use that for the square of the pawn calculation. But it is complex and dangerous. Crafty says -6.0 statically but +8 after less than 0.05 seconds.

I suppose it is all about whether you want your static eval to handle dynamic considerations..

I suppose almost every engine can solve all these positions instantly, through search, when it is close to the root. The problem here is when these positions appear close to the leaves, where all the pruning mechanism takes place. The mis-evaluation of such positions close to the leaves may postpone the correct ordering of the root move which will eventually cause it, as all reductions/pruning schemes heavily rely on the static evaluation. The point is whether we can evaluate better such positions. I am not saying we have to completely solve it statically, but rather give a better "hint" to the search.
One may argue that such situations would be statistically insignificant, but i would like to get as much correct "answers" in my evaluation function as possible.

[zamar]

As far as I know Stockfish does not use unstoppable pawn evaluation anymore (for good reason).
I think you should be careful with a big penalties.

Slight correction: Passed evaluation in old Stockfish version was buggy so it was removed. For 2.0 new very complex passed pawn evaluation was written by me. It's very careful not give wrong bonuses.