Winboard Forum

I am considering to copy the mobility evaluation of Fruit (Of course I cannot copy the source code because I have a different data structure but I can copy the content).

I understood that Fruit evaluates mobility for every piece in the board except king and pawns.

I also understand that it evaluates in the following way:

1)count the number of pseudo legal possible moves of a piece(not considering pinned pieces)
2)reduce from it a constant
3)multiply the result by a constant.

(knightmoves-4*number of knights)*4+(bishopmoves-6*number of bishops)*5+(rooksmoves-7*number of rooks)*average_opening_end_game(2,4)+(queenmoves-13*number of queens)*
average_opening_end_game(1,2)


average_opening_end_game means that the number is average based on the stage of the game when the second number is for the endgame.

I wonder if somebody tried to replace his mobility evaluation by fruit's mobility and if he got positive results or negative results.

I also wonder how other free source code programs or non free source code programs evaluate mobility(I am too lazy to look at the sources if free programs espacially when there is a chance to understand faster by reading replies)

I evaluate mobility mainly based on the number of legal moves when I use the number of legal move in the previous ply for the opponent and may go to previous plies when the king is under threat and it is part of my path dependent evaluation that I hope to get rid of it(I am probably not going to get rid of another part).

Uri

Hi Uri,

It will be hard to draw conclusions if you make two changes at once:

1) leaf evaluation (true measure at the leaves instead of fast approximation from previous nodes)

2) different weighting; if I understand, you value mobility for all pieces in the same way.

If you have computer time available, I suggest you try 1) first with the same weighting you are already using. My intuition is that the 20%-max slow down (with naive code such as mine) will not be visible strength-wise because of better accuracy once in a while. Of course we won't know before we try.

In any case, I think it's easier to try different combination schemes while using full-leaf evaluation (say at least that feature) and only then consider a faster approximation.

Fabien.

I also wonder how other free source code programs or non free source code programs evaluate mobility(I am too lazy to look at the sources if free programs espacially when there is a chance to understand faster by reading replies)

most do pseudo mobility(like fruit or counting moves like you do inmovie).
I did a real mobility calculation in danchess, counting only squares not attacked by a smaller vaued opponent piece. This needs you loop over the squares twice, once collecting attack information,another doing real mobility calcualation for pieces. this didn't bring much difference for me.
I think worrying too much about mobility is bad. I also evaluated control of center and opponent squares. This if i evaluated it high make makes danchess aggresive,sometimes it succeeds sometimes fails.
IMO having some mobility independently for each piece is important. But giving a constant bonus for every other square controled
is not important, becuase this may swallow any other evaluation term you have.
In movie ,do you evaluate mobility independently for each piece or is it
a gross(total number of moves) evaluation?
daniel

Fabien Letouzey wrote:Hi Uri,

It will be hard to draw conclusions if you make two changes at once:

1) leaf evaluation (true measure at the leaves instead of fast approximation from previous nodes)

2) different weighting; if I understand, you value mobility for all pieces in the same way.

If you have computer time available, I suggest you try 1) first with the same weighting you are already using. My intuition is that the 20%-max slow down (with naive code such as mine) will not be visible strength-wise because of better accuracy once in a while. Of course we won't know before we try.

In any case, I think it's easier to try different combination schemes while using full-leaf evaluation (say at least that feature) and only then consider a faster approximation.

Fabien.

In Movei I evaluate mobility only based on the number of moves and the stage of the game(I also added number of captures but I am not sure that it is a good idea).

This is also reply to Daniel who asked if I evaluate mobility independently for each piece.

My evaluation today is not linear and I have a table that give score for every number of moves but I value all pieces in the same way.

My evaluation is a little more complicated than it.
I noticed in the past that older version evaluated mobility too much in the endgame so I simply reduced the mobility evaluation in the endgame by dividing it by 2 or by 4 based on the value of pieces.

This is a solution that I do not like and is result of the fact that my mobility evaluation does not consider the number of pieces unlike fruit's evaluation so case when the side to move has few moves in the endgame gave it a big punishement that is not justified.

A better solution seems to be evaluating mobility of every piece and a side with little number of pieces is not expected to have much mobility so that side will not be punished for it.

Unlike fruit my evaluation of mobility consider pins (for example knight that is pinned has no mobility) and I am not sure if it is a good idea.

Maybe you can also try it in fruit and give no mobility to pieces that are pinned to the king except moves in the pin direction(I do not know how much it is going to cost you in speed).

Uri

If you look at Beowulf, you will see that it can change all of its evaluation parameters from a file.

It can also do a curve fit to EPD positions to try to find approximate optimiums (of course, these tend to be tactical optimums and therefore do not lead to best play).

But an idea like that can help to test ideas and find out which ones are good for your program and which ones are a waste of time.

I have found that things that work very well for one program do not work well for another because of the differences in evaluation and search.

Uri,

Unlike fruit my evaluation of mobility consider pins (for example knight that is pinned has no mobility) and I am not sure if it is a good idea.

If it encourages Movei to pin enemy pieces (and avoid being pinned) then I think that's not a bad idea.

Ross

Uri Blass wrote:I also wonder how other free source code programs or non free source code programs evaluate mobility

I took all mobility code out of Terra except for developing pieces in the opening phase. The idea was to find other evaluation parameters like controlling the center or other spots on the board. Maybe Terra could have been stronger with mobility code but I liked the idea of controlling specific areas of the board instead of all squares.
In Alaric I have about the same idea but I consider to compute mobility with small values as a "backup" when nothing else is found.
/Peter

Fabien Letouzey wrote:Hi Uri,

It will be hard to draw conclusions if you make two changes at once:

1) leaf evaluation (true measure at the leaves instead of fast approximation from previous nodes)

2) different weighting; if I understand, you value mobility for all pieces in the same way.

If you have computer time available, I suggest you try 1) first with the same weighting you are already using. My intuition is that the 20%-max slow down (with naive code such as mine) will not be visible strength-wise because of better accuracy once in a while. Of course we won't know before we try.

In any case, I think it's easier to try different combination schemes while using full-leaf evaluation (say at least that feature) and only then consider a faster approximation.

Fabien.

Hi Fabian
I tried fruit evaluation and it did not work and one of the problems is that
I have pruning that is based also on the mobility evaluation.

I think about using Movei evaluation but the problem is how to evaluate pins.

Today Movei has only list of pinned pieces of the side to move and I am afraid that one problem is that calculating the new pinned pieces is expensive.

I think about improvement in the algorithm.

Today in order to find pinned pieces I start from the king and check every direction(there are possible 8 directions and even in case that some direction is impossible I need to check to find that it is impossible)

I think that it is better to start from the candidate pinning pieces(queen rooks bishops) and have array of candidates that is updated only after king ,queen,rook,bishop moves(I do not need to check if queen that is not in queen direction of the enemy king is pinning queen).

Uri

Hi uri,

I probably did not understand properly what you wanted to say, but with a little addition to mobility code you can also evaluate pins. This the mobility code for a bishop, which also checks whether the bishop is pinning any opponent piece.

rcol -> opponent color
gi.brd -> board

Code: Select all

     // Primitive mobility eval
      for( ; *mvp; mvp++)
      {
    tosq = sq + *mvp;
    while((tosq & 0x88) == 0 && gi.brd[tosq] == NULL) {
       mcount++;
       tosq += *mvp;
    }

    if((tosq & 0x88) == 0)
    {
       tmpscore += pmob[col][gi.brd[tosq]->col][gi.brd[tosq]->pc];
      
       // Possible pin
       if(delta == *mvp && gi.brd[tosq]->col == rcol)
       {
          tmp = gi.brd[tosq]->pc;
          do {
               tosq += *mvp;
          } while((tosq & 0x88) == 0 && gi.brd[tosq] == NULL);
          
          if(tosq == ksq[rcol])
               tmpscore += pin_bonus[tmp];
       }
    }
      }

      tmpscore   += (mcount*2);
      score[col] += tmpscore;


Pallav

Did any one consider to evluate pinning other more valuable pieces
than the king?
I don't expect any improvement from mobility eval, but i expect an improvement on my king safety eval, becaue pinned rooks and pinned queens are major threats there.
daniel

Movei today does not evaluate the pinning piece but only the pinned piece
indirectly.

It is using the number of legal moves for every side and of course a piece that is pinned has less mobility.

It may be better to evaluate the pinning piece because bishop that is pinning a queen is more dangerous then queen that is pinning a queen
but I still want also to use the number of moves.

I do not understand your code.

I guess that
*mvp is a constant because you have better board than my 64 squares board(I can go from h2 to a4 by adding a constant so I cannot do it in that way).
I guess that mcount is the number of noncapture in one direction.

I guess that if((tosq & 0x88) == 0) means if ypu find capture of the piece in the relevant direction.

I guess that later that
gi.brd[tosq]->col means color of tosq when
gi.brd[tosq]->pc means piece type of tosq.

I do not understand what is delta later.

Uri

Hi,

I use a 0x88 board (8x16). I use the standard offset addition method to check mobility in all directions. *mvp is the offset, and for a given direction, *mvp is constant. It is one of the [17, 15, -17, -15] for a bishop.

Following condition checks whether the piece is within the board

Code: Select all

if((tosq & 0x88) == 0)

This checks whether the board sqaure tosq is empty.

Code: Select all

gi.brd[tosq] == NULL


This loop counts the number of possible moves in one direction, and exits only if either the end of board is reached, or a occupied board square is reached.

Code: Select all

while((tosq & 0x88) == 0 && gi.brd[tosq] == NULL) {
       mcount++;
       tosq += *mvp;
    }



If the tosq is still within board, that means that we must have hit an occupied square

Code: Select all

if((tosq & 0x88) == 0)
    {
     
      // Calculate mobility score.
      // gi.brd[tosq]->col is the color of the piece on the position tosq
      // gi.brd[tosq]->pc is the piece on the position tosq on the board.
       tmpscore += pmob[col][gi.brd[tosq]->col][gi.brd[tosq]->pc];
     
       // Now since we have hit an occupied square, it is possible that we
       // may be pinning an opponent piece to the king. To see that I first
       // check that if I go in the current direction, I can reach the king
       // that is delta == *mvp
       // delta is the kings direction
       // I also check that it is an opponent piece.
       // Perhaps I should also check that it is not a pawn.
       // Possible pin
       if(delta == *mvp && gi.brd[tosq]->col == rcol)
       {
          tmp = gi.brd[tosq]->pc;
         
          // Now continue moving in the same direction until we are
          // out of board, or we hit a piece
          do {
               tosq += *mvp;
          } while((tosq & 0x88) == 0 && gi.brd[tosq] == NULL);
         
          // If we hit a piece check whether it is opponent king. If so,
          // give a pinning bonus.
          if(tosq == ksq[rcol])
               tmpscore += pin_bonus[tmp];
       }
    }


I hope I've made it clearer.
Bye,
Pallav

Daniel Shawul wrote:Did any one consider to evluate pinning other more valuable pieces
than the king?
I don't expect any improvement from mobility eval, but i expect an improvement on my king safety eval, becaue pinned rooks and pinned queens are major threats there.
daniel

If you use bitboards, you can calculate all pins and even half-pins for free.

Consider a bishop ray trace or a rook ray trace along some line.

For every one of the [at most] 127 possible distinct bit patters along his ray of attack, you can precompute all the results and store them in a table.

Then, when you place a bishop, rook, or queen on any square, you can use your table to tell you:
1. What open squares it attacks
2. What enemy pieces it attacks
3. What friendly pieces it defends
4. What enemy pieces it pins
4. What enemy squares it x-rays (for pins and revealed attacks)
5. What friendly squares it x-rays (for revealed defenses)
And anything else you like.

Since you can precompute all 127 possibilities and put them in a table, all of the above information is a simple table lookup. You supply the square the attacking piece sits on and the bitmaps of the friendly and enemy chessmen.

It is also useful for incremental evaluation.
(Pick up a piece from the board and remove its influence. Put the piece back down on the board and recompute its influence -- but to do it you have to know how it affects all the other pieces on the board and the above pieces of information tell you most of what you want to know.)

Dann Corbit wrote:If you use bitboards, you can calculate all pins and even half-pins for free.

Consider a bishop ray trace or a rook ray trace along some line.

For every one of the [at most] 127 possible distinct bit patters along his ray of attack, you can precompute all the results and store them in a table.

Dann, it doesn't look that easy to me. Or perhaps, I don't understand it. First of all: Of course, there will be at most 7 squares in each direction, and you can easily create a mask for those squares. You might need up to 8 masks. When you apply thes masks on the opponent bitboard by logical and, you will get a bitmap with possibly pinned men. But long not done yet. On the resulting bitboard, you cannot do any table lookups. So you will need to do some first_bit stuff. You will also need to do the same with the bitboard of the men of stm. You don't want a R to be considered pinning some opponent piece, when an stm pawn is in the way. With the found squares, you would need to do some more logic. You have to look for pieces there, and do some tests. For example, you won't want a Q pinning a B in B direction to a knight (many more cases, especially when you consider the own pieces in between - looks rather difficult to implement without errors). But when you have the squares, you get rather cheap (be another lookup table for example) also mobility, and even X-Ray mobility values for this direction. Doing all this for 8 directions, does not sound really cheap (and certainly not free) to me. Might of course be cheaper, than in a typical array based board layout pinning/mobility routine. One would need to check it, I wouldn't want to guess. Sure, one could have some early exits (for example you might only want to consider directions, that possibly to the opponent K).

Regards,
Dieter

Consider this board (and in particular the rook on E3):
3k2r1/8/8/8/1P6/B1N1R1bp/8/3K3N w - -

Let's think for the moment about the rook's influence on row 3, given:
B1N1R1bp

we can first simplify it to:
x1x1R1xx

The two squares adjacent to the rook are under his direct attack. So a white piece that moves there gets safety and a black piece that moves there gets danger. We call these attacked open squares.
Then we see that something sits on C3 and on G3. These chessmen (whatever they are) are under attack. If they are mine, then I am defending them. If they are his, then I am attacking them. We can know which by one and operation (I do not have to do both ands because of elimination).
The square B3 is shadow attacked. So if the chessman on C3 moves, it gets to be under direct attack.
The chessmen on A3 and H3 are under shadows also. Hence if the pieces between move out of the way, then they are under attack. So I know that there are pin marks for A3 and H3. If the chessmen are mine, then they mean defenses and if they are the opponents then they are attacks.

For a solid row of chessmen, for instance:
3k2r1/5n2/8/8/1P6/BNNBRbbp/8/3K3N w - -
now when we look at: BNNBRbbp
it becomes:
xxxxRxxx
The bitmaps that are interesting for me are:
open square attacks {nothing}:
0000x000
chessmen attacks {one friendly, one enemy piece}:
0001x100
shadow square attacks {nothing}:
0000x000
pins {one friendly, one enemy piece}:
0001x100
shadow chessmen attacks {one friendly, one enemy piece}:
0010x010

It is also not necessary to rotate the chessboard, since you can store the anding maps and the nibble maps and the result maps and everything precomputed.

I can find out about the value of pins by anding with opponent pieces first to see if they are enemies or mine, and then by piece type for king pin, queen pin, rook pin, chessmen pin, pawn pin (stop when you find it).

I do not compute quarter pins or quarter shadows or anything like that but it is also cost free to do it and it might be a good idea.

Is the idea clear?

There is still computation that must be done (not completely free of course). But it saves a lot of work both in evaluation and move ordering.

You can also help the SEE a lot by counting all the attack types against all the squares. Then you know if a square is king safe or queen safe or rook safe, etc. and so you consider the unsafe moves last. Since you have the counts of attacks by each piece type, you have an almost free MVV/LVA kind of a look which also helps to make the SEE smarter.