Author: Uri Blass
Date: 08:46:02 06/20/04
Go up one level in this thread
On June 20, 2004 at 11:27:23, Joachim Rang wrote: >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. >> > >do you evaluate mobility only as a whole and not per piece? Yes and I will probably change it in the future. In Fruit it is done >per piece and different pieces have different values? I guess it is better to do it per piece but it will also be more expensive for me because movei always generate moves after making them so I get the number of moves as free information when doing it per piece means that I do not get it for free. Do you apply the above >table additional or is it the only value that goes into mobility? And of course >you won't use that table if you are in check. It is the only value that goes into mobility when the value is divided by 2 or by 4 in the endgame. > >I can see the idea to use such a table which emphasizes the extremes, but have >you ever tested that it improves the strength of Movei? I am not 100% sure about it but I think that it helped when I implemented it. I can send you a version when it is possible to modify this table if you are interested. > >> >>/ >>> >>>>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. > >Backward pawns and isolated pawns are probably the only eval features Fruit has >and Movie does not. Not exactly. Movei also does not evaluate candidate passers. I read your pawn evaluation in the Winboard Forum and it >seems to me quite sophisticated although perhaps not complete. Thanks. I do not consider it as espacially good evaluation. I still did not change it and I tested improvement in the search hopefully latest version is the best movei inspite of the fact that it is slightly slowe in nodes per second because I changed the code to make future change in the evaluation more simple and now I will probably concentrate on evaluation again. 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.