Re: [gnugo-devel] semeai code observations

[bump]

> 1. do_owl_analyze_semeai() is way too large and complex. I'm not even
>    close to being able to follow it through. We need to simplify and/or
>    break up the code in smaller pieces.

This is certainly true. 

I'd also say that owl_defend and owl_attack are too complicated. In
those cases much of the complication the result of optimizations.
But the fact remains, they are difficult.

A problem is that the semeai code mixes inputs from too many
different sources---both attacking and defending owl moves,
moves to fill an outside liberty, backfilling moves.

I think a reasonable aim is to make the semeai outcomes
fairly reliable in sufficiently simple positions, and to
figure out ways of working around its deficiencies. For
example: 

(1) If the semeai code believes that an opponent's
dragon in the semeai is dead, and fills one of our
liberties, treat the opponent's dragon as a thrashing
dragon.

(2) If the semeai code believes an opponent's dragon
is dead, it currently does not produce an attacking
move. This will be easy to change. At least generate
a move to fill a liberty of the opponent's dragon
for use by a thrashing dragon whacker. It is up to
new_semeai() to notice that the status is the same
no matter who moves first and that the attacking
move is not needed, not owl_analyze_semeai().

(3) The rewritten new_semeai may be a bit more
aggressive than the owl new_semeai in changing
group statuses from CRITICAL to ALIVE, ALIVE_WITH_SEKI
or DEAD. Changing a status from CRITICAL to something
else is very often a mistake, since it leads to 
tenuki in an active semeai.

(4) The semeai code is not yet ko aware. This needs
to be fixed but is perhaps a lower priority than
(1), (2) and (3). Also it would be good to have an
estimate of the margin of safety in a semeai. How
many moves ahead are we?

Dan