I see. It seems that most of Mogo's strength is due to using pattern sequences in the Monte Carlo random games.
I have some questions about your paper... I thought that the Monte Carlo evaluation of a position is done by making many random games from that position, and averaging the win/loss result. So the evaluation of a position would be a number between 0 and 1. I thought several thousand random games would be used for one evaluation. In your paper, say that each UCT leaf node is evaluated by exactly one random game (simulation), with a result of 0 or 1. Is this true? I think you say Mogo does 70,000 random games per move. Does this mean that the UCT tree for a move has 70,000 nodes? When you say 70,000 games per move, does that mean total game move made, or game per node evaluation? How many simulations (random games with patterns) does Mogo do per second? How do you back up values in the UCT tree? There are values in the example tree, but I can't see how they are calculated. Your code says that the value is backed up by sum and negation (line 26, value := -value). But I don't see any negative values in your sample tree, or values greater than one. How do you actually back up values to the root? on page 5 you say that UCB1-TUNED performs better and you use that formula. In the code for the algorithm, you use UCB (line 16). Which is correct? In your paper you show win rates against GnuGo of about 50%, depending on the parameters. The current Mogo beats GnuGo over 90%. What changed? Are you doing more simulations, or do you have more go knowledge in your patterns? Does Mogo have an opening book? Thanks, David > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Sunday, December 31, 2006 11:50 AM > To: computer-go > Subject: Re: [computer-go] UCT vs MC > > > Hello, > > > It looks to me that the strength of the top programs, like Mogo, is > > mostly due to the new UCT search algorithm. > > It depends what you compare to. > If you compare UCT against no tree, this makes a lot of difference. > If you compare UCT to former Remi Coulom's tree search > algorithm, Remi can > answer better than me. He posted a message some months ago, and (if I > remember well) his experiments showed an improvement like > 5-10% against gnugo > comparing to his previous tree search algorithm (which was already an > improvement over other tree search algorithms). > If you compare uniform-MC/UCT against top programs in 9x9, > the difference is > huge. MoGo was using UCT since its first version on CGOS and > was ranked at > 1650. So with UCT and uniform MC you are very far from the > top. UCT alone is > far to be enough. > > > I wonder what would happen if we took a tradional strong > computer-go > > evaluation function and combined it with UCT? > > This should be an interesting experiment. My bet is that it > should not change > a lot the strength. May be this can be worst than alpha-beta. > Perhaps the > gnugo team already tried? > UCT has its advantages and drawbacks, and I think its > performance against > alpha-beta depends on the evaluation function. UCT is > efficient for MC > evaluation function. It is not obvious it is efficient with > "traditional" > evaluation function. I would be very happy to know the result. > > Sylvain > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
