Mobility eval

[hgm]

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.

[lucasart]

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.

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 mobility

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 &#40;unsigned color = White; color <= Black; color++) &#123;
		const unsigned us = color, them = opp_color&#40;us&#41;;
		const uint64_t mob_targets = ~&#40;B->st->attacks&#91;them&#93;&#91;Pawn&#93; | B->b&#91;us&#93;&#91;Pawn&#93;);
		
		uint64_t fss, tss, occ;
		unsigned fsq, piece;
		int count;
		
		/* Generic linear mobility */
		#define MOBILITY&#40;p0, p&#41;								\
			count = count_bit_max15&#40;tss&#41; - mob_zero&#91;p0&#93;;	\
			e->op&#91;us&#93; += count * mob_unit&#91;Opening&#93;&#91;p&#93;;		\
			e->eg&#91;us&#93; += count * mob_unit&#91;EndGame&#93;&#91;p&#93;
		
		/* Knight mobility */
		fss = B->b&#91;us&#93;&#91;Knight&#93;;
		while &#40;fss&#41; &#123;
			fsq = next_bit&#40;&fss&#41;;
			tss = NAttacks&#91;fsq&#93; & mob_targets;
			MOBILITY&#40;Knight, Knight&#41;;
		&#125;
		
		/* Lateral mobility */
		fss = get_RQ&#40;B, us&#41;;
		occ = B->st->occ & ~B->b&#91;us&#93;&#91;Rook&#93;;		// see through rooks
		while &#40;fss&#41; &#123;
			fsq = next_bit&#40;&fss&#41;; piece = B->piece_on&#91;fsq&#93;;
			tss = rook_attack&#40;fsq, occ&#41; & mob_targets;
			MOBILITY&#40;Rook, piece&#41;;
		&#125;

		/* Diagonal mobility */
		fss = get_BQ&#40;B, us&#41;;
		occ = B->st->occ & ~B->b&#91;us&#93;&#91;Bishop&#93;;	// see through bishops
		while &#40;fss&#41; &#123;
			fsq = next_bit&#40;&fss&#41;; piece = B->piece_on&#91;fsq&#93;;
			tss = bishop_attack&#40;fsq, occ&#41; & mob_targets;
			MOBILITY&#40;Bishop, piece&#41;;
		&#125;
	&#125;
&#125;

Some people also do a non linear scoring, to avoid giving to much bonus (eg. a queen having already 8 squares increases to 12 is perhaps not such a big deal while going from 1 to 5 is really uncramping the queen)
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.

[Don]

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.

Mobility is critically important to a modern chess program. Komodo basically does this:

1. gets a count of squares a piece can move to
2. do not count empty squares attacked by enemy pawns.

The count is used to index into a table which is "zero adjusted" so that a piece with low mobility is negative, "typical" mobility is zero and good mobility is positive. The table is non-linear so that having some mobility is more important than having a lot. In other words if one bishop is highly mobile and the other has little mobility it is much more important to help the bishop with low mobility.

I think we also count a point for mobility to own non-pawn pieces (which is sort of like a defense bonus) and of course attacks to the enemy pieces except his pawns if they are defended by a pawn. Not 100% sure of the exact details of this.

Komodo also computes mobility for the knights using the same rules.

There is another kind of mobility that we call "range" (which Komodo does not use but some of my previous programs used.) It is basically the total mobility if only pawns were on the board. It is a reasonable substitute for mobility because pawns tend to be a lot more permanent and pieces are usually transitory. So a bishop of g2 would not be penalized for the knight on f3 for instance with this kind of mobility. Some programs use BOTH kinds of mobility. Range can be calculated fast if you precompute it in the pawn structure hash - it would require only 2 tables which would have to be stored in the pawn hash record, one for diagonals and one for orthogonals and possibly one for knights.

[Don]

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.

Mobility is critically important to a modern chess program. Komodo basically does this:

1. gets a count of squares a piece can move to
2. do not count empty squares attacked by enemy pawns.

The count is used to index into a table which is "zero adjusted" so that a piece with low mobility is negative, "typical" mobility is zero and good mobility is positive. The table is non-linear so that having some mobility is more important than having a lot. In other words if one bishop is highly mobile and the other has little mobility it is much more important to help the bishop with low mobility.

I think we also count a point for mobility to own non-pawn pieces (which is sort of like a defense bonus) and of course attacks to the enemy pieces except his pawns if they are defended by a pawn. Not 100% sure of the exact details of this.

Komodo also computes mobility for the knights using the same rules.

There is another kind of mobility that we call "range" (which Komodo does not use but some of my previous programs used.) It is basically the total mobility if only pawns were on the board. It is a reasonable substitute for mobility because pawns tend to be a lot more permanent and pieces are usually transitory. So a bishop of g2 would not be penalized for the knight on f3 for instance with this kind of mobility. Some programs use BOTH kinds of mobility. Range can be calculated fast if you precompute it in the pawn structure hash - it would require only 2 tables which would have to be stored in the pawn hash record, one for diagonals and one for orthogonals and possibly one for knights.

P.S. Larry considers forward mobility important but we have not done much work on that with Komodo so I cannot offer an opinion.

[Michel]

Larry considers forward mobility important but we have not done much work on that with Komodo so I cannot offer an opinion.

Miguel mentioned here that if you make forward mobility too important then it will become advantageous to move your pieces backward.... So you would need to restrict this in some way....

[Mincho Georgiev]

Unfortunately, is heavily weights dependent.
I've tested the following schemes:

1. "real mobility" - no LVA attacked squares - with increments.
2. -||- - no pawn attacked squares - increments.
2. mobility with increments including capturing squares /all captures/.
3. mobility without occupied squares.
4. "space" - all squares regardless of the attack on each one of them - with no increments, but collective bonus instead.

For me, No.4 works best. It could be just a good balancing regarding the rest of the evaluation terms tough, I'm pretty sure - it's all about the weights and that makes it so hard to find the best one - needs A LOT of testing.
Plus to No.4 - I'm testing for center control and wide center control. It gives me good results, combined with the collective "space" bonuses/penalties.

[Don]

Unfortunately, is heavily weights dependent.
I've tested the following schemes:

1. "real mobility" - no LVA attacked squares - with increments.
2. -||- - no pawn attacked squares - increments.
2. mobility with increments including capturing squares /all captures/.
3. mobility without occupied squares.
4. "space" - all squares regardless of the attack on each one of them - with no increments, but collective bonus instead.

For me, No.4 works best. It could be just a good balancing regarding the rest of the evaluation terms tough, I'm pretty sure - it's all about the weights and that makes it so hard to find the best one - needs A LOT of testing.
Plus to No.4 - I'm testing for center control and wide center control. It gives me good results, combined with the collective "space" bonuses/penalties.

The problem with any way of doing evaluation is that you cannot be sure that you implemented it the best way. Komodo's is relatively elaborate, but who is to say it's any good? It could be that it works because we are missing other important terms or because we did not set the weights right for previous simpler attempts. All evaluation is like this, it's really a black art.

[diep]

Unfortunately, is heavily weights dependent.
I've tested the following schemes:

1. "real mobility" - no LVA attacked squares - with increments.
2. -||- - no pawn attacked squares - increments.
2. mobility with increments including capturing squares /all captures/.
3. mobility without occupied squares.
4. "space" - all squares regardless of the attack on each one of them - with no increments, but collective bonus instead.

For me, No.4 works best. It could be just a good balancing regarding the rest of the evaluation terms tough, I'm pretty sure - it's all about the weights and that makes it so hard to find the best one - needs A LOT of testing.
Plus to No.4 - I'm testing for center control and wide center control. It gives me good results, combined with the collective "space" bonuses/penalties.

The problem with any way of doing evaluation is that you cannot be sure that you implemented it the best way. Komodo's is relatively elaborate, but who is to say it's any good? It could be that it works because we are missing other important terms or because we did not set the weights right for previous simpler attempts. All evaluation is like this, it's really a black art.

The problem is measuring whether something works.

Maybe 1 million games at say 5 minutes all?

[Don]

Unfortunately, is heavily weights dependent.
I've tested the following schemes:

1. "real mobility" - no LVA attacked squares - with increments.
2. -||- - no pawn attacked squares - increments.
2. mobility with increments including capturing squares /all captures/.
3. mobility without occupied squares.
4. "space" - all squares regardless of the attack on each one of them - with no increments, but collective bonus instead.

For me, No.4 works best. It could be just a good balancing regarding the rest of the evaluation terms tough, I'm pretty sure - it's all about the weights and that makes it so hard to find the best one - needs A LOT of testing.
Plus to No.4 - I'm testing for center control and wide center control. It gives me good results, combined with the collective "space" bonuses/penalties.

The problem with any way of doing evaluation is that you cannot be sure that you implemented it the best way. Komodo's is relatively elaborate, but who is to say it's any good? It could be that it works because we are missing other important terms or because we did not set the weights right for previous simpler attempts. All evaluation is like this, it's really a black art.

The problem is measuring whether something works.

Maybe 1 million games at say 5 minutes all?

Indeed, that is a big problem. We have to be happy with 50,000 games for most of our measurements at fast levels - and fast levels do not always come out the same. If the change helps significantly you can prove it's better without that many games.

[hgm]

Miguel mentioned here that if you make forward mobility too important then it will become advantageous to move your pieces backward.... So you would need to restrict this in some way....

This can be counter-acted by the piece-square tables.