Improving evaluation of passed pawns

[bhlangonijr]

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,

[Karlo Bala]

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.

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.

[Ferdy]

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

I agree with that. There are also cases where even if opp king is close to promotion square, I still can promote if own king guards the promotion square.

Before a passer is born there must exist a candidate passer or a potential passer. In ending with only pawns, candidate passers close to promotion should be carefully evaluated. While I already have evaluation of uncatchable passer I ought to have evaluation of uncatchable potential passer also.

OTOH it could be interesting to experiment to extend the search if a potential passer is pushed to the 6th rank.

[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. IMO the positions I've posted contains some elements which can suggest, even without calculation (search), that white is "better": The pawn chain which contains the candidate passer is more advanced, the distance of both kings from the promotion lines, etc. It would be particularly good at high depths as most modern engines pruning are heavily dependent on static evaluation.

[bhlangonijr]

OTOH it could be interesting to experiment to extend the search if a potential passer is pushed to the 6th rank.

If you happen to have a very good static evaluation which handles correctly those situations, maybe the singular extension would do that for you in a more "general" way in many cases. Just a hunch. But I gonna try that as soon as I get my eval fixed.

BTW, I don't follow the current belief that we should neglect the static evaluation and let the search take care of its inaccuracies.

[Karlo Bala]

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.

[Ferdy]

OTOH it could be interesting to experiment to extend the search if a potential passer is pushed to the 6th rank.

If you happen to have a very good static evaluation which handles correctly those situations, maybe the singular extension would do that for you in a more "general" way in many cases. Just a hunch. But I gonna try that as soon as I get my eval fixed.

BTW, I don't follow the current belief that we should neglect the static evaluation and let the search take care of its inaccuracies.

Singular extension is not in my priority list, as I believe if a search happened to see a promising/good position, I guess the search will find a way to improve further its position.

I use full eval for reduction/pruning so I have to build and tune it to suit my reduction schemes, at present my reductions are very limited, no reductions if remaining own piece (not pawns) is below or equal to rook. I thought that I can only overcome this once my eval can handle endings nicely. I guess there a lot to be gained in improving ending evaluation, as qsearch will not stop capturing until it gets a good position. We can help the search to be efficient by showing an evaluation that is close to reality.

[mhalstern]

For the first position, Zappa sees a win instantly and 2.5 minutes later, it announces a mate in 16:

New game
8/p1p5/6pp/PPP2k2/8/4PK2/8/8 w - - 0 1

Analysis by Zappa Mexico II 64:

1.b6 cxb6 2.cxb6 axb6 3.axb6 h5 4.e4+ Kf6 5.b7 Kf7 6.b8Q Kg7 7.Qc7+ Kh6 8.Qe7 h4 9.Qxh4+
+- (12.40) Depth: 13/43 00:00:00 475kN, tb=38
1.b6 cxb6 2.cxb6 axb6 3.axb6 h5 4.e4+ Kf6 5.b7 Kf7 6.b8Q Kg7 7.Qc7+ Kh6 8.Qe7 h4 9.Qxh4+
+- (12.40) Depth: 13/44 00:00:00 549kN, tb=47
1.b6 cxb6 2.cxb6 axb6 3.axb6 h5 4.e4+ Kf6 5.b7 Kg7 6.b8Q g5 7.Qe5+ Kg6 8.Kg3 g4 9.Qf5+ Kh6 10.e5 Kg7
+- (13.21) Depth: 14/47 00:00:01 5324kN, tb=455
1.b6 cxb6 2.cxb6 axb6 3.axb6 h5 4.e4+ Kf6 5.b7 Kg7 6.b8Q g5 7.Qe5+ Kg6 8.Kg3 g4 9.Qf5+ Kh6 10.e5 Kg7
+- (13.21) Depth: 14/47 00:00:01 5444kN, tb=465
1.b6 cxb6 2.cxb6 a6 3.b7 h5 4.b8Q g5 5.e4+ Ke6 6.Qc8+ Ke7 7.Qxa6 h4 8.Qb7+ Kf6 9.a6 Ke5
+- (17.71) Depth: 15/49 00:00:09 28422kN, tb=3265
1.b6 cxb6 2.cxb6 a6 3.b7 h5 4.b8Q g5 5.e4+ Ke6 6.Qc8+ Ke7 7.Qxa6 h4 8.Qb7+ Kf6 9.a6 Ke5
+- (17.71) Depth: 15/49 00:00:09 28549kN, tb=3267
1.b6 cxb6 2.cxb6 a6 3.b7 h5 4.b8Q Ke6 5.Qb6+ Ke5 6.Qxa6 h4 7.Qb5+ Kd6 8.Kg4 Ke7 9.a6 Ke6
+- (18.83) Depth: 16/51 00:00:20 77689kN, tb=3722
1.b6 cxb6 2.cxb6 a6 3.b7 h5 4.b8Q Ke6 5.Qb6+ Ke5 6.Qxa6 h4 7.Qb5+ Kd6 8.Kg4 Ke7 9.a6 Ke6
+- (18.83) Depth: 16/51 00:00:20 78035kN, tb=3787
1.b6 axb6 2.cxb6 Ke6 3.b7 h5 4.b8Q h4 5.Qxc7 g5 6.Qc6+ Ke7 7.Kg4 Kf7 8.a6
+- (19.96) Depth: 17/53 00:00:42 177mN, tb=6098
1.b6 axb6 2.cxb6 Ke6 3.b7 h5 4.b8Q h4 5.Qxc7 g5 6.Qc6+ Ke7 7.Kg4 Kf7 8.a6
+- (19.96) Depth: 17/53 00:00:42 177mN, tb=6198
1.b6 axb6 2.cxb6 cxb6 3.axb6 h5 4.b7 g5 5.e4+ Ke6 6.b8Q g4+ 7.Kg3 Ke7 8.Qe5+ Kf7 9.Qxh5+ Kf6 10.Kh2 Ke6 11.Qxg4+ Ke5
+- (#16) Depth: 18/55 00:02:31 644mN, tb=43610
1.b6 axb6 2.cxb6 cxb6 3.axb6 h5 4.b7 g5 5.e4+ Ke6 6.b8Q g4+ 7.Kg3 Ke7 8.Qe5+ Kf7 9.Qxh5+ Kf6 10.Kh2 Ke6 11.Qxg4+ Ke5
+- (#16) Depth: 18/55 00:02:32 648mN, tb=44073
1.b6 axb6 2.cxb6 cxb6 3.axb6 g5 4.b7 g4+ 5.Kg3 h5 6.b8Q Ke6 7.Qe8+ Kd5 8.Qxh5+
+- (#16) Depth: 19/57 00:03:20 877mN, tb=128986
1.b6 axb6 2.cxb6 cxb6 3.axb6 g5 4.b7 g4+ 5.Kg3 h5 6.b8Q Ke6 7.Qe8+ Kd5 8.Qxh5+
+- (#16) Depth: 19/57 00:03:21 881mN, tb=129583
1.b6 axb6 2.cxb6 cxb6 3.axb6 g5 4.b7 g4+ 5.Kg3 h5 6.b8Q Ke6 7.Qe8+ Kd5 8.Qxh5+
+- (#16) Depth: 20/59 00:03:38 946mN, tb=146704
1.b6 axb6 2.cxb6 cxb6 3.axb6 g5 4.b7 g4+ 5.Kg3 h5 6.b8Q Ke6 7.Qe8+ Kd5 8.Qxh5+
+- (#16) Depth: 20/59 00:03:40 956mN, tb=148488

[bhlangonijr]

For the first position, Zappa sees a win instantly and 2.5 minutes later, it announces a mate in 16:

Interesting. I don't know how Zappa handles this, but Rybka actually does a search with depth 5 in the first iteration so it will also see a win "instantly" (i am not sure as i don't own a rybka copy). For checking what is the real static evaluation of the engine some of them provide a "eval" command for debugging purposes. Stockfish and Critter both have that feature. I just implemented that in Redqueen and also a lot of other things you can play around with the engine, which is the nice thing in open source engines.

[bhlangonijr]

Singular extension is not in my priority list, as I believe if a search happened to see a promising/good position, I guess the search will find a way to improve further its position.

I meant I gonna try what you suggested after fixing the evaluation function. But I already have implemented SE and it was worth something around 20 Elo points for me. It is not a big deal but I will let it there as the code added for that is very simple.

I use full eval for reduction/pruning so I have to build and tune it to suit my reduction schemes, at present my reductions are very limited, no reductions if remaining own piece (not pawns) is below or equal to rook. I thought that I can only overcome this once my eval can handle endings nicely. I guess there a lot to be gained in improving ending evaluation, as qsearch will not stop capturing until it gets a good position. We can help the search to be efficient by showing an evaluation that is close to reality.

Currently my pruning is done using a lazy evaluation. I know it is not nice but I tried in several occasions get rid of the lazy evaluation and always got as result Elo loss.
I never reduce captures (even the bad ones), passed pawns, checks, etc. But I found that not reducing based on evaluation scores of any kind is always worst.