Author: Joachim Rang
Date: 10:58:39 06/20/04
Go up one level in this thread
On June 20, 2004 at 11:46:02, Uri Blass wrote: >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. Yes I am, please send it to: joachim@iwanuschka.de Perhaps I will find a better setting ;-) regards Joachim > >> >>> >>>/ >>>> >>>>>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.