gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] Readconnect


From: Tristan Cazenave
Subject: Re: [gnugo-devel] Readconnect
Date: Sun, 09 Dec 2001 23:10:04 +0100

Gunnar Farneback a écrit :
> 
> Tristan wrote:
> > One thing you can do is write and optimize the move ordering in
> >
> > moves_to_prevent_connection_in_two_moves
> > moves_to_connect_in_three_moves
> 
> This patch revises moves_to_connect_in_two_moves(), adds some code to
> moves_to_connect_in_three_moves(), and reapplies a punctuation patch
> that was lost in 3.1.16.
> 
> I'm not completely sure that it follows Tristan's plan but it can't be
> all bad since it solves 11 tests in connect.tst (11, 31, 32, 38, 40,
> 53, 65, 66, 73, 76, 81) and 2 in connection.tst (28, 33).
> 

that's detecting common second order liberties, so it is exactly what
is needed.
by changing one line, we get even two more passes :)

 static int moves_to_prevent_connection_in_three_moves (int *moves,
                                                       int str1, int
str2) {
-  if (moves_to_prevent_connection_in_two_moves(moves, str1, str2))
+  if (moves_to_connect_in_three_moves(moves, str1, str2))
     return 1;
   return 0;

}                                                                               
                                                     


> detail in the code that confuses me is that connection_one_move()
> and quiescence_connect() are almost identical, except that the latter
> also allows capture in a ladder. Is there any reason why the calls to
> connection_one_move() could not be replaced by calls to
> quiescence_connect()?

I do not know what it gives, but the idea behind is that
prevent_connection_one_move
finds the complete list of moves when no ladder is involved, so
correctness of the result is guaranteed.
To prevent a ladder, many moves are usually possible.

Tristan.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]