I've done quite a few experiments on which squares to count and which not to count. Strangely things like not counting squares occupied by our own pieces was a regression, and generally any condition based on pieces not pawns, was inferior. So I count all squares atacked by each piece that is not occupied by a friendly pawn or protected by an enemy pawn. I didn't do any experiment regarding the weighting of the squares themselves but rather the weighting of the pieces. Anyway here's what I currently do for mobilityhgm wrote:What is the current consensus on mobility evaluation?
I have seen that some programs just count legal moves (weighted by piece type), others count only moves to squares not controlled by enemy Pawns, while still others only count forward moves of some pieces. Is there a way that is considered 'best'?
From my piece-value measurements I know that forward moves on a piece are typically worth twice as much as backwards or sideway moves, so weighting them differently could make sense. (Only counting forward moves seems a bit extreme, though.) An alternative, which on average would achieve the same, would be to weigth by target square. If squares on central ranks are weighted more, this favors forward mobility, as pieces usually can only be safely kept on your own half of the board. (White and black weighting of the same square can of course be made different.)
I also wondered if there is a rationale for excluding only squares controlled by Pawns, as opposed to excluding squares controlled by any enemy piece of lower value. I guess mobility can also be looked upon as 'board control', and attacking a square with a Rook, even if it is protected by a Knight, still increases your control over that square (it prevents the opponent from entering it with a Queen, and it would allow you to enter it with a minor). Squares controlled by enemy Pawns can never be entered by your pieces, however, no matter how often you attack them. But attacking such squares could still prevent the opponent from entering them with a higher piece. So they might deserve to carry some (small) weigth.
I was planning to implement this by taking counts of each piece type that could reach a square (as a sort of material index of the material that reaches it), so that I can use a lookup table to translate that material to score, so that I can basically use any weighting scheme without requiring any additional computational effort.
Code: Select all
static void eval_mobility(const Board *B, eval_t *e)
{
static const int mob_zero[NB_PIECE] = {0, 3, 4, 5, 0, 0};
static const unsigned mob_unit[NB_PHASE][NB_PIECE] = {
{0, 4, 5, 2, 1, 0}, // Opening
{0, 4, 5, 4, 2, 0} // EndGame
};
for (unsigned color = White; color <= Black; color++) {
const unsigned us = color, them = opp_color(us);
const uint64_t mob_targets = ~(B->st->attacks[them][Pawn] | B->b[us][Pawn]);
uint64_t fss, tss, occ;
unsigned fsq, piece;
int count;
/* Generic linear mobility */
#define MOBILITY(p0, p) \
count = count_bit_max15(tss) - mob_zero[p0]; \
e->op[us] += count * mob_unit[Opening][p]; \
e->eg[us] += count * mob_unit[EndGame][p]
/* Knight mobility */
fss = B->b[us][Knight];
while (fss) {
fsq = next_bit(&fss);
tss = NAttacks[fsq] & mob_targets;
MOBILITY(Knight, Knight);
}
/* Lateral mobility */
fss = get_RQ(B, us);
occ = B->st->occ & ~B->b[us][Rook]; // see through rooks
while (fss) {
fsq = next_bit(&fss); piece = B->piece_on[fsq];
tss = rook_attack(fsq, occ) & mob_targets;
MOBILITY(Rook, piece);
}
/* Diagonal mobility */
fss = get_BQ(B, us);
occ = B->st->occ & ~B->b[us][Bishop]; // see through bishops
while (fss) {
fsq = next_bit(&fss); piece = B->piece_on[fsq];
tss = bishop_attack(fsq, occ) & mob_targets;
MOBILITY(Bishop, piece);
}
}
}
Another thing is the squares themselves. Perhaps all things equal weighting the squares in the center a litttle more is better, but really I'm not sure it's that simple.
Another thing is space evaluation (have a look at StockFish). I find the idea a little strange as it seems quite redundant with mobility, but I may be wrong. I've never experienced with it.