Author: Uri Blass
Date: 07:04:19 06/20/04
Go up one level in this thread
On June 20, 2004 at 10:02:18, Uri Blass wrote: >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 I can add that I have a lot of global varaibles and arrays. Maybe it is a bad programming and it is better to have functions that get a lot of parameters. 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.