[Computer-go] Scoring a go board.

Woody Folsom woody.folsom at gmail.com
Fri Feb 8 14:08:56 PST 2013


I wrote an AI agent which plays go using a pure Java implementation of
UCT-RAVE for my MS project at Georgia Tech.  With better data structure
optimization I'm relatively sure 10,000s of roll-outs per second, per core,
is not an unreasonable goal.

Chinese scoring is easier than Japanese but I wouldn't go so far as to say
trivial - my initial implementation erroneously counted surrounded dead
groups as points!

I used no heuristics whatsoever in the roll-out policy, and would recommend
getting your MCTS algorithm working with purely random roll-outs first.  I
also did not explicitly code for avoiding filling the player's own eye, but
used Zobrist hashing for super-ko detection and in practice never observed
games run into hundreds of moves.

I would recommend using a board state data structure which encodes groups
(or strings) of stones.  Counting liberties recursively consumed 40% of my
first agent's total run-time, for negligible memory gains.  I did not deal
with culling the state tree at all.

Finally, (3) above is quite difficult.  I am currently attempting to train
a neural network which usefully estimates this value by means of temporal
difference learning.

For more details, feel free to check out my project write-up at
http://woodyfolsom.net/blog/?page_id=43.  I did not manage much original
research since the whole project was done start to finish in one semester,
but it covers the basics of MCTS and computer go.


On Fri, Feb 8, 2013 at 4:41 PM, Don Dailey <dailey.don at gmail.com> wrote:

> Score a go board using Chinese rules - it is trivial.
>
> The basic concept is that you play random moves and (usually) allow no
> passes until there is nothing else to be done.  To prevent eye filling
> there is a fairly simply but very effective rule that prohibits filling a
> one point eye - otherwise the game can last for hundreds of moves.
>
> That is the "basic" concept.   These "playouts" can be greatly improved on
> with some simple rules and patterns.  But there must sitll be some element
> of randomness and getting this right is subject to a lot of research and is
> considered a bit of a black art.
>
> Even a pretty trivial (uniformly random) playout strategy with the rule
> not to fill properly constructed one point eyes can give a reasonable
> evaluation, especially  near the end of the game if you view it
> statistically.   For example if you play 1000 of these "random" playouts
> and black wins 950 of them,  black probably really does have a won game.
>  With a little bit of intelligence added to the playout strategy it can
> become quite good.   MCTS  basically integrates a best first search with
> this concept.
>
> Don
>
>
>
>
> On Fri, Feb 8, 2013 at 4:33 PM, Rémi <remi.de.z at gmail.com> wrote:
>
>> surely at any time during a game of go, three passes can be made and the
>> game can be scored...
>>
>> On 8 February 2013 22:31, Rémi <remi.de.z at gmail.com> wrote:
>>
>>> If there really is a difference between (1) and (2) then I have always
>>> been completely oblivious to it. For your third (3) case I again see not
>>> what the difference is.
>>>
>>>
>>> On 8 February 2013 22:02, Nick Wedd <nick at maproom.co.uk> wrote:
>>>
>>>> On 08/02/2013 20:34, Rémi wrote:
>>>>
>>>>> Hy,
>>>>>
>>>>> There are a lot of interesting papers on UCT and selection strategies
>>>>> ... But it's harder to find information about the more 'pragmatic' side
>>>>> of computer-go.
>>>>>
>>>>> How do you score a go board?
>>>>>
>>>>
>>>> What do you mean by "score a go board"?  I can think of three
>>>> reasonable possibilities.
>>>>
>>>> (1.) Count the score in a game that is over.
>>>>
>>>> (2.) Count the score in a game that is not over, but both players have
>>>> passed because they think it is.
>>>>
>>>> (3.) Count the score in a game that is still being played.
>>>>
>>>> (1) is difficult but practicable. (2) is similar to (1), so long as you
>>>> are not bothered about the result being meaningful, but just want to
>>>> calculate the score as a referee might if asked to score a game in which
>>>> both players have passed prematurely. (3) is as difficult as playing Go
>>>> perfectly.
>>>>
>>>> Nick
>>>>
>>>>
>>>>  What would be a faster algorithm to score a go-board?
>>>>> Could you pre-calculate and accumulate some information early in the
>>>>> game (on every move), knowing you're going to evaluate the board many
>>>>> times?
>>>>> When do you decide to finish/score the game?
>>>>>
>>>>> Also, what are some of the languages used besides C(++)? Does anyone
>>>>> work in something like java or a functional language?
>>>>>
>>>>> Rémi de Zoeten.
>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> Computer-go mailing list
>>>>> Computer-go at dvandva.org
>>>>> http://dvandva.org/cgi-bin/**mailman/listinfo/computer-go<http://dvandva.org/cgi-bin/mailman/listinfo/computer-go>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Nick Wedd
>>>> nick at maproom.co.uk
>>>> ______________________________**_________________
>>>> Computer-go mailing list
>>>> Computer-go at dvandva.org
>>>> http://dvandva.org/cgi-bin/**mailman/listinfo/computer-go<http://dvandva.org/cgi-bin/mailman/listinfo/computer-go>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Computer-go mailing list
>> Computer-go at dvandva.org
>> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>>
>
>
> _______________________________________________
> Computer-go mailing list
> Computer-go at dvandva.org
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20130208/ca9c432c/attachment.html>


More information about the Computer-go mailing list