I assume this implies that there arent any open-source basic-UCT bots which utilize the basic eye rule and a simple permute and retry scheme as described by many ppl on the group? When we speak of these sorts of bots playing at about 10kyu I assume what is meant is 10kyu at 9x9 not 19x19.
--- On Wed, 5/14/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Subject: Re: [computer-go] 10k UCT bots > To: computer-go@computer-go.org > Date: Wednesday, May 14, 2008, 10:44 AM > > -----Original Message----- > > From: Jacques Basaldúa <[EMAIL PROTECTED]> > > To: computer-go@computer-go.org > > Sent: Wed, 14 May 2008 6:38 am > > Subject: Re: [computer-go] 10k UCT bots > > > > Don Dailey wrote: > > > > [EMAIL PROTECTED] wrote: > > > >> For those currently coding this up, I think > the most important thing > >>> about this playout algorithm is that it is > >> > *temporary*. You will almost certainly > be replacing it with something different and better > >> > just a little bit down the road. So you > probably don't want to worry > >> > about hair-splitting tweaks except as an > academic exercise. > > > Yes, I agree. Also my hair brained scheme of > pre-generated tables of > > > list traversal orderings was just an academic > exercise as you say. > > > But the problem is that when you do heavy playouts you > have the same > > problem except that the probabilities of the legal > moves are no longer equal. > > The problem doesn't go away but the trade-offs change > considerably. This is an interesting and relevant > discussion, but if I were trying to code up light MC > playouts for the first time, right now, I would be feeling > that this dead-simple algorithm was actually very difficult > and confusing. > > For someone in that position (and only them), my advice is > 1. Implement light playouts first. It's simple; you > will find many bugs that way; it's standardized enough > that other people will understand what you're talking > about; it's a fast way to get a basic bot; it will be a > very handy thing to have as a baseline when you test other > things. > 2. Get it working the standard way before improving it. > It's your baseline that you'll be testing > improvements against. > 3. Make it fast but don't spend excessive effort > optimizing. "Better is the enemy of good > enough." > > - Dave > Hillis_______________________________________________ > 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/
