On Tue, 2009-02-17 at 23:29 -0800, David Fotland wrote:
> It's not true that MCTS only goes a few ply. In 19x19 games on 32 CPU
> cores, searching about 3 million play outs per move, Many Faces of Go
> typically goes over 15 ply in the PV in the UCT tree.
That's what I meant when I said a few ply
mputer-go.org [mailto:computer-go-
> boun...@computer-go.org] On Behalf Of George Dahl
> Sent: Tuesday, February 17, 2009 11:23 AM
> To: computer-go
> Subject: Re: [computer-go] static evaluators for tree search
>
> You're right of course. We have a (relatively fast) move pruni
Dailey
> Sent: Tuesday, February 17, 2009 11:58 AM
> To: computer-go
> Subject: RE: [computer-go] static evaluators for tree search
>
> On Tue, 2009-02-17 at 20:04 +0100, dave.de...@planet.nl wrote:
> > A simple alfabeta searcher will only get a few plies deep on 19x19, so
>
GPUs can speed up many types of neural networks by over a factor of 30.
- George
On Tue, Feb 17, 2009 at 8:35 PM, terry mcintyre wrote:
>
> From: "dhillism...@netscape.net"
>
>> Perhaps the biggest problem came from an unexpected quarter. MC playouts
>> are very
From: "dhillism...@netscape.net"
> Perhaps the biggest problem came from an unexpected quarter. MC playouts are
> very fast and neural nets are a bit slow. (I am talking about the forward
> pass, not the off-line training.) In the short time it took to feed a b
First, my code is in no shape for sharing.
Some time back, I experimented with training a neural net to predict ownership
maps from 9x9 board positions. I wasn't looking for a static evaluator; I
wanted something to speed up my MCTS bot. I used my own engine to generate
ownership maps for train
puter-go.org namens Don Dailey
Verzonden: di 17-2-2009 20:57
Aan: computer-go
Onderwerp: RE: [computer-go] static evaluators for tree search
On Tue, 2009-02-17 at 20:04 +0100, dave.de...@planet.nl wrote:
> A simple alfabeta searcher will only get a few plies deep on 19x19, so
> it won'
On Tue, Feb 17, 2009 at 8:23 PM, George Dahl wrote:
> It is very hard for me to figure out how good a given evaluator is (if
> anyone has suggestions for this please let me know) without seeing it
> incorporated into a bot and looking at the bot's performance. There
> is a complicated trade off b
On Tue, 2009-02-17 at 20:04 +0100, dave.de...@planet.nl wrote:
> A simple alfabeta searcher will only get a few plies deep on 19x19, so
> it won't be very useful (unless your static evaluation function is so
> good that it doesn't really need an alfabeta searcher)
I have to say that I believe this
You're right of course. We have a (relatively fast) move pruning
algorithm that can order moves such that about 95% of the time, when
looking at pro games, the pro move will be in the first 50 in the
ordering. About 70% of the time the expert move will be in the top
10. So a few simple tricks li
A simple alfabeta searcher will only get a few plies deep on 19x19, so it won't
be very useful (unless your static evaluation function is so good that it
doesn't really need an alfabeta searcher)
Dave
Van: computer-go-boun...@computer-go.org namens George Dahl
I'd be more than happy to work with you and the other members of your
group. I'm getting close to wrapping up a restructuring of my bot that
allows easily swapping out evaluation methods and search techniques.
As an example, here's the code that does a few basic MC searches:
11 static if (s
12 matches
Mail list logo
