trading pieces and pawns based on material balance

[zenpawn]

According to the old adage "the side with material advantage should trade pieces, while the side with material disadvantage should trade pawns." What's the best way to impart this knowledge to an engine?

No doubt it helps for your engine to know the drawish nature of RB vs R and even more so RN v R with no pawns. I'm also thinking about using asymmetric piece/pawn values such that being up material makes the opponent's pieces worth a bit more than yours and being down material makes the opponent's pawns worth a bit more.

[hgm]

One way to do it would be to give Pawns a negative weight in the game stage, and have larger piece values for the end-game than in the opening. The latter would encourage the engine that has a material advantage to advance the game phase towards the end-game. For which it has to trade pieces, and avoid trading Pawns.

[Sven]

One way to do it would be to give Pawns a negative weight in the game stage, and have larger piece values for the end-game than in the opening. The latter would encourage the engine that has a material advantage to advance the game phase towards the end-game. For which it has to trade pieces, and avoid trading Pawns.

What do you mean by "give Pawns a negative weight in the game stage"? Move game stage towards "opening" when trading pawns? That would sound interesting, I never tried that.

[Ras]

What's the best way to impart this knowledge to an engine?

Maybe not "the best" way, but that's what I have implemented:

- take up the material in the root position. For each side, record the number of pawns, minor pieces, rooks and queens. Record also the raw material difference to see who is up in material.
- in static eval, check whether the material has changed. If there are fewer pieces, but the balance is the same, trades must have taken place.
- give a small bonus/malus for trading pawns/pieces according to who is up or down in material.

It looks like that could be a problem when the root position is in a recapture situation - but the material gain of a pawn or a piece overrules the trade logic by far, so that will still work.

Additionally, I have implemented a small asymmetric penalty for the engine in case that the material is even, but pieces have been traded. This has to be quite small, something like 5 cps, so that the engine still will trade e.g. a knight for a bishop to rob the opponent of the pair of bishops. Or do a trade to inflict damage on the opponent's pawn structure.

It's just to encourage the engine to keep the board full if a trade doesn't gain any advantage. The idea is that my system is designed to play against humans, not computers. With a fuller board, humans are more likely to commit tactical errors.

[zenpawn]

- give bonus/malus for trading pawns/pieces according to who is up or down in material.

This sounds very close to what I was envisioning with the asymmetric piece/pawn values based on material balance before adjustments. Nice to hear it wasn't totally crazy, and of course, I'll be testing it either way.

[hgm]

What do you mean by "give Pawns a negative weight in the game stage"? Move game stage towards "opening" when trading pawns? That would sound interesting, I never tried that.

Indeed. I guess usually Pawns are ignored in the game stage, which typically is something like 6*nrQueens + 3*nrRooks + nrMinors. You could add a term -0.25*nrPawns, say.

This might not be favorable for weighting other evaluation terms between opening and end-game value, however. (E.g. King Safety.)

Note that the usual way of linear interpolation between end-game and opening material value boils down to adding quadratic terms c_AB*nrPieceA*nrPieceB. With 5 non-royal piece types per side there are 55 such terms, and in principle they can all be tuned independently through their c_AB. They can be used for achieving various behaviors. One of those is to establish a 'trading gradient' of the kind mentioned by the OP. Another is for implementing the elephantiasis effect (3 Queens vs 7 Knights stuff). They could also do the Bishop pair (with the kludge that 2 Bishops alswways means a pair, and you never will have 3).

Really calculating this as a sum of 5 quadratic terms is a bit expensive. If the coefficients factorise as c_AB = v_A*w_B it can be calculated a lot cheaper. Updating it incrementally would be a bit cheaper. OTOH, a material hash table has such a large hit rate that it doesn't really matter how costly the calculation is.

To encourage trading pieces when ahead you need something like

c_A*nrPieceA*(9*wQ-9*bQ+5*wR-5*bR+3*wB-3*bB+3*wN-3*bN+wP-bP)

(white POV) where the second factor describes how much white is ahead. The weight c_A describes how badly you want to trade the pieces of type A. It should be negative for pieces you want to trade when ahead. It could be positive for Pawns.

[Sven]

What do you mean by "give Pawns a negative weight in the game stage"? Move game stage towards "opening" when trading pawns? That would sound interesting, I never tried that.

Indeed. I guess usually Pawns are ignored in the game stage, which typically is something like 6*nrQueens + 3*nrRooks + nrMinors. You could add a term -0.25*nrPawns, say.

I use 4*nrQueens + 2*nrRooks + nrMinors. That is a micro-optimization regarding speed (due to the power-of-two factors), and 4:2:1 also seems to be closer to the typical 10:5:3 material relation than 6:3:1.

This might not be favorable for weighting other evaluation terms between opening and end-game value, however. (E.g. King Safety.)

Yes, which makes me believe that using number of pawns in the game phase as you suggested might in total lead to complications. But at least it should be tested.

[Karlo Bala]

According to the old adage "the side with material advantage should trade pieces, while the side with material disadvantage should trade pawns." What's the best way to impart this knowledge to an engine?

No doubt it helps for your engine to know the drawish nature of RB vs R and even more so RN v R with no pawns. I'm also thinking about using asymmetric piece/pawn values such that being up material makes the opponent's pieces worth a bit more than yours and being down material makes the opponent's pawns worth a bit more.

That is just a partial solution. If a weaker side has N for R then it should keep the position closed. There are lots of similar exceptions.

[Lyudmil Tsvetkov]

According to the old adage "the side with material advantage should trade pieces, while the side with material disadvantage should trade pawns." What's the best way to impart this knowledge to an engine?

No doubt it helps for your engine to know the drawish nature of RB vs R and even more so RN v R with no pawns. I'm also thinking about using asymmetric piece/pawn values such that being up material makes the opponent's pieces worth a bit more than yours and being down material makes the opponent's pawns worth a bit more.

best thing is not to implement such a rule at all, as this is basically a purely human, psychological rule, mostly not available in stronger engines, as far as I can judge, and objectively bad/unreliable.

it should be best to leave to the pool of existing parameters to decide when and what to change. (of course, when you give preference to certain changes, and your mobility goes down/up simultaneously, once favouring and at other times damaging the trade, what is the point of it?)

[hgm]

I use 4*nrQueens + 2*nrRooks + nrMinors. That is a micro-optimization regarding speed (due to the power-of-two factors), and 4:2:1 also seems to be closer to the typical 10:5:3 material relation than 6:3:1.

Indeed, I usually also use something different. Fairy-Max uses 6:3:2 (but just to decide about King Safety and null move; it does not interpolate). What I mentioned were the Fruit values (IIRC).

Usingthe same interpolation weight for all game-phase-dependent term is a rough approximation anyway, King Safety, f.e., depends much more on the presence of a Queen then passer values.