Safe spatial mobility

[Lyudmil Tsvetkov]

Hi.
Everyone knows how important mobility in a chess program is. I suppose most engines will be using some variety of safe mobility (in distinction to counting just legal moves, which, chess-wise, could be pretty much distorting), and such an approach would be a reasonable one.

However, I am wondering if there are some engines that are using a more refined approach, based on a spatial dimension of mobility, which could be much more precise purely chess-wise than the standard one. A spatial dimension of mobility would take a deeper look at what piece mobility could offer in terms of functionality. Functionality would mean, of course, the ability or potential of a piece to do several tasks at the same time: for example, attacking and defending, controlling squares in different areas of the board, etc.

Overall, safe spatial mobility might be defined (just one of possible definitions) as controlling squares (safe ones) in 4 distinct areas of the board for the minor pieces and the rook, and 8 distinct areas for the queen: forward and to the right of the piece, forward and to the left of the piece, backward and to the right of the piece, backward and to the left of the piece for the minors, forward, backward, to the right and to the left for the rook, and a combining definition for the queen. Each accessible direction (ray of activity, consisting of available safe mobile squares) might score some additional points (let's say 2,3, maybe 5 centipawns).

[D]6k1/8/8/8/1BN1R3/8/8/6K1 w - - 0 1

For example, in the above diagram, the bishop on b4 would control squares (some of which maybe safe mobile, others not) forward and to the left (a5), forward and to the right (c5, d6, e7, f8), backward and to the left (a3), backward and to the right (c3, d2, e1); the knight on c4 squares forward and to the left (a5, b6), forward and to the right (d6, e5), backward and to the left (a3, b2), backward and to the right (d2, e3); the rook on e4 squares forward (e5, e6, e7, e8), backward (e3, e2, e1), to the left (d4), and to the right (f4, g4, h4).

I think such a method could be quite productive, if possible to do in an efficient way, because it would capture much truer the real bearing of mobility on the development of the game. I could even dare presume that such an approach should be the standard one (of course, with due modifications and improvements) in terms of calculating mobility. It would be, to my humble knowledge based on my couple of personal cents, much more precise than considering just safe mobility (assigning different values for more valuable and less valuable squares would be another thing, maybe done by most engines).

[D]6k1/5p2/N5p1/4p3/8/5P2/6P1/1B4K1 w - - 0 1

Looking at the second diagram (a simplistic representation, just to count squares), where, according to you, should the b1 white bishop go, in order for it to have its best mobility value: to a2, c2, d3 or e4, or maybe stay where it is now? On b1 it controls 4 squares along 2 spatial directions, on c2 it would control 6 squares along 4 spatial directions, on d3 7 squares along 4 spatial directions, and on e4 also 7 squares but along just 2 spatial directions. I think the 4 squares controlled by the bishop on d3 along 4 spatial directions would have a real added value chess-wise compared to the same number of squares controlled by the bishop on e4, but along just 2 directions. The difference might be meaningful and even significant, and, in most cases, a bishop on d3 would be the right answer. Going a bit further, is not the bishop on c2, controlling just 6 squares but along 4 directions, a better choice in terms of mobility than the bishop on e4, controlling one square more but along 2 directions less? I think, in many cases, it might be. So that calculating mobility without a spatial dimension (putting an accent on functionality and potential usefulness of the piece) might be a bit of an imperfect choice.

What is your take on that?
Does your engine consider something similar to spatial mobility, and does it bring you an added value?

Best, Lyudmil

[mcostalba]

Mobility is not so cheap to calculate, so your scheme would noticeably slower the evaluation (because mobility computation is practically duplicated n-times, for a bitboard engine)

We have done some experiment considering only forward mobility for bishops (I think Komodo does this), but with no positive result.

[Lyudmil Tsvetkov]

Mobility is not so cheap to calculate, so your scheme would noticeably slower the evaluation (because mobility computation is practically duplicated n-times, for a bitboard engine)

We have done some experiment considering only forward mobility for bishops (I think Komodo does this), but with no positive result.

Thanks Marco.

The idea behind it would be to better capture the functional potential of a piece, that could have an impact on the game.

I do not really see (maybe my fault) the logic behind considering only a single type of spatial mobility, when this would only limit the functionality assessment of the piece. But maybe I am wrong.

I hope that some day someone tries it, even with a single piece, to provide some evidence on behaviour.