Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Mobility in Chess Evaluation Function at terminal-nodes

Author: Dann Corbit

Date: 09:37:35 12/28/05

Go up one level in this thread


On December 28, 2005 at 12:31:13, Stuart Cracraft wrote:

>Hi - I ran a small experiment last night.
>
>Many people don't put mobility into their evaluation function because of the
>heavy expense of a move-gen at the terminal node.
>
>But I advocate to them that they should do experiments to convince themselves
>that the result on their test suites is not much worse and the program plays
>much better for the positional gain they get from mobility - as you know, J.
>Schaefer's experiments showed mobility as the #2 term corresponding to game
>result, after material, with king safety being third.)
>
>I added mobility to my evaluation function (the difference between a genmv()
>for the side on move less the same for the side not on move, without sorting
>the resulting movelist and without scoring it with SEE, to save at least
>some time over the standard genmv() I do.
>
>I put that under a compile time flag and added a command-line parameter for how
>much of a bonus to give the mobility. For example, 20 moves for white 10 moves
>for black equals 10. A mobility bonus of 1 would make that equal to +10 for
>white. Of 2, would make it +20. etc.
>
>Then I ran an overnight run of the mobility bonus multipliers between
>1 and 18 inclusive from a calling script that varied the mobility
>bonus and got this for a test suite:
>
>$ egrep '/300 ha=' LOG*
>- 7.52/20.62 84% 253/300 ha=28 1190.91 167107696 557026/4/140319
>240474/382329/1327880/5513157/59240532/608225/0/1285006
>- 7.38/20.12 83% 251/300 ha=29 1195.00 138130432 460435/4/115590
>210266/323338/1162457/4534280/49317756/499882/0/1049585
>- 7.49/20.55 85% 257/300 ha=28 1192.64 164995520 549985/4/138345
>234089/379838/1332107/5477857/58841816/599694/0/1302738
>- 7.51/20.49 86% 259/300 ha=28 1189.92 166282704 554276/4/139743
>238989/381854/1520395/5548212/59362600/610289/0/1331883
>- 7.51/20.54 84% 253/300 ha=27 1190.88 166756768 555856/4/140028
>241290/384370/1373972/5559856/59666496/611841/0/1351587
>- 7.50/20.56 84% 254/300 ha=27 1189.29 166566272 555221/4/140056
>239925/382465/1419681/5577634/59651836/609615/0/1342258
>- 7.50/20.43 84% 253/300 ha=28 1190.82 166441136 554804/4/139770
>236177/381435/1503069/5576327/59794100/610294/0/1333488
>- 7.49/20.38 84% 253/300 ha=28 1191.24 166571712 555239/4/139830
>234648/382605/1504945/5580403/59990952/612993/0/1334129
>- 7.49/20.40 84% 253/300 ha=28 1189.92 165183184 550611/4/138819
>235536/380277/1499795/5543228/59542420/609608/0/1348145
>- 7.49/20.35 84% 253/300 ha=28 1189.45 166587152 555291/4/140054
>234568/385026/1562216/5581740/60182484/610646/0/1359775
>- 7.48/20.36 85% 255/300 ha=28 1190.17 166913296 556378/4/140243
>235821/385011/1485762/5581325/60218688/608177/0/1349138
>- 7.49/20.36 85% 255/300 ha=27 1190.30 166767520 555892/4/140106
>239741/384832/1438800/5581739/60256548/611122/0/1368462
>- 7.48/20.34 84% 253/300 ha=27 1189.90 166946240 556487/4/140303
>239484/387104/1461428/5586449/60395188/609393/0/1370506
>- 7.48/20.34 85% 257/300 ha=28 1190.07 166473936 554913/4/139886
>237929/385998/1391489/5572576/60288720/606761/0/1356362
>- 7.49/20.32 85% 255/300 ha=28 1190.03 165876304 552921/4/139388
>235108/383606/1401601/5542329/60103648/603794/0/1347724
>- 7.47/20.29 85% 256/300 ha=27 1191.94 166318352 554395/4/139535
>234834/385503/1413928/5590048/60356304/612689/0/1349921
>- 7.48/20.30 84% 254/300 ha=27 1191.20 167219648 557399/4/140379
>238313/383320/1392053/5608731/60544580/613259/0/1375934
>- 7.49/20.23 85% 256/300 ha=27 1191.18 166792800 555976/4/140024
>239082/383047/1345213/5596612/60508488/611597/0/1370023
>
>Stuart Cracraft@CRACRAFT ~/src/td
>
>Each line represents a result at WAC. The best result came at mob=4 (i.e.
>the 4th line above) but the results are not so far different as to be a grave
>concern. The other interesting thing is that the program without any mobility
>function scores 262/300. So the score of bonus=4 which is the 4th line above is
>about the same (only a 1% difference.) And all of these are within an small
>enough difference that the whole result is in question. Nothing is clearly
>better.
>
>I will expand the test tonight to search for mobility bonus multipliers of 1, 5,
>10, 15, 20, 25, etc.
>
>My program is milli-pawn based so the result argues for a mobility bonus
>multiplier of 4 with typical pc/sq terms typically ranging from single digit to
>no more than 40. A mobility difference of 10 between the two sides, with a
>multiplier of 4 would be equal to approximately the maximum positional bonus as
>currently set.
>
>I know that many will object to this as suite-based cherry-picking instead of
>ICC-based play against real opponents. I do not want them to see it as
>either-or but a combination of the two with only one part semi-completed.
>
>Others will see a score of 262/300 on WAC and ridicule the result as "immature"
>but for them I would encourage them to publish in reply their own experience
>with mobility and avoid the critique-without-improvement approach.

Fruit spends a great deal of energy calculating mobility.  Considering Fruit's
success, I suspect that you are not barking up the wrong tree.

If you have a bitboard program, there is a way to get really cheap mobility
scores.



This page took 0.01 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.