RE: computer-go: Perl Module for next move.

["Fant, Chris" <chris.fant@xxxxxxxxxx>]

Oh, I just noticed one point that I disagree with Heikki on:  I think you have
to count the score as stones+territory, not prisoners+territory, b/c the former
does not penalize you for capturing dead stones.



-----Original Message-----
From: heikki@xxxxxxxxxxxxxxxxx [mailto:heikki@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, June 05, 2001 2:28 PM
To: computer-go@xxxxxxxxxxxxxxxxx
Subject: Re: computer-go: Perl Module for next move.


On Tue, Jun 05, 2001 at 06:59:11PM +0200, Grajdeanu, Adrian wrote:
> I need some method that gives a score and that has the following properties:
> - if the game is clear, the given score is the right one.
> - if the game is ended too soon, the score is an approximate one that makes
> some sense.
> - as the game approaches the state of 'clear' the scoring result is somewhat
> continuous in mathematical sense.

The big problem here is what 'clear' means. In go, it has traditionally
meant that both players are in agreement. Not very useful for neural nets
which may not even have learned the rules...

The only 'clear' that I find useful in such context is a "chinese" one,
where every stone still on board is counted as alive, and every empty point
that can connect to both black and white stones is counted as neutral.

Note that enforcing this may make games longer, but does not have to change
the score, nor the optimal play. Depending how you count (stones on board or
prisoners in addition to clearly defined territories), you may have to award
a point for each pass.

I think implementing this simple scoring from the scratch would be easier
than getting fully reliable "ordinary" scoring from GnuGo, mostly because
gnuGo's scoring is aimed at scoring the game at a point when human players
can see the end, wish not to spend time playing on, and want GnuGo to come
with a decent score.

You also state you need GnuGo for enumerating all legal moves. Again, a
simple go board manager that enforces a super-ko rule (no position may be
repeated) whould be fairly simple thing to code. You might probably not want
to allow suicides (also trivial to code), as they can produce some
pathologically long games, and have (practically) no relevance, even where
allowed (chinese rules).


I remain quite sceptical about the possibility of such a network ever
learning to deal with even simple tactical considerations, like reading a
ladder. But I wish you best of luck, and hope you'll keep us posted.


- Heikki

-- 
Heikki Levanto  LSD - Levanto Software Development   <heikki@xxxxxxxxxxxxxxxxx>