Re: [gnugo-devel] arend_1_22.2: tuning, regression test, --experimental-influence (fwd)

[Gunnar Farneback]

[Commenting a private copy of a message that never seemed to make it
to the list.]

Arend wrote:
> > > - experimental_influence configure and command line option added (unused)
> > 
> > Do you have any clear plans yet for how to approach this?
> 
> Well, basically along the lines I suggested in 
> http://mail.gnu.org/pipermail/gnugo-devel/2001-December/000715.html.
> 
> My first goal is to get a more precise territorial valuation of moves.
> 
> I have already written a first guess for new_value_territory locally,
> haven't tested it yet, but it does seem to change GNU Go's behaviour
> drastically.
> 
> (It essentially consists of the two lines:
>         float diff = ( q->white_influence[i][j] - q->black_influence[i][j] )
>                     /( q->white_influence[i][j] + q->black_influence[i][j] );
>         q->territory_value[i][j] = diff * diff * diff;
> )
> 
> This already has some interesting effects, whether for the good or for
> the bad I cannot tell yet. (Maybe I will change this formula, but it does
> seem plausible to try to guess a function diff->territory, possibly
> just linearly interpolating between some set values.)

It's probably necessary to have a special case when both influence
values are very small.

> The next thing I want to take care of are some influence-intrinsic
> implementation of followup values. I think there are different ways this
> can be done:
> 
> - giving the played move a lower attenuation in move_influence
> - adding weak influence sources for each keima/iken tobi jump from the
>   played move move_influence
> - compute a separate move_followup_influence. Additionally to the
>   values of move_influence, all B patterns related to the move played
>   get matched. (I haven't considered A and D patterns yet, but I think
>   they should be left as they are to be somewhat conservative.

Sounds reasonable.

> Note: Everything that is done with the played move should also be
> done with saved stones, otherwise GNU Go would drastically undervalue
> saving groups. OTOT, doing this might help to reduce GNU Go's tenuki
> disease.
> 
> What I will have to do additionally is to do some retuning of the
> influence patterns. At the moment, it makes hardly any difference whether
> an influence source of strength 0.3 or 0.6 is added (if the opponent has
> strength there, he will get a moyo in both cases). Also, at the moment,
> e.g. the I patterns seem to have some inconsistencies. What I will have
> to do there can probably go directly in the non-experimental version.

There's certainly much to do there with tuning. I have only tuned it
so far that it avoids the worst strangenesses. One thing to be careful
with is early positions in high handicap games, where placing a stone
in an area where previously only the opponent had stones can cause
huge influence swings.

> I am not sure whether this also applies to the worm_strength factor I
> am considering. The idea is that a worm with too few liberties cannot
> walk freely on the board, so it make sense to reduce its strength. E.g.
> a 3-stone worm that has only 4 liberties (this already means that one
> has to be very concerned about double hane's etc.) would get a factor
> 0.9, with 3 liberties 0.7 etc. Best way to do this is probably a
> hard-coded (size , liberties)-> strength factor array. The permeability
> in the intersections adjacent to such a worm might also be worth
> adjusting.

Yes, might be useful.

> I am still interested in any opinions on these matters.

Go ahead. The influence code has a lot of possibilities but it takes
much experimentation to find out how best to make use of them. 

> > >  # gf New pattern. (3.1.14)
> > > +# The constraint is unprecise, but I don't know how to correct it.
> > > +# (would need !xplay_defend_both ( *, a, X defends against atari,
> > > +# O passes, b,    a, c). -ab
> > 
> > The constraint "language" is too weak for this construction. Currently
> > the only way to solve this is to handwrite a helper. I recently
> > implemented connect_and_cut_helper(), which does exactly what you
> > want, except that * already is assumed to have been played. It may be
> > possible to generalize this helper but it may in turn require some
> > modifications of mkpat.c.
> Well, I don't know the helper functions good enough to judge what is
> the thing to do. I think it would be sufficient to pass to 
> xplay_... an argument saying "If a is attackable, get its defend point
> and play there."

Sure, it would suffice but we have no such mechanism available.

/Gunnar