On Mon, 2008-08-11 at 20:39 -0700, David Fotland wrote: > Yes, my alpha-beta searcher still has the big slow evaluation function (about > 50 to 100 evaluations a second). > > When I get some free computer time I'll put it on the 19x19 server. I think > it will be much closer to the 1 cpu uct many faces than to the older version > 11 many faces. > > Uct also has the advantage that it is much easier to use with multiple CPUs. > I know parallel alpha-beta exists, but my evaluation function is not designed > to be thread safe. If I put a big lock around it, there will be almost no > SMP scaling, since almost all the time is in the evaluation, not in the > search.
This is not the case with alpha-beta. With additional processors, alpha-beta always does wasted work, and the more processors the more wasted work. It still always benefits from additional CPU's. - Don > David > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:computer-go- > > [EMAIL PROTECTED] On Behalf Of Don Dailey > > Sent: Monday, August 11, 2008 8:31 PM > > To: computer-go > > Subject: RE: [computer-go] Re: mogo beats pro! > > > > On Mon, 2008-08-11 at 20:10 -0700, David Fotland wrote: > > > Sorry, but I can�t let this statement go past. The go programs in > > the > > > 90s did local search, but not much global search. For example Many > > > Faces did a one ply global search, with a variable depth quiescence > > > search. I added an alpha-beta search to Many Faces last year, and it > > > made a huge improvement in strength. So it is not true that > > > alpha-beta pruning hit a roadblock. > > > > > > > I never doubted alpha-beta but when you say alpha-beta and GO in the > > same sentence, people automatically believe the program is going from > > 99% evaluation to 1% evaluation and 99% stupid. In fact you are still > > spending most of your time evaluating positions. > > > > I'm still not convinced that you can't make a strong alpha beta GO > > program if you have some imagination. It cannot just be a converted > > chess program, it has to be different, but still alpha beta at heart. > > It would have to be extremely selective. > > > > - Don > > > > > > > > > > > > > > > > > For me, the big advantage of UCT/MC is that it eliminates the huge, > > > slow, buggy evaluation function. Simple playouts are much much > > easier > > > to make bug free. Bugs in the evaluation function caused many > > losses, > > > and are almost impossible to eliminate in traditional programs, since > > > the evaluation functions are so complex. > > > > > > > > > > > > David > > > > > > > > > > > > > > > > > > It seems that alpha/beta pruning hit a roadblock a long time ago in > > > go. Now we have MC... which as you increase the number of samples.. > > > you start to get closer to an equivalent alpha/beta. But... there are > > > still huge groups of samples that are not checked... and if you want > > > to somehow prove you have the best move... how will you do it? Will > > > you make the sample size equivalent to the number of possible > > samples? > > > How will you do this practically? You can only state with a certain > > > confidence that you did make the best move and this would be bound by > > > our computational resources. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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/ > _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
