Re: [gnugo-devel] Semeai code redesign

[Gunnar Farneback]

Dan wrote:
> The semeai code clearly has problems. I don't think writing
> a strong semeai module will be easy. I had been assuming this
> task would be post 3.4 but if Gunnar wants to try I have no objection
> and will try to help.

Preliminary results are promising. I currently have a net improvement
of 7 pass against one fail in semeai.tst and something like 24 pass
against 11 fail overall. This comes at a slowdown of about 20% for
semeai.tst.

If more people want to help I could certainly use more test cases.
Things like big eye against small eye or big eye against no eye but
lots of liberties would definitely be useful. Test cases ending in ko
would also be interesting. 

Evan pointed out that the recent NNGS game
uno-gnugo-3.3.17-200304052111.sgf had a big semeai misunderstanding in
the upper left near the end of the game. That could be a good source
for a few test cases if someone took the time to determine exactly
what went wrong and when it did.

> This scheme sounds workable. If I understand correctly this will
> not require more room in the hash nodes.

Right.

> Regarding your last point I think we can ignore the
> distinction between life in seki and independent life.
> If we can get a better semeai module, this is a small
> price to pay.

That's what I think too. For the record though, the problem is with
positions like this:

|OOOO.......
|...OO......
|XX..O......
|.X..O......
|XXXXOOOOOO.
|OOOOXXXXXO.
|.O....X.XO.
+-----------

In the semeai between the two groups at the bottom, the local result
will be either mutual independent life or mutual life in seki. For X
seki doesn't suffice globally though so there's a big difference
between the two results.

> If we intend to remove the distinction between the owl phase
> and the tactical phase I'd suggest either developing an alternative
> module in parallel and swapping it in when it's working right
> (as was done with the connection code) or putting this change
> off until the ko revision is already done. 
> 
> The reason is that I'm not convinced it will will be so easy
> to remove the distinction between an owl phase and a tactical
> and get a working module.

I actually started with this part (the tactical code is still there
but the owl_phase is never turned off). So far I haven't seen any
problems with this. What kind of difficulties should I expect?

> The ko change is going to require changes in semeai.c as well
> as owl.c and would clearly benefit the existing semeai
> module.

And in semeai.tst.

> I'd prefer a revision path that makes this change first, then see if
> you can remove the tactical phase.

I could live with doing a merge with my current revisions if someone
wants to start in this end with the existing code.

> The third change that Gunnar proposes seems less significant
> than the other two.

There's a simple and quite nice trick here. If one of the dragons is
captured, we call do_owl_attack() to determine whether the other
dragon can be killed. I'm happy to say that this allowed me to solve
test cases owl:41,42.

I've put up a preliminary and very unpolished patch at

http://www.lysator.liu.se/~gunnar/gnugo/patches/gunnar_3_18.9

to show what's going on with the code. This is not intended for CVS at
this time but some parts (new eye patterns, owl tuning) could be used
as is. If someone feels like evaluating what regression effects those
have, please do. If Dan finds pieces of the patch interesting to use
with the existing code, feel free to pick those out.

/Gunnar