gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnugo-devel] Re: global lookahead, distributed go


From: ab
Subject: [gnugo-devel] Re: global lookahead, distributed go
Date: Wed, 7 Apr 2004 03:48:54 +0200

Hi!

David G Doshay wrote:
>So far lookahead-GnuGo seem to be 3 or 4 stones stronger than regular Gnu
Go. There are still a number of issues with
> this approach we are trying to work out.
very interesting...
"3 or 4 stones" is already really a lot!

I think this effectively add a kind of search that is not currently
implemented in gnugo and could (does?) reveal some strategic effects of
moves instead of just tactical things. Of course really big surprises won't
be possible, because the selection of the next move is limited to gnugo's
top10 moves. Is it an advantage to broaden the selection on the first move
(add moves that do only sometimes work) and search only till it becomes
apparent that they don't work?

[...]
>>is there something (or the idea for something) like a lookahead for fuseki
moves (whole board)
>We are working on problems like this, although in a slightly different way
than normal for Gnu Go
>
>We are doing whole board lookahead of several of the highest rated Gnu Go
moves, as well as if we
>were to play on the one or two highest rated moves Gnu Go would choose to
play for "them" (if we were to pass).
>We do this on a cluster, so the width of the search is parallel, but
because the sequence is serial we cannot speed
> up the depth of the search. Our algorithm will also branch in the
lookahead sequences if we have available cpus due
>to few lookahead paths.
>
>We are trying lookahead depths between 4 and 16 moves. At the end of the
lookahead sequence we do an evaluation
>of the board with Gnu Go's influence function. We do a linear combination
of the original move value and the influence
>calculated at the end to select the move that we play.

How many moves do you generate (inner nodes of tree) typically? how many
leafs do you evaluate typically?

---
Are you using unmodified versions of gnugo?
With a small appropriate client this would perhaps be an idea for a
distributed go project?

Except for the exploration (what you're already doing) of the limits of this
 approach (serious goal), it could also be fun for the
users to see what is beeing calculated locally and what the resulting move
is with all calculations considered.

* traffic would be low (send 1 Position per some seconds+the result, a
number of moves)
* users could connect/disconnect whenever they want to
* run 2 (or 3 games) simultaneous and let the users vote for the next move
on one board while another board is being evaluated
(at least while no server initiated tests are running)
* in competition to a possible(?) solving >=6x6-Go distributed-project

I think an interesting (not just) fun project..


P.S.: Could you possibly post some sgf-files of some calculated games?


ciao,
 ab





reply via email to

[Prev in Thread] Current Thread [Next in Thread]