Proposed new option twin : use opponent top_moves to find more "big moves"

[alain]

In attachement, an experimental patch for GNU Go 3.7.8 which add new option, and the verbose result of regression tests.

It gives a bonus when one opponent top move is near one our top move. (see genmove.c for the "near" choice and bonus). This gives a better approximation of "hot places", and give more symetry to the engine.

Globally it seems one stone stronger than gg3.7.8 (on 186 games match on 19x19). Maybe it is anti-gnugo, punishing big move miss ?

Normal usage during chuban (0.30 < games_status < 0.90)

gnugo --twin

Tested with kgs robot: twinbot

Known isues:

Sometimes semeai are broken, see comments below or in genmove.c

=> need "play urgent semeai moves before big moves" (this seems possible todo :) This will give a substancial benefit. (see also --large-scale failures due to semeai #29)

maybe could break some ko fights. not sure of this.

Regressions

424 changed genmove

100 PASS (more big moves cgf2004:70)

120 FAIL (some huge miss with one kind of semeai, some good changes wrongly supposed failures)

	 * FIXME if we are fighting a semeai, the twin can sometimes break it,
	 *	 eg when one move is at one side of a dragon, 
	 *		and opponent move is a at the opposite side
	 *	Very big breakages, all due to this kind of semeai:
	 *	kgs:230 gifu05:1120 nngs3:260 trevorb:570 nando:33 nngs2:580
	 *	gunnar:51 strategy3:141 strategy3:117 strategy4:162 strategy4:188 

Regression analyse is not finished yet... its a big task.

[alain]

replace the previous patch, which was broken when twin option is not used !

[alain]

test against the terrible game of the same name. Suspected cache problem, with the twin patch, even when no twin is used. g378 does not have this cache pb here ! i don't understand (yet) the difference in this case !

[alain]

The difference between gg378 and gg-twin without twin option is only due to an endgame broken-optimisation (tm) i made in genmove, to avoid doing review_move_reasons twice. This worked with 3.7.4 this does not work anymore with 3.7.8.

I dont understand really what happens, but the correct move has now nearly 0.0 value, when it is worth 18. or 54. points (with gg374-twin everything is alright) => this prevent the defense of group in atari, and make the engine play endgame move instead.

So the workaround is just to revert the endgame "optimisation". (i still suspect a bug somewhere)

[alain]

patch corresponding to twinbot-0.3 running on CGOS

[alain]

twin-0.4 = twinbis on CGOS. Use some move reasons to avoid big blunders. Previous patch were ugly, this one is worse (more local var transformed in global var !) . Now the functionality seems ok, just need a huge reordering, and performance improvement (just avoid doing useless job).

[alain]

TODO

• clean the code:
  • move the twin in value_moves.c
    
  • revert the local-> global ugly changes on some variables.
    
  • use debug flag for controlling the verbosity of the output
    
  • write the output in sgf comment like others
    

• improve speed: compute our move first
  => if no twin is used we save a precious time during semeai or strategic attac/defend.
  This need to save all our data, make twin-computation, restore our data, do the last checks, find the best move.

[alain]

The "freeze" option added in twin-0.4 seems to be very broken. It's just a functionality try, and a reminder for the rewite.

[gunnar]

Let's see what it takes to make this ready for use. A few early comments:

• Keep it as small as possible for the first round. Leave out auxiliary items like a new scoring mode or time management tweaks.
• Structurally as much as possible of the twin code should go into a file of its own.
• Try to keep the formatting as consistent as possible with other code.
• Patches against CVS are preferred. Also otherwise note that patches for multiple files can simply be concatenated into a bigger patch, which is easier to handle than many small files.

Some specific comments on the patch:

-  if (play_mirror_go
-      && (mirror_stones_limit < 0
-	  || stones_on_board(WHITE | BLACK) <= mirror_stones_limit)
-      && find_mirror_move(&move, color)) {
-    TRACE("genmove() recommends mirror move at %1m\n", move);
+  if (play_mirror_go && 
+	(mirror_stones_limit < 0 || stones_on_board(WHITE | BLACK) <= mirror_stones_limit)
+      && find_mirror_move(&mymove, color)) {
+    TRACE("genmove() recommends mirror move at %1m\n", mymove);

Don't do this kind of gratuitous reformatting. It will only make maintainers weary and inclined to spend their time on something else.

--- ../TGZ/gnugo-3.7.8-ref/./engine/globals.c	2006-01-27 16:49:22.000000000 +0100
+++ ./engine/globals.c	2006-02-21 08:51:03.000000000 +0100
@@ -27,6 +27,7 @@
 #include "sgftree.h"
 #include "liberty.h"
 #include "config.h"
+#include "../interface/gtp.h"
 
 /* 
  * Define all global variables used within the engine.
@@ -99,6 +100,9 @@
 int oracle_exists     = 0;  /* oracle is available for consultation   */
 int autolevel_on      = 0;  /* Adjust level in GMP or ASCII mode. */
 
+char al2_ugly_filename[GTP_BUFSIZE]; /* sgf file loaded, eg for regression test */

This has to be solved in some other way of course.

-  if (debug & DEBUG_TIME)
-    clock_print(color);
+  /* if (debug & DEBUG_TIME)
+   * clock_print(color);
+   */

If you need to comment out code, instead use the "#if 0" idiom.

[alain]

The twin sometimes breaks ko fight when replacing a good threat by a poor one.
W.I.P: fix this nicely, and add test case.

[gunnar]

I'm giving up hope for this to get anywhere and will close it as wontfix. Feel free to reopen the ticket if there should be any kind of active work on this patch.