Re: [gnugo-devel] some kind of bug, bad position reading - v3.2

[Gunnar Farneback]

Paul wrote:
> A bug:
>    enter these commands:
>       load igs3.sgf
>       listdragons (or showdragons)
>       a2          (or d1)
>    Gnu go fails due to some kind of memory corruption. Parts of *owl
>    structure are unaccessible in do_owl_attack (engine/owl.c). This
>    causes access violation in pop_owl function called from line 1582:
>          pop_owl(&owl);
>    Note that listdragons/showdragons are needed to reproduce the bug.
>    In case it is a platform-dependent bug, i'm using windows 98.

I believe Arend has found a fix for this problem.

> If gnu go plays white:
> B: a2         |XXX.....
> W: a3         |OOOXXX..
> B: d1         |X..O....
> W: pass       |.O.X....
>               +---------
> 
> So, it "understands" that white stones are dead after two moves, but
> cannot find that moves if attacking.

GNU Go tries to read out the life and death problem but has no pattern
to generate the move at D1. That can be added to the
patterns/owl_attackpats.db file.

> And yet another thing. If gnu go is to make a move for white in
> position
> 
> |XXX.....
> |XOOXXX..
> |O..OX...
> |.O.OX...
> +---------
> 
> it moves b2. I think that c2 is a better move since b2 leaves a
> ko-threat for black (in case of a ko) at c2.

Yes, c2 is better. We just haven't bothered trying to get these
subtleties right yet.

> I attached an sgf file with this position (board is filled with black
> stones to make gnu go concentrate on the position).

We usually do such testing in gtp mode. Then one can do

loadsgf Igs3.sgf
owl_attack B3
owl_defend B3

to find out how it has analyzed the life and death problem. As a bonus
there is no need to add stones in the rest of the board.

To automate testing one can go a step further and write a .tst file
like

loadsgf Igs3.sgf
1 owl_attack B3
#? [1 A2]
2 owl_defend B3
#? [1 (A3|A2|B2|C2|E2|D1)]

and then run it with e.g. /regression/eval.sh

/Gunnar