Re: [gnugo-devel] About 3.4

[SP LEE]

> 
> As far as I can see the biggest objection to 3.3.23 as a
> candidate for 3.4 is the break in code. The problems:
> 
> (1) It makes the engine slower by at least 20 %, maybe a
> little more.
> 
> Stephane suggested that I test Arend's pending patch
> arend_3_23.1a and see if it gives a speedup. I haven't
> done that yet but will do so.
> 
> (2) It gives no statistical improvement in gnugo/gnugo matches.
> 
> It does give regression improvements and Arend believes that
> it makes the engine stronger, perhaps by 1 stone.
> 
> (3) It is difficult to understand how it works. I explained in:
> 
> http://mail.gnu.org/archive/html/gnugo-devel/2003-07/msg00161.html
> 
> how to get sgf traces of the functions break_in and block_off.
> These traces show many bizarre moves being tried. This is not
> necessarily bad since the same is true of the tactical
> reading code, which is very reliable.
> 
> But at the very least I would like to see get traces of
> examples where the code works correctly. I have been unable
> to confirm that it does what Arend described in the case of
> the file break_in.sgf.
> 
> I do think we should use it in Gifu. I don't see any reason
> to wait before making a zip file containing a gnugo-3.3.23
> binary and supporting programs to supply to Gifu.
> 
> Dan
> 
> 
> 

Some more details about Gifu. Will gnugo show board position etc. at each move? 
Or should I just turn on the gmp debugging to let the operator know that the 
program works properly? Furthermore, the current CVS doesn't include the SGMP 
patch yet, so at least this patch needs to be added first.

SP Lee