Re: [gnugo-devel] bugfix

[Gunnar Farneback]

Arend wrote:
> > +    color = board[str];
> >    }
> >    else if (sscanf(s, "%*s") != EOF)
> >      return gtp_failure("invalid coordinate");
> >
> > -  silent_examine_position(BLACK, EXAMINE_DRAGONS);
> > +  silent_examine_position(color, EXAMINE_DRAGONS);
> 
> I don't understand how this can make a difference:

Exactly my thought, except I have a suspect. The dragon status must
not be allowed to depend on who's to move.

>  * color is the player in turn to move. This does in no way affect the
>  * information collected about the dragons, but it does affect what
>  * information is passed on to the move generation code. If
>  * color == EMPTY no information at all is passed on to the move
>  * generation.
>  */

It's a misfeature that move reasons are generated during make_dragons
at all. The long term goal must be to get rid of that.

> So using black resp. white should _not_ influence the status.
> 
> This smells like a bug somewhere else to me.

This smells like the semeai code. Try this experiment related to
ld_owl:302:

sulitelma> gnugo --quiet -l mixed1.sgf -d0x40 --color white
semeai_analyzer: S19 (me) vs R19 (them)
...tactical situation detected, exiting
semeai_analyzer: R17 (me) vs R19 (them)
white (O) move A2

sulitelma> gnugo --quiet -l mixed1.sgf -d0x40 --color black
semeai_analyzer: R19 (me) vs R17 (them)
Changing status of R17 from CRITICAL to ALIVE.
Changing safety of R17 from CRITICAL to ALIVE_IN_SEKI.
semeai_analyzer: R19 (me) vs S19 (them)
...tactical situation detected, exiting
black (X) move A2

The semeai code incorrectly changes the status, but only if it's black
to move! Hopefully the experimental semeai code behaves better in this
respect.

/Gunnar