An experiment with material imbalances and game-phase

[Evert]

A little while back I decided to play around a bit with tweaking the evaluation of material imbalances in Jazz, and see whether there's anything to be gained by doing "game-phase dependent" evaluation of piece values.

What I have in Jazz is some of the Kaufman stuff (I don't have the rook scaling with number of pawns; it tested as worse when I tried it, but it may be redundant with open files anyway) and a bad-trade penalty similar to what is done in Crafty (well, exactly the same really, since there's not much you can change in the implementation). What I was particularly interested in was experimenting with value-adjustment of major pieces in the presence of minor pieces, an idea that has been mentioned a few times here and that seems "logical" on some level.

In order to get a reasonable "guesstimate" for starting values for some of the coefficients I thought I'd look at some of the different ways other people do material imbalances (for instance in a material table). The problem here was that typically the method is described, but not typical terms or the value of the coefficients. The chess programming wiki did mention one particular open source program (of debated origin) with a material imbalance table, so I decided to have a look.

The material imbalance stuff was easy enough to find, but the code to initialise the table is a bit too convoluted for me to easily see what it does, but the code is self-contained enough that you can initialise the table (treating the initialisation code as a black box) and then simply query it. This didn't proof to be very illuminating, however.

So I tried something that we all know never works: I replaced my own material evaluation code with the material table and ran a test match to see what I might gain from tweaking my material evaluation.

The result was a lovely -60 Elo, which just proofs what I already said above: copying random evaluation stuff from other programs does not work. It did convince me that maybe there are better things to spend time on though, like pawn evaluation (which is so far also proving tricky to improve although it is quite obvious that there is something to gain there).

[hgm]

I once discussed this with Larry, and his intuition was that the discount to be applied on the value of a higher piece due to interdiction by lower-valued opponent pieces would probably not be strictly proportional to the value of that piece, but have a weaker dependence, e.g. a square root. i.e. if a Queen suffers 150 cP from the presence of 3 opponent minors, a Rook would not suffer 500/950 * 150 = 79 cP, but more likely something like sqrt(500/950) * 150 = 109 cP. That is, if you want to fit all material cross terms with a single global formula. Of course you could try to measure and tune every cross term separately, but this seems a quite formidable endeavor. Many of the cross terms are quite small anyway. So I expect the application of a general universal law with just a few free parameters, and then fitting these parameters, to produce a better result than treating all combinations independently.

Of course cooperative effects are only one component you would want to put in the material table. Bonuses for trading down material or Pawns are another one.

[jdart]

Like everything else, it needs to be tested.

Programs differ somewhat in their stock or base piece values, for example for me Knight = 3.25 pawns, Rook = 5 pawns, Queen = 9.75 pawns. And depending on the values you have there the correction for material imbalance will of course differ.

I have special case code for common imbalances and also some general trade-down code and (recently) code to avoid trading down into unbalanced but drawish endgames. I am sure it is not optimal but also quite sure the program would play worse with no such code.

Houdini I have noticed seems to consider exchange sacrifices (such as the common R for B or N) more even than most programs. Which is intuitively right since this is a common part of high-level modern chess.

[jd1]

The chess programming wiki did mention one particular open source program (of debated origin) with a material imbalance table, so I decided to have a look.

The material imbalance stuff was easy enough to find, but the code to initialise the table is a bit too convoluted for me to easily see what it does, but the code is self-contained enough that you can initialise the table (treating the initialisation code as a black box) and then simply query it. This didn't proof to be very illuminating, however.

So I tried something that we all know never works: I replaced my own material evaluation code with the material table and ran a test match to see what I might gain from tweaking my material evaluation.

The result was a lovely -60 Elo, which just proofs what I already said above: copying random evaluation stuff from other programs does not work.

True, I tried the Strelka material tables in Toga several months ago and got a similar result.

Jerry