[Top][All Lists]

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

Re: [gnugo-devel] GUI and Moyo

From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] GUI and Moyo
Date: Wed, 08 Jun 2005 20:18:00 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.9) MULE/5.0 (SAKAKI)

Alexander wrote:
> I have created a very configurable GUI for GNU Go, using Python/Pygame/SDL.


> In addition, I've created an algorithm that finds moves that are
> good for increasing the moyo. My Python-prototype beats the current
> version of GNU Go, and I'm in the process of rewriting it in C.

Like Paul I'm interested in how you have implemented this so far and
how you have measured the improvement.

> Is any of this of interest to you?

It surely is.

> What do you usually do in order to check that an improvement in
> gameplay is an actual improvement?

I'd like to add some things to Paul's answer.

The first, somewhat implicit, step is to visually inspect the patch
and see how much sense it makes. If it makes perfect sense it's
sufficient that the regressions don't indicate some serious oversight.
If it doesn't make sense at all it's almost doomed unless there are
indications that it does give a substantial increase in strength, in
which case the making-sense-meter may need a recalibration or the
change can be modified to something that both makes sense and
increases strength.

In most cases the visual inspection will only give the result that the
change is reasonable and then it's all about evaluating it as well as
possible. The most important tool is the regression testing.
Unfortunately the regression results are somewhat noisy so the
unexpected results generally need to be investigated in some detail to
see whether they really were caused by the considered change.

If the regression testing is inconclusive (the visual inspection plays
a role in determining this) the next step is to test it in real games.
This can be done against the unpatched GNU Go as Paul suggests, but
better is to use games against other players, preferrably on a server
(KGS is currently most popular).

Another technique, which may be useful for moyo moves, is to replay a
number of sample games and investigate the moves where the patched
version plays differently.

A second aspect of testing is to measure changes in speed. This is
primarily done by comparing node counters for the regressions. While
this doesn't tell the whole story it's simple and easily measured and
can be obtained as a biproduct to the regression results.

Please ask if you haven't found out how to do some of these things.
I'm not sure how well they are described in the documentation.

> Am I duplicating work?

There are a number of more or less useful GUIs around, but depending
on what exactly yours do it may very well be complementary to other

Nobody has worked on algorithms to find moyo-increasing moves for a
long time so there duplication is very unlikely.


reply via email to

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