The Xiphos Material Evaluator

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
D Sceviour
Posts: 375
Joined: Mon Jul 20, 2015 3:06 pm
Contact:

Re: The Xiphos Material Evaluator

Post by D Sceviour » Wed Nov 07, 2018 3:15 pm

hgm wrote:
Wed Nov 07, 2018 12:00 pm
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
Posts: 375
Joined: Mon Jul 20, 2015 3:06 pm
Contact:

Re: The Xiphos Material Evaluator

Post by D Sceviour » Wed Nov 07, 2018 4:07 pm

Daniel Anulliero wrote:
Wed Nov 07, 2018 9:13 am
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.

User avatar
hgm
Posts: 22665
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: The Xiphos Material Evaluator

Post by hgm » Wed Nov 07, 2018 10:57 pm

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
Posts: 375
Joined: Mon Jul 20, 2015 3:06 pm
Contact:

Re: The Xiphos Material Evaluator

Post by D Sceviour » Thu Nov 08, 2018 1:07 am

hgm wrote:
Wed Nov 07, 2018 10:57 pm
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().

User avatar
hgm
Posts: 22665
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: The Xiphos Material Evaluator

Post by hgm » Fri Nov 09, 2018 11:38 am

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.

Post Reply