[Computer-go] I need an off-the-shelf final position live/dead evaluator

Petr Baudis pasky at ucw.cz
Mon Nov 29 16:13:00 PST 2010


On Mon, Nov 29, 2010 at 05:30:07PM -0500, Brian Sheppard wrote:
> Or just use one search of a thousand UCT trials, where we keep track of how
> often a point is black/white at the end of the game. Then assume that stones
> that live with probability < T are dead.

  This is what e.g. Pachi (and I'm sure others) uses to mark dead stones
at the game end when playing on KGS (for n=500, T=0.2).

  (IMO going this way and just quickly whipping up a very simple UCT
implementation and going this way is the easiest choice (you should be
able to find BSD-licenced/public-domain Go-playing infrastructure easily,
or at least 1+ year old Pachi version could be used); but I say that
after already doing it once. :-)

> My guess is that either of these approaches can be made to work to the
> standard that Dave Dyer suggests: usually correct to within a few points.

  If the position is final in the sense used in most human tournaments
(at least in Europe), that is with kos closed etc., I think there's no
reason for a simple flood-fill based scoring to be incorrect at all once
you know the status of all stones. What am I missing?

  (Of course *knowing* the status is difficult, but my point is that
making mistake in few percents of cases is no big deal if you have the
proper user interface to let the human fix that up.)

				Petr "Pasky" Baudis
The true meaning of life is to plant a tree under whose shade
you will never sit.

More information about the Computer-go mailing list