Re: [gnugo-devel] Semeai stuff

[Arend Bayer]

I must admit that I had completely overlooked the matter about the
parameters of owl_analyze_semeai. OTOH, I am not sure whether the
pass parameter really causes problems.

> 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
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.)

If do_owl_analyze_semeai(apos, bpos) is called with pass==1, this
should not change its result at all. If it finds a move, it forgets about the
pass parameter. If it doesn't find a move, then it will either claim SEKI (if
called with pass==1), or else it will pass and call
do_owl_analyze_semeai(bpos, apos); however, if it is at all possible that 
do_owl_analyze_semeai(apos, bpos) gets called with pass == 1 in this
position, then this must mean that do_owl_analyze_semeai(bpos, apos) cannot
find a move, so hence this function will claim seki, return this, yielding
the same result.

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

#define SEMEAI 10
#define SEMEAI_OWL SEMEAI + 1

and then use
    get_read_result2(SEMEAI + owl_phase, EMPTY, 0, &apos, &bpos, &read_result)
?


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?

Arend