Re: [gnugo-devel] Recent games

[Arend Bayer]

> > If abandoning a group is done by a move that creates a new group, in the
> > opponent's sphere of influence, then this is an experimental influence
> > fault. I am now back from traveling, and I also have rough idea how to
> > resolve this problem.
> 
> I didn't think this was what was happening in the GoFun games. 
> 
> Could you give some examples of the phenomenon you are describing?
> I think they may be frequent in games where GNU Go gives a 9 stone
> handicap. But generally I think GNU Go is better now at giving
> big handicaps than 3.0.0.

Maybe the phenomenon is not as frequent as I had imagined. nngs1:2 is
a bit of an example, also the 3-3 invasions that your patch took care of
by an increased negative shape value.
The best example I have seen is nngs:900. It is from a 9stone game, but
the mistake is extremely urgent.
Other examples are trevorb:{180,250,370,440} (all very similar).


> Bear in mind that we're approaching the late stage of the
> 3.2 release. We can continue to tune for a while but at
> some point we must stop and freeze the code, fixing only
> bugs and portability issues. So it's important to prioritize now.
> Especially anything that might make it weaker by accident should be
> approached with caution.
Yes, I know I need to be cautious with this. Apart from this patch, I
intended to maybe do some small influence pattern tuning, but nothing else
pre-3.2 that would effect the playing behaviour.

I think I have now a pretty clear idea what I would like to do, so it
should be quick to code. So I think I will just try it out, and if I get
ambigous results, I will postpone it.

> The hashing patch, BTW seems to give about a 5% speedup
> in the testing I did. I think you intended to revise that
> again, per your comments in
> http://mail.gnu.org/pipermail/gnugo-devel/2002-March/001596.html
> and a previous message of Gunnar's. I brought it current with the patch
> hash_1_28.3 once but it may clash with komaster_1_28.1 which is now in the
> CVS. (I haven't checked.)

I think I should do that revision, and I am testing it at the moment.
In particular, it contains a compiler switch to get back to the old
behaviour.

Arend