gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] owl attack moves and semeais


From: Gunnar Farneback
Subject: Re: [gnugo-devel] owl attack moves and semeais
Date: Fri, 09 Apr 2004 04:35:02 +0200
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)

Arend wrote:
> Ok. Sow how about:
> 
> - if it's tactically capturable => dead for now
> - otherwise, if owl alive => alive, otherwise dead for now
> - if there is a single semeai that a "dead" dragon will win, we change it's
>   status to alive

That has better chances to work, although I have a feeling there will
pop up more complications.

> IMO, winning a single semeai should be enough to make a dragon alive. If
> capturing the other dragon is not sufficient to make life, the semeai
> code shouldn't claim a win.

The semeai code can handle the situation where capturing the other
dragon would leave a dead shape. The more difficult case is of this
type:

|OOOOOOO..
|.OO.X.O..
|OO..X.O..
|..XXXOOOO
|XXXOOOXXO
|X.OOXX.XO
|XXXOX.XXO
|X.OXXX..O
|X.OXOOOOO
|X.OOXXX.O
|X.O.X.OOO
|X.O.X.O.O
+---------

The semeai reading code will think that the big X dragon can win
against the O dragon since it fails to understand that O can in turn
win its semeai against the small X dragon. I think it would take quite
a bit of work and a loss of efficiency to make the semeai reading
consider all relevant moves. It might ultimately be the best solution,
but I'm not sure about it.

(I haven't verified that the position above really is analyzed like
this but there certainly are testcases where it applies. Ah,
semeai:81-86 and nicklas5:1211 are mentioned in the semeai.c
comments.)

> In other words, if the semeai code claims a dragon is still killed in a
> semeai, and this dragon is part of multiple semeais, this opinion is as
> unreliable as owl claim "dragon is dead" if it is involved in a semeai.

Or maybe I misunderstood your proposal. Can you clarify how it would
work out for the three dragons in the example above (or in one of the
real test cases)?

> In other words, I think my policy above is as good as it gets without
> proper combination reading of multiple semeais. (Which I am not
> proposing to do.)

I actually think that the code in semeai.c might do a bit better than
that. But you're welcome to prove me wrong. :-)

/Gunnar




reply via email to

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