mobility or piece square table evaluation

[Uri Blass]

Chrilly Donninger posted in the chess computer club that he removed piece square table from hydra so I am interested to know what other programmers do.

In order not to say that it is dependent on the piece I ask about bishops.

I have both of them but I think that it is possible that it may be better to increase my mobility evaluation and to get rid of piece square table or at least reduce the difference in piece square table as compensation.

[smcracraft]

Chrilly Donninger posted in the chess computer club that he removed piece square table from hydra so I am interested to know what other programmers do.

In order not to say that it is dependent on the piece I ask about bishops.

I have both of them but I think that it is possible that it may be better to increase my mobility evaluation and to get rid of piece square table or at least reduce the difference in piece square table as compensation.

Tropism at terminal nodes was substituted before pc/sq tables came
along as "Poor Man's Mobility".

As always, I would suggest creating the two in your program with
#ifdef's and testing against all the testsuites, humans, computers
you wish to and then choose the one you feel does better.

Test-test-test.

Stuart

[H.G.Muller]

I have no experience with mobility, I always worked with piece-square tables. My mistrust against mobility as a valuable evaluation characteristic was motivated by poor performance of the first commercial chess compuers like Chess-Chalenger 10, that seemed to be due to overemphasis of mobility: those machines could not wait to position their Queen in the center, and tenaciously kept it there until the very last square that was safe for it was attacked. If he did it cleverly the opponent could more or less develop all his pieces while CC was only doing Queen moves!

So if people use mobility nowadays, do they weight the contribution of various pieces differently to prevent such behavior? Or is the larger search depth that one nowady achieves enough to make the engine see the futility of such behavior?

I once philosophised about how one could combine advantages of piece-square tables with mobility count. I came up with the following idea (that I did not try yet): start making a table that assigns an importance to every square of the board, depending on the pawn structure (e.g. in a locked pawn structure the holes in it would be of large strategic importance). Then add the values of all the squares that are covered by a pieces, but apply a correction factor based on the value of the lightest piece that covers it. So an important field covered by a Queen is worth less then when it is covered by a pawn. But if it is covered by a Queen and a Pawn, this is nearly as good as when it is covered by 2 pawns, because the most important result of the double coverage is that the pawn will be defended whenver he takes what comes into the square. To make this scheme even more flexible one could set a certain bit for each type of piece that covers a square, and use the resulting number as an index in a table that tells you the correction factor that such a combination of pieces should apply to the square value.

Are any such complicated scoring methods in use?

[Alessandro Scotti]

I have no experience with mobility, I always worked with piece-square tables. My mistrust against mobility as a valuable evaluation characteristic was motivated by poor performance of the first commercial chess compuers like Chess-Chalenger 10, that seemed to be due to overemphasis of mobility...

Hi H.G.,
isn't that a 30 years old software and hardware?!? Today mobility is considered an important factor in the right engine. Fruit has it, and not long ago Anthony Cozzie talked about Fruit and his own Zappa as "mobility-based" engines...
In Kiwi mobility did not buy much strenght, but it considerably changed the play style and made it more "active" and "interesting", at least from my point of view.

[H.G.Muller]

Yes Allesandro, I started chess programming a long, long time ago, but then I held a 20-year long pause...

But what I was most curious about: do these engines (and yours) do pure move counting, without weighting the moves of different pieces differently?

[Uri Blass]

Yes Allesandro, I started chess programming a long, long time ago, but then I held a 20-year long pause...

But what I was most curious about: do these engines (and yours) do pure move counting, without weighting the moves of different pieces differently?

In my case I do not weight the moves differently but I have piece square table for bishops and knights that help to prevent queen moves in the opening because developing other pieces is more important.

I tried changing it to weight pieces differently(more similiar to fruit) but so far with no success and for some reason the program seemed to play worse when I tried to do it(I only tested it in the noomen match for fixed depth of 9 plies and the result was not significant but based on my memory I stopped after 60 or 70 games when the previous version leaded with difference of 3 games).

Note that my evaluation is not linear by the number of moves and I have a table to give a score for every number of moves.

one possible reason that more mobility for bishops and knights seems not to be better for me is the fact that I encourage centralizing them by piece square table so more mobility for bishop and knight may be too much so it may be better only to reduce the difference in the piece square table together with increasing mobility for bishop and knight.

Uri

[Pradu]

I use mobility in eval and dynamically generated PSTs for ordering them.

Of course mobility eval sucks in the opening (because of horizon effect only, not a fault in the eval), but it is very accurate in the middle game.

[Uri Blass]

I use mobility in eval and dynamically generated PSTs for ordering them.

Of course mobility eval sucks in the opening (because of horizon effect only, not a fault in the eval), but it is very accurate in the middle game.

The idea of an evaluation is that you cannot see everything(otherwise only material evaluation is enough).

The claim that evaluation is bad because of horizon effect does not convince me.

If the evaluation sucks in the opening it means that it simply is not good for the opening and not that there is no fault in the evaluation.

Uri

[Alessandro Scotti]

But what I was most curious about: do these engines (and yours) do pure move counting, without weighting the moves of different pieces differently?

For each piece:
- get number of moves;
- subtract "expected" number of moves;
- multiply for a weight that depends on the piece itself and the game stage.

This is all stuff I learned from Fruit. Before that, I did mobility only for bishops and in some cases for rooks (which IIRC is the approach used by Crafty) using a table to translate number of moves into a score, and without considering the game stage.

[Uri Blass]

Some more notes about my mobility evaluation

In my case I divide the score of mobility by 2 in case that the value of pieces is at most 20 and I divide it by 4 in case that the value of pieces is at most 5.

I found that it was productive and I did it before fruit so I did not think about the idea of stages.

Note that I have also a table for number of captures and if one side has many captures I give it a bonus.

One note about the idea to substract expected number of moves in fruit.

I think that subtracting "expected" number of moves like fruit does is the same as reducing the value of the piece.

Correct me if I miss something but I do not see a difference.

Uri

[Tord Romstad]

So if people use mobility nowadays, do they weight the contribution of various pieces differently to prevent such behavior?

Yes, I am pretty sure everybody does this. In general, the minor pieces are weighted higher than the major pieces. The queen is often omitted completely (personally I do evaluate queen mobility, but I have never been able to prove that it works). Many programmers also use different weights depending on the phase of the game.

It is also quite common to use non-linear scales when evaluating mobility. When computing the mobility bonus for a piece, you don't just take the number of squares it attacks and multiply it with some constant, but instead use the number as an index to a small lookup table.

Tord

[Uri Blass]

So if people use mobility nowadays, do they weight the contribution of various pieces differently to prevent such behavior?

Yes, I am pretty sure everybody does this. In general, the minor pieces are weighted higher than the major pieces. The queen is often omitted completely (personally I do evaluate queen mobility, but I have never been able to prove that it works). Many programmers also use different weights depending on the phase of the game.

It is also quite common to use non-linear scales when evaluating mobility. When computing the mobility bonus for a piece, you don't just take the number of squares it attacks and multiply it with some constant, but instead use the number as an index to a small lookup table.

Tord

non linear scales is the only thing that I use now in evaluating mobility
I do not use different weights for different pieces and I evaluate mobility also for king and pawns.

I am going to change to weigh higher the major pieces if I find something that works for me.

The reason that I divide the evaluation when the number of pieces is small is because I consider very small number of moves as very bad.

The history reason for doing it is because of a game in WBEC that showed me the problem.

When I think about it
I count king and pawns moves so dividing the evaluation in endgames really help to get closer to the real value of mobility of other programs that do not count king moves and pawn moves but I am sure that it is not the best solution.

[Event "WBEC3_3rdDivision"]
[Site "DUAL-P3-933"]
[Date "2002.09.03"]
[Round "16.2"]
[White "Movei 0.0.72h"]
[Black "SseChess 2.04.5"]
[Result "1/2-1/2"]
[PlyCount "190"]
[EventDate "2002.??.??"]
[TimeControl "40/2400:0"]

1. d4 d5 2. Nc3 Nf6 3. Bg5 Bf5 4. e3 Nbd7 5. Bd3 Bxd3 6. Qxd3 e6 7. Nf3 Be7 8.
Bxf6 Bxf6 9. e4 c6 10. O-O O-O 11. Rfe1 Nb6 12. a4 Rc8 13. e5 Be7 14. b3 c5 15.
a5 Nd7 16. Qd2 Nb8 17. dxc5 Bxc5 18. Na4 Be7 19. Nb2 Na6 20. Nd3 Qc7 21. Nd4
Rfd8 22. Ra2 h6 23. g4 Nc5 24. Nxc5 Bxc5 25. f3 Bxd4+ 26. Qxd4 Qc3 27. Qf2 Rc6
28. Re3 Qd4 29. Re1 Qxf2+ 30. Kxf2 Rdc8 31. Re2 Kh8 32. f4 Kg8 33. Ke3 Rc3+ 34.
Kd2 Rf3 35. Ra4 Rc6 36. g5 hxg5 37. fxg5 Rh3 38. Rf2 Rhc3 39. Ra2 R3c5 40. h4
Ra6 41. b4 Rb5 42. c3 Rc6 43. Kd3 Rc4 44. h5 Rg4 45. Rg2 Re4 46. Rae2 Rh4 47.
Rh2 Rg4 48. Reg2 Re4 49. h6 Rxe5 50. Rf2 Rf5 51. Rxf5 exf5 52. Rf2 gxh6 53.
gxh6 Kh7 54. Rxf5 Kxh6 55. Rxf7 Kg6 56. Rf8 Kg7 57. Rf5 Kg6 58. Re5 Kf6 59. Kd4
a6 60. Rxd5 Rxd5+ 61. Kxd5 Ke7 62. c4 Kd7 63. b5 axb5 64. cxb5 Kc7 65. b6+ Kd7
66. Kc5 Kc8 67. Kd6 Kb8 68. Kd7 Ka8 69. Ke6 Kb8 70. Kf6 Kc8 71. Ke7 Kb8 72. Kd8
Ka8 73. Kd7 Kb8 74. Kd6 Kc8 75. Kc5 Kd7 76. Kb5 Kc8 77. Kb4 Kb8 78. Kb3 Kc8 79.
Ka4 Kb8 80. Kb4 Kc8 81. Kb3 Kd7 82. Ka4 Kc8 83. Kb5 Kb8 84. a6 bxa6+ 85. Kxa6
Ka8 86. Ka5 Kb8 87. Kb4 Kb7 88. Kb5 Kb8 89. Kc6 Kc8 90. Kd5 Kb7 91. Kc5 Kb8 92.
Kb5 Kb7 93. Ka5 Kb8 94. Ka4 Kb7 95. Kb3 Kxb6 {Insufficient mating material}
1/2-1/2


Movei missed a win by 63.c5 and when I analyzed the game I found that movei had enough search depth to see that 63.c5 wins a pawn but evaluated that it is better to win some mobility by pushing the black king into the corner by 63.b5 when black has later only a single move(Ka8-b8) that was considered by movei as very bad(only legal king moves are counted so Ka8-a7 of course was not counted).

Uri

[Stan Arts]

In my eval at the beginning I have to loop over the board to retrieve lots of information, so I encounter every piece separate, and then do whatever mobility for that piece I can do without knowing other information yet. If I want to count squares I then count pseudo-legal squares the piece can go. (different then my regular move-generation, just counting squares is much faster for me.)

For bishops I count possible pseudo squares, with some extra mobility very near the bishop. (how my bishop mobility started out when i didn't use full mobility yet.) Combined with gamefase and kingsafety (like wanting a bishop into a g2/b7 or b2/b7 fianc-hole if there and so on) dependant knowledge but no PST.

For rooks I count pseudo-squares, but also use a PST for prefering 7th and other opponent lines and central lines into one computation. Other then that specific things like with the bishops.

Knights I count pseudo-squares as well..but I think such mobility for the knights isn't very helpfull and want to find something better. So far I haven't. Also use a PST for centralisation and to avoid some bad squares.

When experimenting with mobility I started out using queen-mobility, but made the mobility-score very small. It still caused stupid queendevelopment moves, so i removed it completely, seems best.
I do have other queen-knowledge like not to put it on c1,b1,a1,a2,a3 , f1,g1,h1,h2,h3 squares with white, etc. I would like to have smart knowledge about trapped queen instead of mobility, but haven't managed to come up with anything yet.

And I have a sort of pawn-mobility. No idea if this is helpfull or not, but it seems ok. Atleast it doesn't really cost me any speed.

No kingmobility.. that is a bad idea imho. (except in the endgame.) Another reason why having non-piece-specific mobility is not very good imho.

Other then that safe-squares (atleast in the way of smaller pieces capturing bigger ones) is probably better then pseudo-legal, but it's hard to decide anyway because of tactics and so pseudo-legal is fine for me. (other things to worry about for my program (getting 5 extra ply.. ) )

Stan