Author: Uri Blass
Date: 11:36:11 06/20/04
Go up one level in this thread
On June 20, 2004 at 13:58:39, Joachim Rang wrote: >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 Sent. There are a lot of modifyable parameters so I am sure that it is possible to find a better setting. Note that latest Movei supports knight outposts but the default value for them is 0 and I did not test changing it. 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.