how to recognize draws with a pawn ?

[PK]

How would the Pawn side see that KBK is worse than KBKP is worse than KBKPP if material is set to 0?

Passed pawn bonus?

[Evert]

How would the Pawn side see that KBK is worse than KBKP is worse than KBKPP if material is set to 0?

Passed pawn bonus?

Yes.
Also, PST values and asorted bonuses for the kings.

Not that it matters much in this case, unless you can promote the pawn now or win the Bishop, KBKP is a dead draw.

[Ras]

In endgames where one side has only a minor piece, but the other side still has pawns, I correct the eval to about +5 centipawns for the side with the pawns if the eval is negative up to this point.

That has the nice side-effect that the engine can see some defence lines if it is down in material. E.g. opponent has bishop and two pawns, my engine has knight and one pawn. Trading the knight for two pawns is a good option here.

[jdart]

I usually keep track of whether each side has a material combination that would allow it to win. If it doesn't but is nominally ahead in material, the material evaluation is set to 0.

I have tried this (including cases with pawns) but surprisingly I could not get it to test better over a long series of games. (I do however recognize a "wrong color Bishop" draw with KBP vs K).

Also note: there are positions where the better side does have mating material but only the other side has pawns, for example this one from a recent game:

[d] 4R3/8/1r6/1n6/1P6/4k3/6K1/8 b - - 0 74

This is a draw (6-man TBs) unless Black plays the blunder Re6. (KRN vs R is known drawn but here there is a pawn). I used to detect "near draw" situations like this where the piece configuration was drawn or drawish but there were pawns. I took this out but may re-introduce it.

This can get tricky though because not all such configurations may be drawn.

--Jon

[hgm]

How would the Pawn side see that KBK is worse than KBKP is worse than KBKPP if material is set to 0?

Passed pawn bonus?

Yes.
Also, PST values and asorted bonuses for the kings.

Not that it matters much in this case, unless you can promote the pawn now or win the Bishop, KBKP is a dead draw.

Although it might work in some cases, it seems to me this is all a bit 'accidental'. The passer bonus of a single far advanced Pawn can easily by higher than the sum of the passer bonuses of two not-so-advanced Pawns. This would make the engine prefer the KBKP over KBKPP. Which, as remarked, indeed is a dead draw. So I would expect that it would work better if there was at least some material bonus for having the extra Pawn, to guarantee KBKP is always considered worse than KBKPP, no matter how large the passer bonus.

Of course setting material to 0 for certain material compositions is just a special case of an additive score bonus for that material, tuned to exactly cancel the piece values. It could be tuned differently, and in particular differently for KBKP and KBKPP. One method I used for material would be to store a one-byte unsigned code for each material composition, where values C = 0-200 would indicate an additive correction 4*(C-100) centi-Pawn. Codes above 200 would be used to index a small table with either white and black multipliers, or pointers to dedicated evaluation routines (for KPK, KBPK, KQKP).

My fear, however, is that to get the KBKP score never in favor of the Bishop, the score would be way to much in favor of the Pawn if it had the maximum passer bonus. So much that it could be preferred over positions where the Pawn side would have genuine winning chances. It seems that you would really want to compress the possible range of scores that could be covered by the passer bonus, i.e. use a multiplier rather than an additive score correction.

Of course the ultimately flexible method could allow both. If you have a material hash, it is not very important how much info per material composition you store. So you could store white and black multipliers, the score threshold that decides which of tehse two to use, and an offset to be added to this after the scaling:

Code: Select all

correctedAbsEval = ((absEeval > m->threshold ? m->factor[WHITE] : m->factor[BLACK]) * (absEval - m->threshold) >> 4) + m->offset;

Or, more compactly and branch-friendly

Code: Select all

absEval -= m->threshold;
correctedAbsEval = (absEval * m->factor[absEval < 0] >> 4) + m->offset;