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@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnugo-devel
>
_______________________________________________
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel
