unstoppable passed pawns in stockfish

[Uri Blass]

I wonder if the code to detect unstoppable passed pawns in stockfish in endgames is productive for playing strength.

Did the developers test it?

The reason is that it is clear that there are cases of huge evaluation errors
and as a chess player I prefer a program that know nothing about unstoppable pawns and not a program that can give me huge errors in evaluation(because at least in the first case I can have more confidence that a huge score really means winning)

Of course stockfish see that white wins by search in the following diagrams but if this position is a leaf of the tree it may cause stockfish to get a wrong decision(when without the code it ha chances not to make it)

New game - Stockfish 1.8 JA
[d]6k1/p7/P6p/8/1P6/8/8/K7 b - - 0 1

Analysis by Stockfish 1.8 JA:

1...h6-h5
-+ (-6.14) Depth: 1 00:00:00


New game - Stockfish 1.8 JA
[d]7k/p1K5/P6p/8/1P6/8/8/8 b - - 0 1

Analysis by Stockfish 1.8 JA:

1...h6-h5
-+ (-4.96) Depth: 1 00:00:00

[d]7k/ppp5/8/PPP4p/8/8/5P2/K7 w - - 0 1

Even if the code is productive it may be better to add to the code a condition that a pawn is unstoppable only if there is not an opponent pawn that may promote earlier or at the same time based on the opponent pawn rank.

If this restriction does not work in testing then at least it may be better to reduce the bonus for unstoppable passed pawn in cases that there is an opponent pawn that may promote.

Uri

[zamar]

Unstoppable pawn code is very old and from Glaurung times. It has some major flaws as you pointed out. On my long TODO list

[Ralph Stoesser]

Even if the code is productive it may be better to add to the code a condition that a pawn is unstoppable only if there is not an opponent pawn that may promote earlier or at the same time based on the opponent pawn rank.

How would you code that condition?

[mcostalba]

Even if the code is productive it may be better to add to the code a condition that a pawn is unstoppable only if there is not an opponent pawn that may promote earlier or at the same time based on the opponent pawn rank.

How would you code that condition?

I would think is already coded. In particular the last position is evaluayed wrong due to a bug reported and fixed by Marek some week ago.

Namely the code was not accounting for double pawn push correctly.

[Dann Corbit]

Even if the code is productive it may be better to add to the code a condition that a pawn is unstoppable only if there is not an opponent pawn that may promote earlier or at the same time based on the opponent pawn rank.

How would you code that condition?

I would think is already coded. In particular the last position is evaluayed wrong due to a bug reported and fixed by Marek some week ago.

Namely the code was not accounting for double pawn push correctly.

Is the corrected version available?

Is there a git repository or something of that nature to pull what is always the latest bleeding edge version?

[zamar]

I would think is already coded. In particular the last position is evaluayed wrong due to a bug reported and fixed by Marek some week ago.

Namely the code was not accounting for double pawn push correctly.

This is not a double pawn push issue at all. Look at this position for example:

[d]7k/p7/P7/7p/1P6/8/K7/8 w - - 0 1

Stockfish sees that black has unstoppable passed pawn and he gets a huge bonus. White doesn't get a bonus, but is first to promote!

Even if the code is productive it may be better to add to the code a condition that a pawn is unstoppable only if there is not an opponent pawn that may promote earlier or at the same time based on the opponent pawn rank.

How would you code that condition?

One idea:

Loop through opponent's pawns. Find highest relative rank of pawn which is not blocked by enemy pawn. If this pawn is further advanced than unstoppable pawn, give significantly lower unstoppable pawn bonus.

[Ralph Stoesser]

Even if the code is productive it may be better to add to the code a condition that a pawn is unstoppable only if there is not an opponent pawn that may promote earlier or at the same time based on the opponent pawn rank.

How would you code that condition?

I would think is already coded. In particular the last position is evaluayed wrong due to a bug reported and fixed by Marek some week ago.

Namely the code was not accounting for double pawn push correctly.

In the last position 1.b6 wins for white (pawn breakthrough). Not easy to identify by a non-chess-player.

But I think it's also not easy to identify by a chess engine without doing search...

[bob]

Even if the code is productive it may be better to add to the code a condition that a pawn is unstoppable only if there is not an opponent pawn that may promote earlier or at the same time based on the opponent pawn rank.

How would you code that condition?

I would think is already coded. In particular the last position is evaluayed wrong due to a bug reported and fixed by Marek some week ago.

Namely the code was not accounting for double pawn push correctly.

In the last position 1.b6 wins for white (pawn breakthrough). Not easy to identify by a non-chess-player.

But I think it's also not easy to identify by a chess engine without doing search...

Crafty has always evaluated such pawns by giving them a bonus. In crafty, this is called a "hidden passed pawn" where the a pawn is blocked and actually the b-pawn appears to be backward. But due to the advanced square of the A pawn, it promotes very quickly. I probably should go back over all of this stuff again. The problem is that you can't get it right 95% of the time. Whatever you do has to be 100% correct. If a case is not certain, you just don't evaluate it at all. Otherwise, the big search we see today will run all through those holes and create havoc.

[Uri Blass]

Even if the code is productive it may be better to add to the code a condition that a pawn is unstoppable only if there is not an opponent pawn that may promote earlier or at the same time based on the opponent pawn rank.

How would you code that condition?

One condition for a pawn to be unstoppable(without doubt) is that the pawn is more advanced than all the opponent pawns(and if the difference is one rank you need also to have the side to move to be sure that the opponent does not reply promotion by promotion)

If this condition does not happen you are not sure or almost sure that the pawn is unstoppable so you may give only a bonus of +1 in the evaluation for the significant probability that the pawn is unstoppable and not a bonus of +5 or +6.

Uri

[Uri Blass]

Even if the code is productive it may be better to add to the code a condition that a pawn is unstoppable only if there is not an opponent pawn that may promote earlier or at the same time based on the opponent pawn rank.

How would you code that condition?

I would think is already coded. In particular the last position is evaluayed wrong due to a bug reported and fixed by Marek some week ago.

Namely the code was not accounting for double pawn push correctly.

In the last position 1.b6 wins for white (pawn breakthrough). Not easy to identify by a non-chess-player.

But I think it's also not easy to identify by a chess engine without doing search...

Crafty has always evaluated such pawns by giving them a bonus. In crafty, this is called a "hidden passed pawn" where the a pawn is blocked and actually the b-pawn appears to be backward. But due to the advanced square of the A pawn, it promotes very quickly. I probably should go back over all of this stuff again. The problem is that you can't get it right 95% of the time. Whatever you do has to be 100% correct. If a case is not certain, you just don't evaluate it at all. Otherwise, the big search we see today will run all through those holes and create havoc.

Note that I also think that it is better if programs do not evaluate unstoppable passed pawns if they get it correct 95% of the time but my reason is different.

I do not claim to know that the advantage in games is not bigger than the disadvantage(The only way to know is by testing that I did not do).

I simply want to know that I can trust a big score that I see in pawn endgames(and I feel that I can trust more high scores of programs with no knowledge of unstoppable passed pawns)

I also think that programs without high scores for something that can be wrong can be more aggresive in pruning based on evaluation in the endgame so the improvement in the evaluation can cause a new change in the search to be productive.

Uri