TalkChess.com

[H.G.Muller]

Well, like Gerd says, it is mainly a bit-twiddling addiction. We don't do it because we need it to program Chess engines, but we do Chess programming because it provides us with a nice set of opportunities to come up with twiddles like this...

Upto now Joker only used the square color for evaluating King safety: if it makes a hole in the Pawn shield by advancing the Pawn directly in front of its King, it gets a lethal penalty if the opponent still has a Bishop of that color, and its own Bishop is not filling the hole.

In the version I am currentl testing, though, I use it also for good vs bad Bishop and B vs N evaluation: I count the number of own Pawns on each color, and subtract that (multiplied by a suitable weighting factor) from the value of the Bishop, double-counting Pawns on its own color (and half-counting Pawns on a- and h-file and 2nd and 7th rank, on the assumption that these are less of an obstacle). I have no idea yet if this helps.

The square color is only explicitly calculated for the Bishops, though: for the Pawn counting I use an array of 64 bytes (in 0x88 layout, shared with some other table indexed by square number) that has the Pawn weight (1 or 2, depending on if it is an fringe or center Pawn) in the low nybble for white squares and in the high nybble fror black squares. I can then simply add that for all the Pawns of a certain side, and later extract the totals from the nybbles and weight them depending on Bishop color.

Of course the end-game stuff you mention is very important, but Joker has no end-game code yet at all. My priority is to improve so that it can survive into the end-game... The weak squares is a nice idea. Joker's Knight scoring already involves a bonus for Knights on center squares that can no longer be attacked by a Pawn, and one can easily generalize that for Bishops.

The square-color calculation of the Bishops in Joker kind of a legacy thing: when I will finally do a clean-up of the code I will no longer use it, but derive the presence of Bishops of either color from a piece-makeup variable that is differentially updated on make/unmake. This piece-makeup distinguishes Bishops by color, and is currently used as an index in many tables. E.g. to see what the highest piece or the highest two pieces are (for futility pruning, or King safety), the total amount of non-Pawn material (for game-stage determination), number of non-pawns, if nul-move pruning is allowed, etc. I might as well get the material evaluation from there as well, so that I no longer have to differentially update that separately. And for the color of Bishops. The piece-makeup variable is updated by having a number for each piece type in the piece list (B=1 or 2, N=4, R=12, Q=36), that is subtracted from it when the piece is captured, so that a unique code results. (Yes, this system is not resistant to under-promotions. If I were ever to implement supernumerary under-promotions, it would have to reassign codes and recalculate the tables on make and unmake...)