gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] marginal eye space incorrect


From: Gunnar Farneback
Subject: Re: [gnugo-devel] marginal eye space incorrect
Date: Sun, 09 Dec 2001 20:06:35 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Trevor wrote:
> I believe that A6 should not be considered marginal in this
> position, but that A5 should be.

I agree that it would be better, but the reason is somewhat subtle.

> In any event, it would be easy to solve this problem with a
> pattern, but I think there's a bigger problem w/ make_domains
> and compute_eyes_pessimistic, and the eye shapes should pick
> out the critical B move to kill.

The code to generate eyespaces is somewhat magical, but basically
simple and fairly fast. I don't see a simple solution to revise it to
do right in this particular position.

In general I agree that the optics code should always be able to find
the vital moves within the eyespaces, but unfortunately it's not quite
good enough. A more significant problem than the occasional
mispositioning of marginal vertices is that it doesn't distinguish
between different types of marginal vertices. In the simplified local
games model this makes no difference but in reality it too often
matters. Another major problem is that when opponent stones inside the
eyespace can be rescued, the eyespace disappears and transforms into a
lunch instead, which is handled totally differently. To give an
example of this, consider the eyespace

..
!...

Clearly this should be critical between one and two eyes. What about
this variation?

X.
!.X.

Try it yourself. You'll see that the optics code is basically lost.

All the weaknesses notwithstanding, the optics code is reasonably
successful anyway. This is to a large degree due to the conservative
nature of compute_eyes_pessimistic() and the fact that many owl
patterns fill in for the mistakes done by the optics code. But this
comes at the cost of performance. The owl code should be able to speed
up substantially with a more accurate eyespace evaluation. However,
this will require a fairly major revision of the optics code and some
good ideas how to go about it.

> In any event, it would be easy to solve this problem with a
> pattern

For the time being, this is what we have to do.

/Gunnar



reply via email to

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