Pawn backwardness

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Pawn backwardness

Post by bob »

xmas79 wrote:
Ferdy wrote: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)?
I don't see why the distinction is good. If the pawn is backward at b3, for example, but is currently on b2, it is JUST as backward sitting there. It can't be defended except by pieces, which is why it is weak in the first place (any backward pawn)...

There are other such things, for example isolated. No pawns on adjacent files for many. But Kmoch defined "artificially isolated" where a pawn is so far advanced no friendly pawns can safely advance to protect it. Just as weak as a real isolated pawn. AND just as important to detect and score correctly.
xmas79
Posts: 286
Joined: Mon Jun 03, 2013 7:05 pm
Location: Italy

Re: Pawn backwardness

Post by xmas79 »

D Sceviour wrote: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.
Why you score nothing for a backward pawn? unless it is attacked is a strong assumption for scoring a bad pawn structure, no?
D Sceviour wrote: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.
Sorry, what you are describing is a (pretty forced) compensation for the white "problem". And no, as black I would never play a5 and c5, but only a5 or c5, controlling the weak square b4, making the b2 backward, and not having the same weakness. So I don't agree with your argument.
xmas79
Posts: 286
Joined: Mon Jun 03, 2013 7:05 pm
Location: Italy

Re: Pawn backwardness

Post by xmas79 »

bob wrote:I don't see why the distinction is good. If the pawn is backward at b3, for example, but is currently on b2, it is JUST as backward sitting there. It can't be defended except by pieces, which is why it is weak in the first place (any backward pawn)...
The score distinction maybe is not important. The fact that an engine can recognize it as backward maybe is important.
bob wrote:There are other such things, for example isolated. No pawns on adjacent files for many. But Kmoch defined "artificially isolated" where a pawn is so far advanced no friendly pawns can safely advance to protect it. Just as weak as a real isolated pawn. AND just as important to detect and score correctly.
Agreed.
Sven
Posts: 4052
Joined: Thu May 15, 2008 9:57 pm
Location: Berlin, Germany
Full name: Sven Schüle

Re: Pawn backwardness

Post by Sven »

xmas79 wrote:I'm playing with pawn patterns. I enjoyed very much writing all the stuff, and I found it very straightforward also.... However there's the definition of "backward pawn" that is a bit "too" vague. Isolated pawns are... well... isolated.... But backward? Reading over and over the chessprogramming wiki the very same perplexity seems to emerge...

Right to the questions:

Position 1: is b7 backward?
[d]K6k/1p6/8/8/2p5/2Pp4/3P4/8 w - -


Position 2: is d2 backward? is e4 backward?
[d]K6k/2p1p1pp/3p4/3P4/4P3/8/3P4/8 w - -


Position 3: is g6 backward? are h3 and h2 backward?
[d]K6k/3p4/6p1/p1p3Pp/P1P5/7P/1P5P/8 w - -
I'd like to share my view about it.

The definition of a backward pawn that I learned is based on being backward "relative to something", not just on its own. That means, a pawn is backward relative to its friendly neighbor pawn(s) on which it cannot close the gap safely unless some pawn on the board is being removed (captured). I would translate this definition into an algorithm like this:

1. The pawn has at least one friendly neighbor pawn that is blocked by an enemy pawn and is more advanced than itself.
2. All squares in front of the pawn up to and including the one next to the least advanced one of all blocked friendly neighbor pawns found in step 1 are not occupied by a pawn.
3. The pawn cannot be defended safely.

This definition implies that a backward pawn is not necessarily residing on a half-open file, and that a blocked pawn is never backward. It leads to my following answers to the three example positions:

Pos. 1: yes (and b7 is the only backward pawn)
Pos. 2: no, no (but c7 and e7 are backward)
Pos. 3: no, no, no (but b2 and d7 are backward)
D Sceviour
Posts: 570
Joined: Mon Jul 20, 2015 5:06 pm

Re: Pawn backwardness

Post by D Sceviour »

Sven Schüle wrote:This definition implies that a backward pawn is not necessarily residing on a half-open file, and that a blocked pawn is never backward.
I agree "that a backward pawn is not necessarily residing on a half-open file." It seems to be the consensus that being on a half-open file in not a necessary condition for the definition of backward. Rather, a half-open file is an extra condition that has to be tested when scoring rook attacks. That is, there is no use for a rook to attack a backward pawn on a closed file. Further, a backward pawn on a closed file could be attacked by other pieces besides a rook.

I also agree that a blocked and unprotected pawn deserves a different description than backward. However, this differs from the classical definition of backward so not everyone may agree yet.

In position 1, b7 can be called a free pawn for the purposes of calculating safety. The difference is not trivial to avoid the description backward. For example, if b7 were attacked by a knight or bishop it could move safely to b6 because it is not truly backward.

The big shortfall is recognizing whether a pawn can advance safely. For static evaluation on the horizon that may be a necessary condition, especially for tempo. I am running some tests now on advancing availability tempo (called free pawns), and will report if anything is found. So far, results indicate it is very rare to find a position without free pawns, but when it does null move search is useless.

Chess players are in the natural habit of making two moves in advance in their eyes. It is natural for a human to make two moves with a knight to see what it attacks. There is no unique description for this - double move, intuition, attacks? For a chess engine, this is called a null move search where it allows a side to make two moves in row. The ability of a pawn to move safely is very important to avoid zugzwang in a null move search. Simply put, do not count the chickens before they hatch.
User avatar
hgm
Posts: 27811
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Pawn backwardness

Post by hgm »

In King Slayers pawn-hash entry I reserved fields for indicating the weakness of the structure against orthogonal and diagonal attacks. The current version doesn't use this yet, but the idea was that these would contain scores that are conditionally added to the recorded total score of the Pawn stricture, the condition being the presence (and number of) the corresponding sliders. So each backward Pawn on a half-open file would cause a penalty for that to be added to the 'rook bonus', etc. This then would be multiplied with the number of Rooks, and added to the Pawn-structure 'base score'.
D Sceviour wrote:Chess players are in the natural habit of making two moves in advance in their eyes. It is natural for a human to make two moves with a knight to see what it attacks. There is no unique description for this - double move, intuition, attacks? For a chess engine, this is called a null move search where it allows a side to make two moves in row. The ability of a pawn to move safely is very important to avoid zugzwang in a null move search. Simply put, do not count the chickens before they hatch.
This is why it is such a bad idea to apply enormous reductions to subsequent quiet moves with the same piece. It really wrecks the engine's ability to do any long term planning. (Where 'long' means something like 2 or 3 moves...) Repeatedly moving the same piece to squares it could not reach before should never be heavily reduced.
D Sceviour
Posts: 570
Joined: Mon Jul 20, 2015 5:06 pm

Re: Pawn backwardness

Post by D Sceviour »

hgm wrote:This is why it is such a bad idea to apply enormous reductions to subsequent quiet moves with the same piece. It really wrecks the engine's ability to do any long term planning. (Where 'long' means something like 2 or 3 moves...) Repeatedly moving the same piece to squares it could not reach before should never be heavily reduced.
Would you suggest sorting the move list order so a "planning move" has a higher priority? The planning move is from the piece that was moved two plies below.
User avatar
hgm
Posts: 27811
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Pawn backwardness

Post by hgm »

Indeed, this might be a good idea. In general, moves that were not possible two ply early (i.e. continuation with the same piece, or over a square that got empty in the previous two plies) has a much higher probability to come up with something good than moves you could already do two ply earlier. If the latter were any good, they probably would have been even better two ply earlier, and you should have searched them there. I used this system for extensions in my engine Usurpator, in a time when it was quite difficult to reach a depth of 3 in a full-width search.
D Sceviour
Posts: 570
Joined: Mon Jul 20, 2015 5:06 pm

Re: Pawn backwardness

Post by D Sceviour »

hgm wrote:I used this system for extensions in my engine Usurpator, in a time when it was quite difficult to reach a depth of 3 in a full-width search.
I also wrote a 3-ply program over 30 years ago. There had to be some way of getting the board to develop sensibly. I used a technique called "mobility board" – and it is still used in Schooner. Perhaps I will post about it if anyone is interested.