Ingo, are you sure you already want to bet on one particular technique? :)
I don't believe a score optimisation algorithm like UCT works all that well when behind. I am pretty sure that human players do *not* choose between the top three moves if their values are 40%, 39% and 38%. They will start looking for other moves. I am also not sure the dynamic komi will help, if all it ends up doing is shifting the percentages. Criteria for moves for humans when playing behind may look something like this (subjective assessment): 1. Am I certain of the score after the move, and does it lead to a loss? Discard it, there is no point - unless it is a waiting sequence to prepare for another move, or a move that answers a sente play. 2. Does the move create uncertainty in the score? One does not play for certainty when behind, but for confusion. If I cannot see the result, my opponent probably can't either. 3. Is it a "meltdown" move (i.e. if it goes wrong, I will definitely lose the game)? If so, I might not want to play it unless I am very far behind (> 10 points, and in the middle game) I wonder if anybody has looked at alternating the evaluation function when behind? This is, of course, very difficult without providing a point of attack or discontinuity in its playing style. Perhaps moves with a higher standard deviation could be chosen "once in a while"? Whatever the case may be, I agree that things definitely need to be tried out, against strong players, perhaps on KGS. I gave Zen, an excellent program, 2 stones yesterday night, and sure enough it melted down spectacularly once it was behind :) Christian p.s. I believe handicap games need to be treated differently from situations where one is behind in even games - in the former, one can wait for the opponent's mistakes; in the second, one needs to be proactive. Ingo Althöfer wrote: > Don Dailey wrote: >> I think we should open up to other ideas, not >> just dynamic komi modification. In fact that >> has not proved to be a very fruitful technique >> and I don't understand the fascination with it. > > I was not clear enough in the original posting. > My main point is the following: Currently the > programmers are developing program, and customers > are playing with them. > > But "we" should try to bring creative customers inside > the process of development. Dynamic komi might be > one good early try for this approach. > > You write "that [DyKo] has not proved to be a very > fruitful technique" but you are right only concerning > the rather narrow community of programmers. > (Some) creative customers have lots of time to test strange > things and settings and are willing to do so, provided the > programs are sufficiently "test-friendly". Concerning dynamic > komi I would bet 1:1 that their findings might lead to a > breakthrough. > > Ingo. _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
