Author: Uri Blass
Date: 07:02:18 06/20/04
Go up one level in this thread
On June 20, 2004 at 08:22:37, Joachim Rang wrote: >On June 20, 2004 at 07:05:30, Uri Blass wrote: > >>On June 20, 2004 at 05:14:26, Joachim Rang wrote: >> >>>On June 20, 2004 at 00:12:22, Uri Blass wrote: >>> >>>>Is it correct that fruit evaluates mobility as the same for all directions? >>>> >>>>If I understand Fruit1.5's code correctly I do not see difference between >>>>mobility of rook in files and in ranks. >>>> >>>>The mobility score for rook seems to be the number of square that it can goto >>>>minus 7. >>>> >>>>Uri >>> >>>That is how Fabien explained it to me, so I think you are correct. One >>>specialtity is that Fruit counts all squares where the piece can go plus the >>>enemy pieces which are attacked. It is actually possible to give these two >>>concepts different weights but so far it does not seem to increase the strength. >>> >>>regards Joachim >> >>This is similiar to the way public movei already calculates mobility by the >>number of the legal moves and it has no concept of open files(mobility score for >>fruit can also be calculated based on the number of the legal moves of pieces >>when the only difference is that you need to know the number of moves of every >>piece). >> > >right, Fabien wanted more flexibility, to give different values for square >control and attacking pieces, but how it is tuned right now, it is like counting >legal moves. > >>I thought that I may need to change it and to define mobility forward and >>mobility backward and I saw few cases when public movei suffered from the fact >>that it did not evaluate open files. >> >>Latest movei give static bonus for open files for rooks and the same panelty for >>closed file when open files are defined the same way as they are defined in >>fruit1.0 based on Fabian's post but I am also not sure if it increase the >>strength(it beated previous version in the nunn match but scored similiar to >>movei00_8_198 in Heinz tournament). >> >>There are also some other changes when I am not sure that they increase the >>strength. >> >>I wonder if fruit1.5 evaluates open files directly seperate from mobility. >>I did not find it in the evaluation but maybe I did not look well enough. >> > >The boolean mobility expressions, like bishop on closed diagonals, rook on >closed file and queen on closed files and diagonals where removed once mobility >was tuned, because it seemed that mobility does a better job. > >If Fabien has nothing hidden from me, Fruit does not evaluates open files >directly seperate from mobility. There are still some (piece placement) >expressions beside pst and mobility but they are constant bonus not counting the >dynamic features of a position. > >>Another question is if it evaluates knight outposts. >> > >No. The PSTs are constructed in a way, that advancing knights is encouraged but >there is no evaluation whether an advanced knight is an outpost or not. > >>One suggestion that may help fruit is to have some mobility table with the idea >>that very negative mobility is worse than what is suggested by the mobility >>score. >> > >Can you explain what do you mean by that? Perhaps you can give an example. Yes I have the following mobility table -92 -86 -80 -74 -68 -62 -56 -50 -44 -38 -32 -26 -20 -14 -8 -2 4 10 15 20 25 30 34 38 42 46 49 52 55 58 60 62 64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 104 106 108 110 112 114 116 118 120 122 124 126 128 130 132 134 136 138 140 142 144 146 148 150 152 154 156 158 160 162 164 166 168 170 172 174 176 178 180 182 184 186 188 190 192 194 196 198 200 202 204 206 208 210 212 214 216 218 220 222 224 226 28 230 232 234 236 238 240 242 244 246 248 250 252 254 256 258 260 262 264 266 268 270 272 274 276 278 280 282 284 286 288 290 292 294 296 298 300 302 304 306 308 310 312 314 316 318 320 322 324 326 328 330 332 334 336 338 340 342 344 346 348 350 352 354 356 358 360 362 364 366 368 370 372 374 376 378 380 382 384 386 388 390 392 394 396 398 400 402 404 406 408 410 412 414 416 418 420 422 424 426 428 430 432 434 436 438 score for 0 legal moves is not important because I evaluate mate or stalemate. score for 1 legal move is -86 score for 2 legal moves is -80 and it continue in that way. You can see that the difference in mobility between 9 and 10 legal moves is bigger than the difference in mobility between 29 and 30 legal moves and the idea is that I want to punish a side with small number of legal moves more than what the mobility value suggest. Based on the same idea I think that fruit may translate bad mobility to even more bad values. / > >>I do it in movei. >> >>I do not consider it as something that is hard to find by yourself because >>it is similiar to the idea that king safety is not something linear but maybe >>other people do not use it. >>Maybe it is one of the reasons that movei is considered by some testers to have >>good mobility evaluation. >> >>My solution to the problem of endgame(very bad mobility may be not so bad is >>simply to divide the score by 2 or 4 based on the number of pieces but I think >>that the substraction idea in fruit may be better). >> > >What substraction idea? Knight and Bishop mobility is weighted the same in >opening and endgame but rook and queen mobility is weighted higher in the >endgame. op[me] += (mob - 4) * KnightMobOpening; // was 6 eg[me] += (mob - 4) * KnightMobEndgame; // was 6 The -4 is what I call substraction idea. I simply divided the score in the endgame in order to reduce the mobility score in endgames. > > >>Uri > > >I want to make a general comment on your program: On what do you occasionally >write here and in the winboardforum it seems that you have quite sophistated >evaluation terms, much more detailed and sophisticated than Fruit. I am not sure about it. Movei has some king safety evaluation that fruit does not have but on the other hand it has not sophisticated pawn structure evaluation and it does not evaluates weak pawns except isolated pawns that are not passed pawns and it does not evaluate backward pawns. I think that the secret for movei's good result is some search tricks. I can thank Fabian for his boolean features. I recently tested some search changes and it seems to me that the boolean features is a good idea to make my code more readable and continue to improve the pruning. I have some code that is if (eval>beta+margin(depth)) return beta and I believe that this code can be improved. It had some complex if conditions and I translated it by first calculating some boolean conditions and later using the boolean conditions to calculate margin(depth). I hope that I improved it in my latest version. It scored better in my tests against a previous version but of course it does not prove that it is better. I believe that it can be improved significantly but I also believe that my function to calculate margin(depth) is significantly better than most engines at similiar strength. previous version had complex if and not a single function and having a function when I define boolean conditions was inspired from fruit that does the same with pawn structure and first calculate for every pawn boolean conditions. Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.