Re: [gnugo-devel] Inge's patch (fix)

[Gunnar Farneback]

Inge wrote:
> The reason for the other failure, filllib 15, is that P19 and R19 both
> are moves that according to value_move_reasons() does the following: 
> "carry out threat or defend against threat".  They are both pure
> threat moves and get exactly the same valuation except for a small
> random contribution.  This random term decides wether P19 or R19 is
> played and thus if the test succeeds or fails.

The difference between genmove() and genmove_conservative() is exactly
whether empty threats should be carried out or not. The gtp function
gg_genmove uses genmove_conservative() because it's more natural not
to carry out empty threats in a regression setting. The genmove_*
commands on the other hand use genmove() since it may turn out
successful (either because the opponent answers incorrectly or because
the threat was better than we thought) in a real game situation.

> I suspect that one of Gunnars late changes may be responsible for this
> so I will let him attack it first. If he plays the ball back to me I
> will give it a try.

My patches have nothing to do with this. In retrospect it's easy to
see that your patch introduced a bug in genmove_conservative:

>  int
>  genmove_conservative(int *i, int *j, int color)
>  {
> -  return do_genmove(i, j, color, 0.0);
                                    ^^^
> -}
> +  int move;
> +  int retval;
>  
> +  retval = do_genmove(&move, color, 0.4);
                                       ^^^

effectively causing gg_genmove_conservative() to also generate empty
threat moves. Since your analysis shows that the problem is with empty
threats being generated, it seems very likely they were caused by your
patch. And indeed your bugfix does solve the problem also with
filllib:15. Run the filllib test suite and you will see that it all
passes again.

> During the debugging of this I found it convenient if I could generate
> moves for both colors from a given position so I implemented a
> --genmove option with a color argument.

In these particular cases it's easy to switch color by increasing the
move number by one since there's a pass move next in the game record.
You would probably have been better helped by a switch which causes
the LOAD_AND_ANALYZE mode to use genmove_conservative() instead of
genmove().

/Gunnar