The Xiphos Material Evaluator

[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.

[D Sceviour]

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).

The bishop pair is one of two imbalances recognized by the Xiphos evaluator. The other is increased pawn value with exchanges. Of course programmers like to have their own special routines, but the simplicity is what is so interesting.

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.

I never found any advantage with material hash. It is faster to simply add up the material on the horizon, or keep a running material score in makemove(). Ethereal and Xiphos combine the material values with PST during initialization, and then keep a running score. Because of Texel tuning, I used to calculate "static" material on the horizon. However, Schooner now uses a material method similar to Ethereal and Xiphos (and probably a lot of other engines). I call it Dynamic Scoring when a running material value is maintained in makemove().

[hgm]

No, that is certainly not faster.

score = materialHash[materialKey & MASK];

will definitely be at least an order of magnitude faster than any loop you would need to sum up the material value of all pieces in a leaf.