A idea about mobility evaluation

Discussion of chess software programming and technical issues.

Moderators: hgm, Dann Corbit, Harvey Williamson

Han Chengye
Posts: 23
Joined: Sun Feb 08, 2009 3:54 am

A idea about mobility evaluation

Post by Han Chengye »

So if we can precaculate the moves of rooks, bishops etc, why we don't precaculate mobility at the same time?
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: A idea about mobility evaluation

Post by bob »

Han Chengye wrote:So if we can precaculate the moves of rooks, bishops etc, why we don't precaculate mobility at the same time?
Did that in older versions of Crafty. Problem is, mobility is not a static issue, even though the possible moves are. But if you look in older versions of Crafty you will find exactly this idea. However, in current crafty,different squares have different weights in the mobility calculation. But in thinking about it, this might actually be a workable idea with the current approach we are using. Will look at it more carefully...
Dann Corbit
Posts: 12476
Joined: Wed Mar 08, 2006 8:57 pm
Location: Redmond, WA USA

Re: A idea about mobility evaluation

Post by Dann Corbit »

Han Chengye wrote:So if we can precaculate the moves of rooks, bishops etc, why we don't precaculate mobility at the same time?
Here is an interesting mobility puzzle:
[d]8/8/5k2/8/8/4K3/6p1/5N1N b - -

The pawn has three moves possible, so we might say that it's mobility is 3 move choices, but what about the next ply? Besides a queen it can also underpromote to knight, bishop or rook. In the case of a knight, it can attack squares that the queen cannot attack. In the case of a bishop or rook, we can limit the squares (a direct subset of the squares a queen can attack). So a pawn about to promote has special mobility options in a sense. This can (of course) be very valuable in cases such as winning underpromotion to a knight or forcing a draw by under promotion to knight or bishop (or other possibilities).

My notion in this case is to consider the mobility of the special pawn as :
gxf1=Q, g1=Q, gxh1=Q,
gxf1=R, g1=R, gxh1=R,
gxf1=B, g1=B, gxh1=B,
gxf1=N, g1=N, gxh1=N
so 12 move choices, and then let the forward plies take care of themselves, but I am not sure it is the best idea.

I guess that your idea has to do with a bare board (IOW, if I put a bishop on A1, it attacks 7 squares but on E5 it attacks 13 squares (if we consider x-rays and battery). But in some special cases (like the pawn above) the move choices become more potent when captures and promotions are possible (which also explains why A and H pawns are not as valuable as B-G pawns).

On the other hand, it is possible to precalculate (for the whole board and every possible configuration) all possible forward moves including x-rays, pins, attacks, defends, etc, but it requires a lot of code. My approach for this notion is to write a program to write the move generation functions. Otherwise it becomes much too tedious.
User avatar
Eelco de Groot
Posts: 4556
Joined: Sun Mar 12, 2006 2:40 am
Full name:   

Re: A idea about mobility evaluation

Post by Eelco de Groot »

Dann Corbit wrote:
Han Chengye wrote:So if we can precaculate the moves of rooks, bishops etc, why we don't precaculate mobility at the same time?
Here is an interesting mobility puzzle:
[d]8/8/5k2/8/8/4K3/6p1/5N1N b - -

The pawn has three moves possible, so we might say that it's mobility is 3 move choices, but what about the next ply? Besides a queen it can also underpromote to knight, bishop or rook. In the case of a knight, it can attack squares that the queen cannot attack. In the case of a bishop or rook, we can limit the squares (a direct subset of the squares a queen can attack). So a pawn about to promote has special mobility options in a sense. This can (of course) be very valuable in cases such as winning underpromotion to a knight or forcing a draw by under promotion to knight or bishop (or other possibilities).

My notion in this case is to consider the mobility of the special pawn as :
gxf1=Q, g1=Q, gxh1=Q,
gxf1=R, g1=R, gxh1=R,
gxf1=B, g1=B, gxh1=B,
gxf1=N, g1=N, gxh1=N
so 12 move choices, and then let the forward plies take care of themselves, but I am not sure it is the best idea.

I guess that your idea has to do with a bare board (IOW, if I put a bishop on A1, it attacks 7 squares but on E5 it attacks 13 squares (if we consider x-rays and battery). But in some special cases (like the pawn above) the move choices become more potent when captures and promotions are possible (which also explains why A and H pawns are not as valuable as B-G pawns).

On the other hand, it is possible to precalculate (for the whole board and every possible configuration) all possible forward moves including x-rays, pins, attacks, defends, etc, but it requires a lot of code. My approach for this notion is to write a program to write the move generation functions. Otherwise it becomes much too tedious.
Dann, but you are confusing the man :) This is all not so important. The pawn will likely become a Queen, so that overshadows all the mobility calculations anyway. The position is highly unquiet with a pawn on the seventh Rank for instance Stockfish will not try to do razoring. The pawn can just choose one square out of three options and the mobility of a Queen in positions after this is not so important. I think the proposed method is a good method for an approximate evaluation especially for cases when a piece has zero mobility. Zero mobility by the way is in my opinion worth computing accurately much more than mobility in a couple of moves. For instance if there are pawns in your arsenal but they all have zero mobilty, they are all blocked by other pawns for instance, no moves in the moves list, you can give a score alreay to how closed the position is.

The "closedness of the position" could be a weight for the mobility and value of all the other pieces, for instance if you want to create a anti-human mode that avoids the closing by experts like Pablo Restrepo. You would only need the moves list and the list of available material. I have not tried anything like this but I think for creating interesting chess personalities already this could be a good way to start.

Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: A idea about mobility evaluation

Post by bob »

I re-implemented this idea since our mobility was slowly modified to be something that could once again be pre-computed. The net effect was a 3-5% speed improvement. This will be in 23.2 once we release it.