Author: Dann Corbit
Date: 13:31:06 12/28/05
Go up one level in this thread
On December 28, 2005 at 16:21:54, Walter Faxon wrote: >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: > >...snip... > >>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. >> >>Thanks, >> >>Stuart > > >Mobility is a weak proxy function for "is a good move available?" Even a >program where the static evaluator is a random number generator will play better >than random chess: More moves == more evaluations == a possibly higher random >number. And if nothing else, more pieces == more moves. (A paper has been >published on this.) > >So legal mobility or a proxy thereof (e.g., from attack tables) is a good thing >to have in a static evaluator. But that's at the search horizon. My question >is: Since our static evaluators are imperfect, shouldn't our move choices be >influenced by mobility scores from positions before the horizon? After all, a >move our search said was best may turn out to be a clunker after we've already >committed to the subtree containing it. More mobility means a better chance of >getting out of trouble at that point or before. > >English checkers (draughts) champion Derek Oldbury once wrote to the effect that >forced lines were better compared not by minimal depth but by minimal number of >required moves in the supporting analysis. E.g., a 4-move mate where the losing >side has only one legal move at each turn should be preferred to a 3-move mate >where the loser is mated in different ways in different lines. This implies >that it is even more important to restrict your opponent's mobility than to >increase your own. > >This very "human" -- you might instead say "lazy" -- way of figuring things has >a real point when you cannot be sure how good your evaluator is. (I have a >philosophical problem with what exactly static evaluation "means": Is being up >a queen at six ply better or worse than being up a rook at eight?) This is why >it might be worth considering adding "successive mobility" values (or a proxy >function like pseudo-legal mobility) into the evaluation for actual move >choices. This is the sort of function that is probably better to be asymmetric, >or even have different coefficients at every ply, maybe depending on game stage, >etc. > >I know the objection: The same position may get different scores depending on >which way you get to it, which at the very least screws the transposition table. > That is why successive mobility would have to be backed up separately from the >static evaluations. I don't have an algorithm for this. > >However, even legal mobility is a very weak proxy for "number of reasonable >moves". Other programmers (e.g. Donninger) have remarked that the bigger the >subtree, the more likely the computer will play the move leading to it. So >successive mobility may be getting into play indirectly. > >Early research on computer games considered different ways of searching and >scoring positions based for example on the number of good lines available. Five >ways of winning a rook might be scored as better than one way of winning a >queen, maybe. You'd have to look through some awfully early papers. > >Vasik Rajlich (Rybka) wrote in posts here that he is using (1) unusual search >methods and (2) some older methods (maybe not search) that have been abandoned >by the mainstream CC community. (I'm too lazy to find these posts right now.) > >This whole idea is almost certainly not so hot for tactical suites. Successive >mobility is for when you don't know that you static evaluator is adequate. > >Anyway, something to think about. > >-Walter I think that mobility can tell you some other things too. For instance, high mobility is also an indicator of development. The higher your mobility (and especially the higher your attack count) the better your development is (unless structurally unsound by hanging pieces, etc.).
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.