Pawn backwardness

[D Sceviour]

1- As Bob says the open-file stuff is bogus. There is not such a requirement for a pawn to be backward. It simply increases the weakness of the pawn, but only if there are rooks on the board.

I almost agree. It is easier to program the pawn structure if backward is always flagged on a half-open file. Perhaps that might be an error.

2- The base of the pawn chain could be (should be?) easily seen as a backward pawn, therefore in position 1 d2 could also backward

It is surprising for you to say that since your OP indicated you were not satisfied with the definition of backward. There has to be some way of distinguishing between a backward (meaning blocked and unprotected) pawn and a backward (meaning repairable) pawn. Repairable simply means the opposite of blocked.

3- in position 1 b7 is clearly a backward pawn.

b7 is not backward because it can advance safely to b6 or b5.

4- in position 2 e7 is clearly a backward pawn.

It is possible to define it that way but it is not clear. The e7 pawn is in no danger on a closed file so there is nothing to score.

5- in position 3 b2, d7 are clearly backward pawns.

b2 is not backward because it can advance safely to b3.
d7 is not backward because it can advance safely to d6.
The difference could be zugzwang.

[Ferdy]

This is how I define my backward pawn (bwp).
1. The front sq is empty and
2. The front sq is attacked by opp pawn and
3. I don't have pawn defender on that front sq.

By that pos 1 b7 is not bwp, pos 2 e7 and e4 are bwp, pos 3 g6, h3 and h2 are not bwp.

[xmas79]

2- The base of the pawn chain could be (should be?) easily seen as a backward pawn, therefore in position 1 d2 could also backward

It is surprising for you to say that since your OP indicated you were not satisfied with the definition of backward. There has to be some way of distinguishing between a backward (meaning blocked and unprotected) pawn and a backward (meaning repairable) pawn.

I'm not satisfied with this definition and I want to see what other people say about it, so no surprise.

Repairable simply means the opposite of blocked.

So the only difference is that the square in front of the pawn is free/occupied by opponent pawn? And what if there a friendly pawn?

3- in position 1 b7 is clearly a backward pawn.

b7 is not backward because it can advance safely to b6 or b5.

b7 will be backward sooner or later. The "safely advance" is bogus because sooner or later black will not be able to push that pawn anymore. So it is a weakness.

4- in position 2 e7 is clearly a backward pawn.

It is possible to define it that way but it is not clear. The e7 pawn is in no danger on a closed file so there is nothing to score.

Again, the open/close file stuff is irrelevant. You said, that pawn cannot be safely advanced, so it is backward...

5- in position 3 b2, d7 are clearly backward pawns.

b2 is not backward because it can advance safely to b3.
d7 is not backward because it can advance safely to d6.
The difference could be zugzwang.

b2 and d7 are clearly backward, and if you don't score them as such would be a huge error IMO. That kind of pawn structure is often seen in midgames, and unless the engine have some form of compensation for such structure it should avoid it. Do you agree that playing 1.a4 followed by 2.c4 from the start position is a bad idea because b4 square becomes instantly weak?? That also makes instantly b2 backward, do you agree?

The fact that these pawn have one tempo is not a valid justification. Zugzwang is dynamic (rather problematic) property of chess, and has nothing to do with static eval.


IMHO.

[xmas79]

This is how I define my backward pawn (bwp).
1. The front sq is empty and
2. The front sq is attacked by opp pawn and
3. I don't have pawn defender on that front sq.

By that pos 1 b7 is not bwp, pos 2 e7 and e4 are bwp, pos 3 g6, h3 and h2 are not bwp.

+1:

That was one on my attempts. The key idea is simple: if a pawn cannot safely advance then assign a penalty. This will penalize "immediate" backwardness. How to penalize "future" backwardness (eg the b2 pawn once it gets in b3)?

[Ferdy]

How to penalize "future" backwardness (eg the b2 pawn once it gets in b3)?

I don't have penalty for the pawn in b2, but only rely on the pawn sq table being not far advanced. In addition I have other feature to penalize that weak empty b3 sq.

[D Sceviour]

5- in position 3 b2, d7 are clearly backward pawns.

b2 is not backward because it can advance safely to b3.
d7 is not backward because it can advance safely to d6.
The difference could be zugzwang.

b2 and d7 are clearly backward, and if you don't score them as such would be a huge error IMO. That kind of pawn structure is often seen in midgames, and unless the engine have some form of compensation for such structure it should avoid it..

The error would never be huge. I score nothing for backward pawns anyway. Only if backward pawns are attacked does it make a difference. b2 an d7 could be called free pawns.

Do you agree that playing 1.a4 followed by 2.c4 from the start position is a bad idea because b4 square becomes instantly weak?? That also makes instantly b2 backward, do you agree?

No, I do not agree. What you are describing could be a closed pawn formation if black follows with a5 and c5. The presence of a b pawn would make little difference on b2 or b3 unless the b-file was half-open. White would have the same compensation for the hole on b5, and again there is nothing to score.

The fact that these pawns have one tempo is not a valid justification. Zugzwang is dynamic (rather problematic) property of chess, and has nothing to do with static eval.

I disagree, especially with null move searches that can be destroyed very quickly with zugzwang. The static evaluation is very important. In fact, null move search makes me re-think the importance of pawn tempo. Currently, null move search is often not performed unless there are minors/majors on the board. Perhaps pawn tempo from free pawns could also be added to the conditions for null move search. This looks worth further investigation.

[hgm]

Pawn tempos are not a good reason to allow null moves, because the Pawn moves are irreversible. So you run out of them. But if you allow null move just because that side has a single Pawn move, after which he will be axed, he will happily play 10 null moves in a row, and think there is nothing wrong with his position. When the opponent has a slider, this holds the promise for perpetual tempos. Especially since a slider can usual move without having to give up a vital protection function. With just a Knight the danger of zugzwang is already too big to justify null move. Even with a Bishop there are many cases where it is crucial that the Bishop keeps cotrolling two squares that are not on the same diagonal, and zugzwang forces it to abandon one of those, and lose as a consequence. There recently was an unlike-Bishops end-game in Graham's tourney where this happened. (It might even have been a Schooner game.) The engine just did not see it coming until it happened in the root, where it could no longer null move.

[D Sceviour]

There recently was an unlike-Bishops end-game in Graham's tourney where this happened. (It might even have been a Schooner game.) The engine just did not see it coming until it happened in the root, where it could no longer null move.

Yes, I saw that game. Opposite colored bishop endings are almost the equivalent of no minors/majors for the purpose of calculating potential zugzwang. I am considering adding code for that in null move search. What do think?

I still think there might be a point to calculating free pawns in static evaluation on the horizon.

[hgm]

Well, my conclusion was that it is not safe to do null move even with a single Bishop. (I also remember a Joker game from years ago where it lost with Bishop vs Knight due to zugzwang.) In the draw-positions thread there were a few positions shown that could be won by bringing a side that had a single Queen in zugzwang. So basically any position with only a single piece would seem to need verification that zugzwang isn't a problem.

I am now inclined to think that such a verification search is best done as a singularity search that counts how many moves can be done that do not fail low compared to the shifted window ('playable moves'), and forbid null move when this drops below 4.

[bob]

Position 2: is d2 backward? is e4 backward?

8
7
6
5
4
3
2
1
	a	b	c	d	e	f	g	h

K6k/2p1p1pp/3p4/3P4/4P3/8/3P4/8 w - -

no and no. e4 can be supported by d2-d3, d2 is iffy. It can't be supported, but it can be used to advance e pawn and it is a bit hard to attack it.

It could be useful to mark e4 as backward to some degree. From a statically point of view, e4 pawn cannot be advanced without being captured, so it is weak. Clearly, with some dynamics pawn has a support and the weakness disappear. However, this is what search is for, and I fear that these bonus/penalties can have downsides.

I see the backward pawn term as a way of recognizing that a pawn that can't be protected by a friendly pawn is a weakness that can tie down one's pieces in defense.

If you look at current crafty (24.1) you will note there is not specific backward pawn code, just "weak pawns" which are pawns that can not be defended by friendly pawns. They get weaker if they can't advance. And the evaluation takes other pawns (both sides) into consideration. IE with black pawns at c5 and e5, white pawns at c3 and d3, the d3 pawn is weak. It can't be defended by a pawn, it can't safely advance to escape an attack. And if advanced it turns into an isolated pawn which is just as weak.

It also matters where these pawns are. A more advanced pawn is often easier for the opponent to attack, for example...

So yes, d2 is weak, but not nearly as weak as it could be.