The Xiphos Material Evaluator

[Joost Buijs]

In my experience Texel tuning works extremely well, especially for tuning the material values.
The only thing that gave me some trouble was the king-attack-multiplier table which is nonlinear in my program.
For my program I found the following piece values to be optimal, of course they also depend upon the PSQ and other position values.

Code: Select all

// midgame
int valuePawnMG   =   85;
int valueKnightMG =  353;
int valueBishopMG =  352;
int valueRookMG   =  477;
int valueQueenMG  =  913;

// endgame								
int valuePawnEG   =  115;
int valueKnightEG =  285;
int valueBishopEG =  316;
int valueRookEG   =  556;
int valueQueenEG  = 1185;

The only thing that strikes me is that a queen seems to be worth 2 rooks + 0.63 pawn near the endgame, I always thought that 2 rooks were a little bit stronger than a queen near the endgame. Of course it also depends upon the positions you use for the tuning process.

[tomitank]

I spent a lot of frustrating time on the previous version of Schooner with Texel's tuning, and got no elo change. This inspired me to start again with another evaluator. The simplicity of the Xiphos material evaluation is stunning:

pawn value = 100
knight value = 310
bishop value = 330
rook value = 500
queen value = 1000

That's it! There is nothing to tune. The basic formula for piece values was proposed in 1958 by Larry Evans in his book "New Ideas In Chess". It has changed little since.

Compare this with the obscure imbalance formula used by Bob Hyatt in Crafty, or the esoteric quadratic formula use by Stockfish. There is a lesson to learn from beginning programmers to the Stockfish team. You do not need a fancy material formula to have a strong 3000+ engine. There is a temptation to want to change and improve on the formula. However, remember the advice of Robert Fischer when asked the secret of finding good moves - "Sit on your hands".

The other parameters compensate the values. eg: PST, Mobility etc.
For example:
if you use a separate value (material) in the end game, they would get similar results, because the other parameters compensate that.

[jdart]

I have fixed piece values and they are not very different from the ones quoted here.
But I have a lot of adjustments on top of those: for example, a "trade down" term that encourages trades of pieces when ahead, and a bunch of special-case endgame code that evaluates piece configurations when low in material.

--Jon

[D Sceviour]

I have fixed piece values and they are not very different from the ones quoted here.
But I have a lot of adjustments on top of those: for example, a "trade down" term that encourages trades of pieces when ahead, and a bunch of special-case endgame code that evaluates piece configurations when low in material.

That is a weakness of the Xiphos material values. They do not consider endgame imbalances. For endgame, there is an examination of specific material imbalance which equate to forced draw. Even though simple, everyone seems to be pleased with Schooner's understanding of the endgame. This was also faster than interrupting the evaluator with an EGTB WDL probe.

KK
KNK
KBK
KNKP
KBKP
KNNK
KRKN
KRKB
KBBKB
KRNKR
KRBKR
KBNKB
KBNKN
KBNKR

[jdart]

IMO you have to look not just at forced draws but also consider that some configurations with pawns might be hard to win or could be exchanged down into a drawn ending. See adjustMaterialScore in https://github.com/jdart1/arasan-chess/ ... coring.cpp.

--Jon

[Daniel Anulliero]

Hi
I run à "just to see" test , games at STC 1'+ 250 ms between Isa 2.0.64 and a dev version with xiphos material values .
I stopped after 120 games and -50 elo for the de one .

[hgm]

Compare this with the obscure imbalance formula used by Bob Hyatt in Crafty, or the esoteric quadratic formula use by Stockfish.

Now try who it thinks is ahead with 3 Queens vs 7 Knights.

Having the value of all pieces go up towards the end-game is a simple and usuful method for encouraging piece trading when ahead. Trading Pawns should not be considered advancing the game phase, however. Actually more the opposite.

It is important to not only score KRNKR as draw, but also KRNKRP. Otherwise the engine will happily trade into KRNKRP (e.g. from KRNPPKRNP) and think it is OK as long as it refrains from capturing the last Pawn.

[D Sceviour]

Now try who it thinks is ahead with 3 Queens vs 7 Knights.

That is fantasy chess. Testing for stuff like this on the horizon can slow the engine. Would you tie the shoelaces together of your opponent before challenging him to a footrace?

Having the value of all pieces go up towards the end-game is a simple and usuful method for encouraging piece trading when ahead. Trading Pawns should not be considered advancing the game phase, however. Actually more the opposite.

It is not worth it. Do not interfere with the flow of thought. Let the engine find the move to win. That is the human style and democratic thing to do. The proof is in the elo.

It is important to not only score KRNKR as draw, but also KRNKRP. Otherwise the engine will happily trade into KRNKRP (e.g. from KRNPPKRNP) and think it is OK as long as it refrains from capturing the last Pawn.

Any time there is a pawn on the board, there is a danger of winning for the inferior side. Every pawn position has to be tested with depth. Only KBKP / KNKP are quickly cutoff. Even then they are not equated as a force draw; rather their scores are reduced or minimized to give the pawn a chance to show its stuff.

Code: Select all

  if (piececount==4) {
     if ((wknight | wbishop) == 1 && (bpawn==1))
        return min(eg,0);
     if ((bknight | bbishop) == 1 && (wpawn==1))
        return max(eg,0);
  }

I have not noticed any problem yet with KRNPPKRNP, but I agree there are a few recurrent endgame themes that create trouble. Schooner currently evaluates this single passed pawn endgame very poorly on the horizon. It takes 7 ply to see that black is winning. To fix *** in the future:

[d]8/1p6/3p2k1/K2P1p2/8/P7/1PP5/8 b - - 0 40

I used to have a poor man's KP bitbase to quickly assess passed pawns, but it does not seem to be good enough now. Maybe a KPK bitbase might help.

[D Sceviour]

I run à "just to see" test , games at STC 1'+ 250 ms between Isa 2.0.64 and a dev version with xiphos material values .
I stopped after 120 games and -50 elo for the de one .

Try again. Check your source code for bad material compensations that are no longer needed. You may find that eventually there is no difference at all. That is the point - fancy material formula only slow the engine. On the other hand, maybe you have a very good material formula that is yours, and you like it.

[hgm]

They don't slow the engine at all. They are just as instantly as simple material formulas, a single table lookup indexed by the material key. The material table takes care of the Bishop pair bonus, and you get drawn-end-game discounting as a free extra, plus any non-linear effect you might want. (Such as trading encouragement, leveling effect...)

Surely your engine accounts for the B-pair bonus? It is well known that an early BB-vs-BN imbalance gives you a score of 59-60%, and it would be really stupid to squander such an advantage by a quick and unnecessary B-for B exchange (which the opponent with a realistic material eval will surely seek).

If you hash the material, rather than using a precalcuated table, it is just as fast from a practical point of view, as misses even in a modest-size table are virtually non-existing. But you can then store some more info in the table, such as game phase, and piece counts, so you would not have to keep track of those incrementally. So it only speeds up your engine.