Re: [gnugo-devel] look at regress file

[Gunnar Farneback]

Kevin wrote:
>   i did some detailed research on this case and the
> following are what i found so far:
> 
>   1. how did gnugo found J11:
>   J11 was found by gnugo in shapes(). it present J11
> with 3 move_reasons:
>     Move at J11 expands territory
>     Move at J11 strategically attacks L7
>     Move at J11 strategically defends J10

This looks like the result for GNU Go 3.2. When it comes to
development that version is ancient. It's more or less meaningless to
discuss mistakes by anything older than the most recent development
version (currently 3.3.17). Preferable is to use an up to date copy
from CVS.

Current versions understand that the J8 dragon is critical but want to
defend it at H8, which doesn't look effective. So this would indeed
require owl tuning to solve.

>   3. i found that there is no difference between if L9
> is presented with 2 move_reasons:
>     Move at L9 expands territory
>     Move at L9 strategically defends J10
> or with 3 move_reasons by add:
>     Move at L9 strategically attacks L7
> in terms of final valuation results.
> Then, i dig into the source code of value_moves.c, and
> found that there is no place the 'strategically
> attacks' move_reason was valuated and add a value.

Yes, there is. Lines 2313-2369 (in current version of course).

> >From the manual judgement of the board situation, the
> sente of L9 is because it's strategically attacks L7
> if it get followup-move at M9. So, i think this is the
> key problem of gnugo in handling this specific case.

No the key problem is that it doesn't get the life and death reading
right. Until it does there's not too much point in discussing the move
valuations. 

> the solution: i recommand to make some enhancement to
> the value_moves.c to add handling 'strategically
> attacks' move_reason, especially with sente.
> 
> how difficult it is and how well it will be done, that
> depends, but in principle, that's something needs to
> be done. i like to give a try and also like to co-work
> with anyone who likes to join.

This is an important problem in general, although it might not quite
apply in this specific test case. I also think it's a very difficult
problem. I would definitely recommend taking a look at some more
regression tests looking for systematic errors done by GNU Go.

If you want to concentrate on one specific test case I can recommend
13x13b:8, which should be quite tractable.

/Gunnar