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