Backward Pawns

[mjlef]

Now that I have a (somewhat) working program which has bitboards for pawns, I am looking at some better ways of scoring backward pawns. Looking at some other programs, I see various "definitions" of backward pawns:

All seem to require the pawn have no helper pawns on the side or behind it on adjacent files.
Some do a count of helper pawns and attacking pawns ahead of the pawn under consideration. If there are the same or equal number of helpers as attackers, the pawn is not considered backward.
Others just look at the square one or two in front of the pawn. If the square in front is attacked by the opponent, or if the square two in front of the pawn in attacked, but not defended, it is considered backward.
Some do special analysis of pawns on the original square, since thye have the option of a double move.

Backward pawns are complex, since interactions on adjacent files can change the status of being backward. So far, I am scoring them much like isolated pawns, since that is pretty much how they act.

Now that I have all these cool, fast bits, what do you think I should do with them?

BTW, the new C program uses 10x16 mailbox for most move generation, but carries along pawn bitboards for faster eval of a lot of things. So far it is 2.5-3 times faster than the old, slow (but still stronger) Pascal version.

Mark

[hgm]

I think the crucial property of backward Pawns should include that they are susceptible to frontal attack by enemy sliders (besides to not being defendable by other Pawns), either though a half-open file or through a diagonal.

[sje]

The Chess 4.x definition comes to mind, although not the exact details. I recall that they had two flavors of backward pawns, "mild" and "severe", and that these were scored differently.

[bob]

The Chess 4.x definition comes to mind, although not the exact details. I recall that they had two flavors of backward pawns, "mild" and "severe", and that these were scored differently.

This is what I do. the classic "horrible" backward pawn is where white has pawns at c4, d3, e4 (either c4 or e4 pawn can be removed without changing this). Black has pawns at c5 and e5. The white d-pawn can't move, period, because if it does, it will be captured by either the black pawn on c5 or e5, and the resulting pawn at d4 will be protected. So the white d-pawn is totally immobile and is almost worth nothing.

A less bad, but still very weak condition happens when you take the case where white has a pawn at c4 and d3, and black has a pawn at c5 or e5. The pawn is weak, and to advance it, you have to have one more piece attacking d4 than black does, since black already has one pawn helping restrain the pawn...

The above two "flavors" describe the pawn. The pawns are decidedly weaker if black has rooks since they can attack the pawn along the half-open file. But they are weak whether they can be attacked from the front or not, since knights and bishops cause white to commit pieces to avoid losing them, and in a king and pawn endgame, they are just another weakness that a lone king has to deal with.

[Gerd Isenberg]

Now that I have all these cool, fast bits, what do you think I should do with them?

For first level evaluation terms you'll likely multiply those bits with weights. Either by traversing/bitscanning sets and indexing the pawn-square tables by square and feature - or by bit[64] * char[64] dot-products, which seems less efficient with low populated bitboards, but nevertheless becomes more and more an alternative with fast simd- or popcnt- instructions.

You may further sub-class to get disjoint sets, to combine them for several purposes.

1. pawn plus stop square not defended or defendable by own pawns
2. pawns which stops are dominated by one or even two sentries
3. pawns on second/third rank
4. open pawns, so that opponent rooks may attack on half-open files
5. center and wing pawns like king related shield or storm pawns.
6. backward pawns as base of a chain, defending likely rammed pawns.
7. pawns which may push, but stay backward afterwards.

Backward pawns against two sentries become likely members of immobile pawns, like rammed center pawns defended by backward pawns as well, to decide about bad bishops.

Often some boolean features are appropriate (open backward pawn in center) to define some strategical goal (piece support to push the pawn against one sentry) and to scale second level terms with piece interactions. If the balance of pawn-structure defects becomes greater than one, (assuming almost same number of pawns for both sides but no passers or advanced candidates as compensation), it is likely the "weaker" side loses the pawn-ending and has to look for some compensation in piece-play, e.g. attacking the king on all costs rather than passively defending weak pawns by pieces.

Of course this is all easier said than implemented

The radical general approach might be an artificial neural network, where you feed in feature vectors for a final scalar output.

Gerd