[gnugo-devel] Semeai stuff

[Daniel Bump]

Gunnar and I looked at the problems with the semeai
patch I wrote about yesterday. We identified the
problem and I revised the patch.

Arend looked at the problems too and came to similar
conclusions about the cause with a different fix. 
Probably his change should be used on top of the
revised patch. His comment about sekis (see the
patch) could be important.

Both my patch and Arend's are up at devel.html.

I haven't added these revisions to the CVS yet but
the semeai patches are starting to look usable.

The crash I discussed was caused by the caching
but the bug was not in cache.[ch]. My analysis
yesterday was incorrect.

The function do_owl_analyze_semeai can be run with
a parameter pass. What was happening was that a
result was cached with pass==1 and retrieved with
pass==0. The resulting loss of information led
GNU to think that one string could be saved with a 
pass. We ended up with a string with a nonzero
attack code, a nonzero defend code, and defense
PASS. This is an inconsistent state that caused
a crash later in the program.

The solution is to either cache the pass code or
not to cache when pass==1. For the time being we
went the latter route. After the patch, we
neither cache nor examine the cache unless
pass==0 and owl==1.

Another change is a complete revision of
small_semeai. The old version was clunky and
could end up finding the same semeai multiple
times.

The owl defense codes are changed through
change_defense, not directly as in the
previous version.

Another change in this patch is that unsafe
outside liberties are not tried.

The reduction in owl nodes is disappointing
however. Without the patch, semeai.tst takes
507475 reading, 1924 nodes. With the patch,
506696 reading, 1802 owl. This is only a
6% saving. Before I was able to do quite
a bit better than that. So perhaps we need
to cache the pass parameter after all.

After the patch, there are 13 unexpected PASS
and 8 unexpected FAIL. I looked at one of the
fails, filllib:19. This is strange, because
when the file is loaded from the command line
it finds the right move, but when loaded from
the gtp it finds the bogus move at S9. This
bogus move occurs even when compiled without the
experimental semeai. I don't know how to account
for this. It is primarily because of this that I
haven't added the patch to the CVS.

Comparing these results with the ones when we
tested the experimental semeai code after
3.1.21, many of the gained regressions are
preserved. A few have been lost, namely

nicklas5:1406
nngs:1600
nngs:1700
trevorb:430
trevorb:630

Other mysterious results are the 2 unexpected
PASS in connection.c and a FAIL in optics.c

In addition to these tests, any unexpected FAIL
in the following list should be examined.

Finally, there are two unexpected PASS in
connection.tst.

./regress.sh . optics.tst
317 unexpected FAIL: Correct '1 2 B18 B18', got '0 0'
./regress.sh . filllib.tst
19 unexpected FAIL: Correct 'A13', got 'S9'
./regress.sh . connection.tst
6 unexpected PASS!
78 unexpected PASS!
./regress.sh . lazarus.tst
4 unexpected FAIL: Correct 'R12|Q12|M8', got 'T5'
7 unexpected PASS!
./regress.sh . strategy2.tst
55 unexpected FAIL: Correct 'C12', got 'B14'
72 unexpected PASS!
./regress.sh . nicklas1.tst
1406 unexpected PASS!
./regress.sh . nicklas2.tst
2104 unexpected FAIL: Correct 'PASS', got 'E2'
./regress.sh . nicklas3.tst
602 unexpected PASS!
./regress.sh . trevor.tst
461 unexpected PASS!
./regress.sh . nngs.tst
250 unexpected FAIL: Correct '!S15', got 'S15'
1520 unexpected FAIL: Correct 'F15|F14', got 'C16'
1790 unexpected PASS!
2040 unexpected PASS!
./regress.sh . strategy3.tst
114 unexpected PASS!
./regress.sh . global.tst
46 unexpected PASS!
./regress.sh . 13x13.tst
36 unexpected PASS!
./regress.sh . strategy4.tst
168 unexpected FAIL: Correct 'A3|A4', got 'B7'
188 unexpected PASS!

Dan