Re: [gnugo-devel] Semeai stuff

[Daniel Bump]

Arend wrote:

> I do not think that was the main problem. If you look at the old lines
> 
>   if (best_resulta == UNKNOWN) {
>     do_owl_analyze_semeai(bpos, apos, owlb, owla, komaster,
>                           resultb, resulta, NULL, 1);
>     SGFTRACE2(PASS_MOVE, UNKNOWN, "No move found");
>     if (move) *move = PASS_MOVE;
>     READ_RETURN_SEMEAI(read_result, move, PASS_MOVE, UNKNOWN, UNKNOWN);
>   }
> 
> you see that the result returned (via *resulta and *resultb) is different
> to the one that is written to the cache. (UNKNOWN was later parsed as
> != DEAD, hence win, by small_semeai_analyzer, which added a defend_code = WIN
> and PASS_MOVE as defense point.)

I think your patch is correct and should go in. It's in my current
working copy. I labelled it arend_1_24.2 and it's posted on devel.html.

Two problems were identified. Fixing either seems sufficient to stop the
crashes.  Which is the most serious is now an academic question.

> So I think it is safe to ignore pass == 1 when caching. OTOH, only caching
> in case of owl==1 might loose a bit too much. Here it might of course make a
> difference. Maybe it is most elegant to define

This is an approach we should remember. But at the moment it seems to me
that when the owl code is turned off there is little or no branching,
so not caching when owl==0 shouldn't have much penalty. The algorithm
without owl moves is to fill the first possible: (1) safe outside liberty; 
(2) backfilling move; (3) safe inside liberty. If no move is possible,
it might be seki. But only one move is tried.

> Finally, it seems to me that small_semeai_analyzer should also
> test whether the winning semeai move should count as an attack move for 
> he 2nd string? Or do you assume that that move will have an tactical
> ATTACK_MOVE reason anyway?

Both strings are assumed attackable. This is tested by small_semeai. 
On the other hand it's possible that we should move the attack point 
for the second string.

Right now I'm looking at filllib:19. I stated incorrectly that 
this error only occurs in the gtp. To get it from the command
line run:

gnugo -l filllib4.sgf --quiet -L252 -t --color white

Dan