You stepped on a bug

[Markus Wennrich]

19 . X X X O X . X . X . X O . O X . X . 19
18 X O X O O O X . X X X O O O . O X O . 18
17 X O O . O . O X O O O . O . O . O . O 17
16 X O . O O O . O X + O O X O . O . O . 16
15 X O . O . X O . O O O X . X O . O X X 15
14 . X O O . O . O O . X O O . O . O X . 14
13 X O O . O . O O . O O X . . X O X O O 13
12 . X X O . O . O O X X X . O . X . O . 12
11 X X O . O . O X X . X . . . X O O . O 11     WHITE (O) has captured 56 stones
10 X O O O . O X . X X O O . O O + O . O 10     BLACK (X) has captured 6 stones
 9 . X O . O O O X . . . . . . X O X O X 9
 8 X O O O X O . O . . . O . . . O . O X 8
 7 . X O X . X O . . O . . . . . X O X . 7
 6 X O O O X . O X . . . O O . . . O . . 6
 5 . X O X X O . O O O . . . . . . . . . 5
 4 X O O O O X X O . + . . . . . + . . . 4
 3 . X O . O O O X . O . . . . . . O X . 3
 2 O O . O X X X . . . . . . . . O . O X 2
 1 . O X O X . . . . . . . . . . X O O X 1
   A B C D E F G H J K L M N O P Q R S T
(;GM[1]FF[4]SZ[19]KM[6.5]GN[GNU Go 3.7.7 stepped on a bug]
;B[jj];W[dp];B[do];W[ep];B[cp];W[cq];B[bq];W[bp];B[cr];W[co];B[dq];W[qc]
;B[ap];W[cp];B[bo];W[qq];B[cn];W[io];B[fp];W[dn];B[eo];W[eq];B[er];W[fq]
;B[fr];W[gq];B[gp];W[bn];B[hq];W[cm];B[gr];W[cn];B[dm];W[dl];B[en];W[jq]
;B[cl];W[ck];B[an];W[bl];B[bm];W[cl];B[el];W[ek];B[dk];W[dj];B[cj];W[ci]
;B[bk];W[mn];B[al];W[bj];B[fk];W[nj];B[di];W[ei];B[ch];W[mf];B[ej];W[je]
;B[bi];W[dh];B[ki];W[cg];B[ii];W[nh];B[bh];W[bg];B[ag];W[af];B[bf];W[ll]
;B[jh];W[hd];B[kh];W[qi];B[lh];W[br];B[ig];W[hp];B[jf];W[ke];B[kf];W[fj]
;B[fi];W[fo];B[eh];W[eg];B[dg];W[df];B[fg];W[be];B[ae];W[bd];B[ad];W[bc]
;B[ac];W[cf];B[ce];W[ed];B[cd];W[cc];B[dc];W[ec];B[cb];W[bb];B[ca];W[dd]
;B[ab];W[de];B[ba];W[db];B[da];W[ea];B[eb];W[fb];B[fc];W[gi];B[gj];W[fh]
;B[gh];W[hh];B[hi];W[gg];B[gf];W[hf];B[hg];W[ff];B[ij];W[gk];B[gl];W[fl]
;B[hk];W[fk];B[fm];W[gm];B[hn];W[gn];B[go];W[ho];B[fp];W[jm];B[gp];W[if]
;B[aj];W[cj];B[ai];W[ar];B[as];W[ds];B[cs];W[dr];B[es];W[bs];B[cs];W[hl]
;B[fe];W[fd];B[gd];W[qn];B[he];W[ie];B[id];W[jc];B[kd];W[kc];B[le];W[ge]
;B[jd];W[ic];B[hc];W[ld];B[lc];W[mc];B[md];W[lf];B[kb];W[kg];B[lg];W[jg]
;B[kf];W[ih];B[ig];W[hg];B[jb];W[mb];B[ib];W[lb];B[jd];W[ln];B[id];W[jo]
;B[fa];W[hb];B[gb];W[gc];B[ha];W[eb];B[hc];W[ka];B[ja];W[kd];B[la];W[ga]
;B[nc];W[nb];B[fa];W[ma];B[ob];W[oc];B[pa];W[pb];B[pc];W[pd];B[od];W[oe]
;B[ne];W[nd];B[qb];W[rb];B[ra];W[oa];B[pe];W[qe];B[pf];W[of];B[og];W[pg]
;B[qg];W[rg];B[ph];W[lj];B[rf];W[rh];B[ri];W[qf];B[re];W[pg];B[pf];W[pi]
;B[oi];W[oj];B[ok];W[pk];B[pj];W[qj];B[qk];W[pl];B[pm];W[qm];B[rm];W[rl]
;B[sl];W[rk];B[sk];W[sj];B[rj];W[si];B[sh];W[rd];B[rc];W[sc];B[se];W[sg]
;B[pe];W[pg];B[id];W[kj];B[ss];W[rs];B[sr];W[qs];B[ps];W[pr];B[qr];W[rr]
;B[rq]
)
gnugo 3.7.7 (seed 1699781924): You stepped on a bug.


Compile-time options: --enable-cosmic-gnugo --enable-large-scale --enable-alternate-connections

run-time options: --mode gtp --max-level 0 --level 0 --with-break-in --large-scale


Hope this helps,

btw ... thank you for the great Go engine :-)

Nick

--
java is like a parent caring too much ... "don't use pointers.. don't
work across string boundaries ... -- yes, mum, i know.. *sigh*"



_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[Markus Wennrich]

Ah, I forgot the first lines:


***assertion failure:
owl.c:480 - board[apos] == OTHER_COLOR(board[bpos]) near T2***

 (variation 384)

On Sun, Dec 25, 2005 at 07:52:12AM +0100, Markus Wennrich wrote:

> 19 . X X X O X . X . X . X O . O X . X . 19
> 18 X O X O O O X . X X X O O O . O X O . 18
> 17 X O O . O . O X O O O . O . O . O . O 17
> 16 X O . O O O . O X + O O X O . O . O . 16
> 15 X O . O . X O . O O O X . X O . O X X 15
> 14 . X O O . O . O O . X O O . O . O X . 14
> 13 X O O . O . O O . O O X . . X O X O O 13
> 12 . X X O . O . O O X X X . O . X . O . 12
> 11 X X O . O . O X X . X . . . X O O . O 11     WHITE (O) has captured 56 stones
> 10 X O O O . O X . X X O O . O O + O . O 10     BLACK (X) has captured 6 stones
>  9 . X O . O O O X . . . . . . X O X O X 9
>  8 X O O O X O . O . . . O . . . O . O X 8
>  7 . X O X . X O . . O . . . . . X O X . 7
>  6 X O O O X . O X . . . O O . . . O . . 6
>  5 . X O X X O . O O O . . . . . . . . . 5
>  4 X O O O O X X O . + . . . . . + . . . 4
>  3 . X O . O O O X . O . . . . . . O X . 3
>  2 O O . O X X X . . . . . . . . O . O X 2
>  1 . O X O X . . . . . . . . . . X O O X 1
>    A B C D E F G H J K L M N O P Q R S T
> (;GM[1]FF[4]SZ[19]KM[6.5]GN[GNU Go 3.7.7 stepped on a bug]
> ;B[jj];W[dp];B[do];W[ep];B[cp];W[cq];B[bq];W[bp];B[cr];W[co];B[dq];W[qc]
> ;B[ap];W[cp];B[bo];W[qq];B[cn];W[io];B[fp];W[dn];B[eo];W[eq];B[er];W[fq]
> ;B[fr];W[gq];B[gp];W[bn];B[hq];W[cm];B[gr];W[cn];B[dm];W[dl];B[en];W[jq]
> ;B[cl];W[ck];B[an];W[bl];B[bm];W[cl];B[el];W[ek];B[dk];W[dj];B[cj];W[ci]
> ;B[bk];W[mn];B[al];W[bj];B[fk];W[nj];B[di];W[ei];B[ch];W[mf];B[ej];W[je]
> ;B[bi];W[dh];B[ki];W[cg];B[ii];W[nh];B[bh];W[bg];B[ag];W[af];B[bf];W[ll]
> ;B[jh];W[hd];B[kh];W[qi];B[lh];W[br];B[ig];W[hp];B[jf];W[ke];B[kf];W[fj]
> ;B[fi];W[fo];B[eh];W[eg];B[dg];W[df];B[fg];W[be];B[ae];W[bd];B[ad];W[bc]
> ;B[ac];W[cf];B[ce];W[ed];B[cd];W[cc];B[dc];W[ec];B[cb];W[bb];B[ca];W[dd]
> ;B[ab];W[de];B[ba];W[db];B[da];W[ea];B[eb];W[fb];B[fc];W[gi];B[gj];W[fh]
> ;B[gh];W[hh];B[hi];W[gg];B[gf];W[hf];B[hg];W[ff];B[ij];W[gk];B[gl];W[fl]
> ;B[hk];W[fk];B[fm];W[gm];B[hn];W[gn];B[go];W[ho];B[fp];W[jm];B[gp];W[if]
> ;B[aj];W[cj];B[ai];W[ar];B[as];W[ds];B[cs];W[dr];B[es];W[bs];B[cs];W[hl]
> ;B[fe];W[fd];B[gd];W[qn];B[he];W[ie];B[id];W[jc];B[kd];W[kc];B[le];W[ge]
> ;B[jd];W[ic];B[hc];W[ld];B[lc];W[mc];B[md];W[lf];B[kb];W[kg];B[lg];W[jg]
> ;B[kf];W[ih];B[ig];W[hg];B[jb];W[mb];B[ib];W[lb];B[jd];W[ln];B[id];W[jo]
> ;B[fa];W[hb];B[gb];W[gc];B[ha];W[eb];B[hc];W[ka];B[ja];W[kd];B[la];W[ga]
> ;B[nc];W[nb];B[fa];W[ma];B[ob];W[oc];B[pa];W[pb];B[pc];W[pd];B[od];W[oe]
> ;B[ne];W[nd];B[qb];W[rb];B[ra];W[oa];B[pe];W[qe];B[pf];W[of];B[og];W[pg]
> ;B[qg];W[rg];B[ph];W[lj];B[rf];W[rh];B[ri];W[qf];B[re];W[pg];B[pf];W[pi]
> ;B[oi];W[oj];B[ok];W[pk];B[pj];W[qj];B[qk];W[pl];B[pm];W[qm];B[rm];W[rl]
> ;B[sl];W[rk];B[sk];W[sj];B[rj];W[si];B[sh];W[rd];B[rc];W[sc];B[se];W[sg]
> ;B[pe];W[pg];B[id];W[kj];B[ss];W[rs];B[sr];W[qs];B[ps];W[pr];B[qr];W[rr]
> ;B[rq]
> )
> gnugo 3.7.7 (seed 1699781924): You stepped on a bug.
>
>
> Compile-time options: --enable-cosmic-gnugo --enable-large-scale --enable-alternate-connections
>
> run-time options: --mode gtp --max-level 0 --level 0 --with-break-in --large-scale
>
>
> Hope this helps,
>
> btw ... thank you for the great Go engine :-)
>
> Nick
>
> --
> java is like a parent caring too much ... "don't use pointers.. don't
> work across string boundaries ... -- yes, mum, i know.. *sigh*"
>

--
Budget: A method for going broke methodically.


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Le Dimanche 25 Décembre 2005 07:58, Markus Wennrich a écrit :
>
> ***assertion failure:
> owl.c:480 - board[apos] == OTHER_COLOR(board[bpos]) near T2***
>
Hello wonderfull GNU Go people

i reproduce this also with gnugo 3.6 at level 2, nothing wrong with gnugo 3.4

gnugo-3.6 --level 2 -l crash-4.sgf
        ***assertion failure:
        owl.c:448 - board[apos] == OTHER_COLOR(board[bpos]) near T2***

my 2 cents (really small contrib ;)
alain


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Le Mardi 27 Décembre 2005 12:44, alain Baeckeroot a écrit :
> Le Dimanche 25 Décembre 2005 07:58, Markus Wennrich a écrit :
> >
> > ***assertion failure:
> > owl.c:480 - board[apos] == OTHER_COLOR(board[bpos]) near T2***
> >

hello
 i had alook after this bug:
it appears with gnugo-3.5.5 at level 2 or less
no pb at level 3 or higher

i m slowly investigating ...(this is great fun :)
hope this help

alain


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[Gunnar Farnebäck]

Alain wrote:
>  i had alook after this bug:
> it appears with gnugo-3.5.5 at level 2 or less
> no pb at level 3 or higher

Moreover it does also appear for current CVS at level 2 or lower.

> i m slowly investigating ...(this is great fun :)
> hope this help

Did you get any further? It seems to me that it may be the same
problem as in http://trac.gnugo.org/gnugo/ticket/61.

/Gunnar


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Le Mardi 10 Janvier 2006 22:11, Gunnar Farneb�ck a écrit :

> Alain wrote:
> >  i had alook after this bug:
> > it appears with gnugo-3.5.5 at level 2 or less
> > no pb at level 3 or higher
>
> Moreover it does also appear for current CVS at level 2 or lower.
>
> Did you get any further? It seems to me that it may be the same
> problem as in http://trac.gnugo.org/gnugo/ticket/61.
>
> /Gunnar

Hello

The only thing i found for the moment is:
- in 3.5.5 -> 3.6 the bug appears at level 2 or lower
- in 3.7-pre -> 3.7.7.tar.gz i can download on the site it appears at level
0 , but not at level one or higher

- in recent cvs 3.7.7 it is again at level 2 or lower. So recent cvs have
impact on the bug :)

- from the cvs tree , i revert some patches to go back to 3.7.7 reference
tarball, ( for example owl.c patch) but nothing happened
(i m newbie to C and CVS, so it takes me long time, i was fortran programmer
10 years ago during my phD ;)

i looked at status and many things in gdb ... but find nothing for the moment

i agree it seems to be the same as  http://trac.gnugo.org/gnugo/ticket/61, and
will soon look at this second test case.

But , i m afraid this is a too difficult indirect bug for me, concerning code
i have not studied yet :(
i ll post a message if i find something more or if i give up.

Regards
Alain


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Le Mardi 10 Janvier 2006 22:11, Gunnar Farneb�ck a écrit :
> Did you get any further? It seems to me that it may be the same
> problem as in http://trac.gnugo.org/gnugo/ticket/61.
>
> /Gunnar

i noticed one interesting thing:

- T61 bug still happens for level 5 or _higher_ even with the proposed patch
- the other bug happens for level 2 (or 0) or _lower_

so if this is the same bug, it must be somewhere in the common code,
depending indirectly on the level.

(rh fc4 , gcc4.0.2 or gcc3.2.3-compat)

Alain


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Le Mardi 10 Janvier 2006 22:11, Gunnar Farneb�ck a écrit :

> Alain wrote:
> >  i had alook after this bug:
> > it appears with gnugo-3.5.5 at level 2 or less
> > no pb at level 3 or higher
>
> Moreover it does also appear for current CVS at level 2 or lower.
>
> > i m slowly investigating ...(this is great fun :)
> > hope this help
>
> Did you get any further? It seems to me that it may be the same
> problem as in http://trac.gnugo.org/gnugo/ticket/61.
>
> /Gunnar

a first clue :-)
in both cases the backstrace of the stack in gdb is the same
do_genmove
collect_move_reasons
owl_reasons
test_owl_attack_move
owl_analyze_semeai_after_move

and
gnugo -d 0x0004 (debug worms) does not complete because of the bug

++
Alain


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Le Mercredi 11 Janvier 2006 19:19, alain Baeckeroot a écrit :
> Le Mardi 10 Janvier 2006 22:11, Gunnar Farneb�ck a écrit :

> > Did you get any further? It seems to me that it may be the same
> > problem as in http://trac.gnugo.org/gnugo/ticket/61.
> >
> > /Gunnar
>
> a first clue :-)
> in both cases the backstrace of the stack in gdb is the same
> do_genmove
> collect_move_reasons
> owl_reasons
> test_owl_attack_move
> owl_analyze_semeai_after_move
>

In test_owl_attack_move (owl.c : 4942) i have in both cases  wrong dr2
int dr2 = DRAGON2(dr).semeai_defense_target;

dr2=22  <=> B19 in _both_ cases !!!!!!
which has no link with the semeais (in near J4 or T3), and is hopefully the
wrong color which cause the crash.

So it seems the bug is much earlier, in the definition of
DRAGON2(dr).semeai_defense_target

Well, thats enough for today :)
Alain


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[Gunnar Farnebäck]

Alain wrote:
> dr2=22  <=> B19 in _both_ cases !!!!!!
> which has no link with the semeais (in near J4 or T3), and is hopefully the
> wrong color which cause the crash.
>
> So it seems the bug is much earlier, in the definition of
> DRAGON2(dr).semeai_defense_target

Yes, that's the purpose of the assertion adding patch in ticket 61. It
causes the crashes to occur much earlier and the problem is most
likely in the semeai() function in semeai.c.

/Gunnar


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Le Mercredi 11 Janvier 2006 23:16, alain Baeckeroot a écrit :
>
> In test_owl_attack_move (owl.c : 4942) i have in both cases  wrong dr2
> int dr2 = DRAGON2(dr).semeai_defense_target;
>
> dr2=22  <=> B19 in _both_ cases !!!!!!

in both cases, B19 is the first stone/dragon on the board
=> i suspected loop boundary problem

In engine/semeai.c : 47
#define MAX_DRAGONS 100

instead of 50 fixes the problem:
we have in one case 51 dragons, and in the other 53

Happyly
Alain





_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Hi again

a not very important thing.
The mails take nearly 5 hours to arrive here, so i get it much later
than my next post :(

i dont know if it is done on purpose, but i would find it more pleasant
to get mails lets says in half an our.  

> Received: from localhost ([127.0.0.1] helo=lists.gnu.org)
>         by lists.gnu.org with esmtp (Exim 4.43)
>         id 1Ex7CW-0005I7-RR
>         for alain.baeckeroot@...; Thu, 12 Jan 2006 13:29:32 -0500
>  Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
>         id 1Ex34j-0007JA-D8
>         for gnugo-devel@...; Thu, 12 Jan 2006 09:05:13 -0500

Regards
Alain


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[Bump-2]

> a not very important thing.
> The mails take nearly 5 hours to arrive here, so i get it much later
> than my next post :(
>
> i dont know if it is done on purpose, but i would find it more pleasant
> to get mails lets says in half an our.  

We can't do anything about the slowness of the mailing list,
which is quite variable.

However if it's impeding things you can add a few people like
Gunnar to your cc: list and maybe get faster replies.

Dan


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[Gunnar Farnebäck]

Alain wrote:
> in both cases, B19 is the first stone/dragon on the board
> => i suspected loop boundary problem
>
> In engine/semeai.c : 47
> #define MAX_DRAGONS 100
>
> instead of 50 fixes the problem:
> we have in one case 51 dragons, and in the other 53

The loops are fine, due to this construction:

  if (num_dragons > MAX_DRAGONS) {
    TRACE("Too many dragons!!! Might disregard some semeais.");
    num_dragons = MAX_DRAGONS;
  }

  for (d1 = 0; d1 < num_dragons; d1++)

What's not fine is that there's no check that neighbor dragons have
numbers below MAX_DRAGONS.

Actually I'm rather sceptical about the approach to truncate the
number of analyzed dragons. I think it makes more sense to entirely
turn off the semeai analysis if there are too many dragons, on the
basis that it would only occur in pathological games where semeai
analysis is not critical for the result. I was going to propose
increasing MAX_DRAGONS first but after looking closer at the two crash
inducing games I changed my mind.

Patch added to the ticket.

/Gunnar


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Le Jeudi 12 Janvier 2006 23:04, Gunnar Farneb�ck a écrit :
> The loops are fine, due to this construction:
>
>   if (num_dragons > MAX_DRAGONS) {
>     TRACE("Too many dragons!!! Might disregard some semeais.");
>     num_dragons = MAX_DRAGONS;
>   }
>
>   for (d1 = 0; d1 < num_dragons; d1++)
yes

>
> What's not fine is that there's no check that neighbor dragons have
> numbers below MAX_DRAGONS.

hmm still it is not very clear for me why B19 dragon is considered involved in
a semeai near T3, when it is really not the case.
I saw the #define MAX_DRAGONS and was instantaneouly "sure" that it was
implied in the bug
>
> Actually I'm rather sceptical about the approach to truncate the
> number of analyzed dragons. I think it makes more sense to entirely
> turn off the semeai analysis if there are too many dragons, on the
> basis that it would only occur in pathological games where semeai
> analysis is not critical for the result. I was going to propose
> increasing MAX_DRAGONS first but after looking closer at the two crash
> inducing games I changed my mind.

i agree with your analyse, but i dont like exeptions in the code, i prefer a
"straightforward" engine which handle correctly all the cases.
Because for a newcomer (like me) each exception in the code need a lot of
thinking to be understood, and for coder it must be documented ...
(i ll post a message with a very clear example of this complexity due to
exceptions)

Even in those rare pathological games (2 bug reports in nearly 2 years), GNUgo  
behaves well, and is winning.
With the timing-adaptative level we will have no fear to lose on time, because
of obscure semeai search (this semeai are quickly solved by the engine).

So i vote for coding  MAX_DRAGONS = MAX_WORMS and against introducing an
exception for 2 pathological cases. (even if gnugo will lose due to that ;-)

Regards
Alain


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

 Hello again

This is just an argument for keeping the code as simple as possible, and not
introduce exceptions when we can avoid them.

Here is one good example of what i call "newbie-confusing complexity" :-)

examine_position is 100 lines function (in engine/genmove.c)
 
 * The parameter how_much tells us how much of the work we have to do.
 * For move generation we have to do it all.  For debugging we can
 * sometimes stop a little earlier.

As far as i understand, the normal flow of operation fits in 10 lines, the 90
other lines are here for debugging purpose.
But thats 900% overload for my brain ;-) . Instead of reading it in 30
seconds, i spent a lot of time (maybe one hour) to be sure i do not miss
something within all the tests.

Maybe the debugging code could be #ifdef DEBUG , but thats a big job and
another problem... for gnugo 3.10 or 4. ?

regards
Alain


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[arend.bayer (Bugzilla)]

Hi Alain,

Alain Baeckeroot wrote:

>  Hello again
>
> This is just an argument for keeping the code as simple as possible, and not
> introduce exceptions when we can avoid them.
>
> Here is one good example of what i call "newbie-confusing complexity" :-)
>
> examine_position is 100 lines function (in engine/genmove.c)
>  
>  * The parameter how_much tells us how much of the work we have to do.
>  * For move generation we have to do it all.  For debugging we can
>  * sometimes stop a little earlier.
>
> As far as i understand, the normal flow of operation fits in 10 lines, the 90
> other lines are here for debugging purpose.
> But thats 900% overload for my brain ;-) . Instead of reading it in 30
> seconds, i spent a lot of time (maybe one hour) to be sure i do not miss
> something within all the tests.

First of all the code flow there could certainly be simplified, without
losing any functionality. Maybe I can get around to do this at some time.

Generally, I fully agree that this kind of special-casing thing has serious
costs. I am always in favour of throwing out special case code that is only
needed in rare cases and makes the case less readable. Patches simplifying
some piece of code are always welcome.

However, in this case, the comment above is a little misleading. This
"stopping earlier" happens in every reading/connection/life-and-death
regression test, and it would make the runs of owl.tst a lot slower if
we removed the "how_much" parameter.

Arend

> Maybe the debugging code could be #ifdef DEBUG , but thats a big job and
> another problem... for gnugo 3.10 or 4. ?
>
> regards
> Alain
>
>
> _______________________________________________
> gnugo-devel mailing list
> gnugo-devel@...
> http://lists.gnu.org/mailman/listinfo/gnugo-devel
>

_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[Gunnar Farnebäck]

Alain wrote:
> hmm still it is not very clear for me why B19 dragon is considered
> involved in a semeai near T3, when it is really not the case.

Consider this code:

  for (d1 = 0; d1 < num_dragons; d1++)
    for (k = 0; k < dragon2[d1].neighbors; k++) {
      int apos = DRAGON(d1).origin;
      int bpos = DRAGON(dragon2[d1].adjacent[k]).origin;
      int result_certain;
     
      d2 = dragon[bpos].id;

E.g. when d1=47 there may be a neighbor dragon with id d2=50. If it
turns out to be involved in a semeai, this call

      owl_analyze_semeai(apos, bpos,
                         &(semeai_results_first[d1][d2]),
                         &(semeai_results_second[d1][d2]),
                         &(semeai_move[d1][d2]), 1, &result_certain);

will index the 2D arrays out of bounds on the second index. The effect
is that [47][50] points to the same address as [48][0]. When the
arrays later are traversed a semeai between dragon 48 and dragon 0
will be found, where the former tends to live in the lower right
corner and the latter in the upper left corner.

> i agree with your analyse, but i dont like exeptions in the code, i prefer a
> "straightforward" engine which handle correctly all the cases.
> Because for a newcomer (like me) each exception in the code need a lot of
> thinking to be understood, and for coder it must be documented ...

Rest assured that this is one aspect of the code we always take into
account. But there are tradeoffs to make with factors like speed,
memory consumption, robustness, language limitations, portability
issues, and so on.

> Even in those rare pathological games (2 bug reports in nearly 2
> years),

Not really pathological, although the crashes are and should be rare.
This kind of game is somewhat common against very weak beginners.
There's no way for GNU Go to win by less than 200 points or so,
however, except by crashing.

> GNUgo behaves well, and is winning. With the
> timing-adaptative level we will have no fear to lose on time,
> because of obscure semeai search (this semeai are quickly solved by
> the engine).

Time is not much of an issue here at all.

> So i vote for coding  MAX_DRAGONS = MAX_WORMS and against introducing an
> exception for 2 pathological cases. (even if gnugo will lose due to that ;-)

I wouldn't mind using that except that I'm doubtful about the wisdom
of spending 1 MB of stack space (13*(4/5*19*19)^2) for these arrays or
even the 324 kB they can be reduced to by changing type to signed char
(at the cost of some extra code complexity). In fact I'm fairly sure
that the former is not portable enough and I'd rather avoid the latter
as well. Especially since no more than a tiny fraction of the entries
will ever be used at any one time.

I think the cleanest solution is to special case this situation and
disable the semeai analysis for huge numbers of dragons.

/Gunnar


_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel

[alain.baeckeroot (Bugzilla)]

Thanks a lot for your very clear explaination.

I was not sure that in C  [47][50] points to the same address as [48][0] (in
fortran i know it, but i didnt know if it is a language feature or compiler
one, or something else)
Also i did not think of the consequences on stack space... i have a lot to
learn in GNU go :)

i have tried a lot of small changes and break many things, for understanding
the engine. I m doing some clean-up and will send a weird patch soon, with
regression results (lots of breakages, and probably slower and weaker engine
<:o)

Alain

Le Vendredi 13 Janvier 2006 22:04, Gunnar Farneb�ck a écrit :

> Alain wrote:
> > hmm still it is not very clear for me why B19 dragon is considered
> > involved in a semeai near T3, when it is really not the case.
>
> Consider this code:
>
>   for (d1 = 0; d1 < num_dragons; d1++)
>     for (k = 0; k < dragon2[d1].neighbors; k++) {
>       int apos = DRAGON(d1).origin;
>       int bpos = DRAGON(dragon2[d1].adjacent[k]).origin;
>       int result_certain;
>      
>       d2 = dragon[bpos].id;
>
> E.g. when d1=47 there may be a neighbor dragon with id d2=50. If it
> turns out to be involved in a semeai, this call
>
>       owl_analyze_semeai(apos, bpos,
> &(semeai_results_first[d1][d2]),
> &(semeai_results_second[d1][d2]),
> &(semeai_move[d1][d2]), 1, &result_certain);
>
> will index the 2D arrays out of bounds on the second index. The effect
> is that [47][50] points to the same address as [48][0]. When the
> arrays later are traversed a semeai between dragon 48 and dragon 0
> will be found, where the former tends to live in the lower right
> corner and the latter in the upper left corner.
>
> > i agree with your analyse, but i dont like exeptions in the code, i prefer

a

> > "straightforward" engine which handle correctly all the cases.
> > Because for a newcomer (like me) each exception in the code need a lot of
> > thinking to be understood, and for coder it must be documented ...
>
> Rest assured that this is one aspect of the code we always take into
> account. But there are tradeoffs to make with factors like speed,
> memory consumption, robustness, language limitations, portability
> issues, and so on.
>
> > Even in those rare pathological games (2 bug reports in nearly 2
> > years),
>
> Not really pathological, although the crashes are and should be rare.
> This kind of game is somewhat common against very weak beginners.
> There's no way for GNU Go to win by less than 200 points or so,
> however, except by crashing.
>
> > GNUgo behaves well, and is winning. With the
> > timing-adaptative level we will have no fear to lose on time,
> > because of obscure semeai search (this semeai are quickly solved by
> > the engine).
>
> Time is not much of an issue here at all.
>
> > So i vote for coding  MAX_DRAGONS = MAX_WORMS and against introducing an
> > exception for 2 pathological cases. (even if gnugo will lose due to

that ;-)

>
> I wouldn't mind using that except that I'm doubtful about the wisdom
> of spending 1 MB of stack space (13*(4/5*19*19)^2) for these arrays or
> even the 324 kB they can be reduced to by changing type to signed char
> (at the cost of some extra code complexity). In fact I'm fairly sure
> that the former is not portable enough and I'd rather avoid the latter
> as well. Especially since no more than a tiny fraction of the entries
> will ever be used at any one time.
>
> I think the cleanest solution is to special case this situation and
> disable the semeai analysis for huge numbers of dragons.
>
> /Gunnar
>
>
> _______________________________________________
> gnugo-devel mailing list
> gnugo-devel@...
> http://lists.gnu.org/mailman/listinfo/gnugo-devel
>

_______________________________________________
gnugo-devel mailing list
gnugo-devel@...
http://lists.gnu.org/mailman/listinfo/gnugo-devel