Re: [gnugo-devel] bug fixed

[alain Baeckeroot]

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