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

[Arend Bayer]

Gunnar wrote:
> > +Pattern CC83
> > +# ab added (3.1.22)
> > +
> > +..o
> > +O*.
> > +oXO
> > +
> > +:8,C
> > +
> > +..o
> > +O*a
> > +oBO
> > +
> > +;oplay_attack_either(*,a,a,B)
> 
> This pattern is a strict subset of Conn311 in patterns2.db and should
> have no effect whatsoever.

Oops, my fault.

> > - 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.)

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.

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.

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.


I am still interested in any opinions on these matters.


> >  Pattern Shape66
> >  # db increased negative shape (3.1.7)
> > +# ab two ??? lines added as jump is often good on 3rd line
> > +# (seen in many joseki, advertised as "struggle to get ahead" in
> > +# Lessons in the Fundamentals)
> >  
> >  xX.         often bad to leave a gap
> >  O.*
> >  ...
> > +???
> > +???
> 
> The struggle to get ahead can happen anywhere on the board, so the
> main question should be how significant weakness the gap is. Some
> constraint based on moyo/area and the number of liberties of the O
> stone might be useful for a rough heuristic.

Yes, but I would claim that, on the center of the board, either * is some
attacking move, or the keima one line below is better. Also, on the third
line, * can have two reasons, either that X cannot cut, or that O is weak
and is prepared to sacrifice either O or * in exchange for a ponnuki.

I don't think a moyo type heuristic will help. Even if X cannot cut,
the aji left behind is usually not worth the difference between * and
keima.

> >  # 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."

Arend