gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] moyo reduction


From: Daniel Bump
Subject: Re: [gnugo-devel] moyo reduction
Date: Thu, 6 Dec 2001 06:34:18 -0800

Arend wrote:

> I have been deliberating a while on GNU Go's moyo weakness, and I think
> I have some more or less concrete suggestions how to improve it. What
> I am writing is rather focussed on the reduction of enemy moyos. I guess
> this is more urgent; I think the successes of some other programs via
> building moyos is rather due to their opponents letting them finish it.

I agree with this statement! Go4++ comes to mind. But Many Faces of Go
and Wulu are both much better than GNU Go at making moyos. Interestingly
Many Faces does not have a separate moyo module. (We don't know much
about the internals of other top programs besides Many Faces. We know
what we can about Many Faces because David Fotland is willing to
discuss his program.)

But to take Go4++ as an example, it is very effective at building
moyos and consolidating territory in computer play or against weak
humans. But its moyo building is not fundamentally sound.

> However, parts of what I would like to do is very delicate in that it
> could break a lot of tuning, so I would like to invite some discussion
> on the matters.

Generally there is a way of handling changes like that. You 
make them optional, for example currently we have a configure
option --enable-experimental-semeai and a runtime option
--experimental_semeai. During the development of the module
it is turned off by default so others aren't aware of the
brokenness. Then when it is somewhat debugged, it gets turned on
by default, but can still be turned off. Finally, when the
confidence level is high enough, it can be turned on by
default.

Since your scheme is tuning based, for a time we would support
two distinct influence tunings, the current ones and an experimental
one which would be toggled by a parameter. If the experiment is
quickly successful this could be taken down quickly. On the other
hand if it takes time to get it working, no one will be inconvenienced.

> So, once again I add more to the to-do-list than to the actual code :-),
> but I feel these ideas could benefit from some further deliberation
> while I am still working on the issues I raised with the strategic
> effect. I would be happy about any comment!

I think this is very likely to be a very good project and I'd
encourage you to do it. The details might get somewhat changed from
your statement as you develop it but is a good idea to formulate
your ideas out in advance as you have done.

Dan








reply via email to

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