[gnugo-devel] cutstone

[Gunnar Farnebäck]

In struct worm_data there are two fields called cutstone and
cutstone2. As the names indicate they have something to do with
cutting stones, i.e. strings which are of importance because they keep
the opponent separated. Historically the cutstone field came first
while cutstone2 was introduced to solve certain problems with cutstone
and was planned to replace it entirely, something that never happened.
It is noteworthy that both concepts predate the connection reading
code and it seems likely that we could come up with something better
to replace both of them while simplifying the code base in the
process. The exact use of the cutstone fields has varied over time so
I'll start with a review of how they are defined and used currently.

cutstone:
This is computed on lines 174-227 in worm.c. The code comments say:
   *     A CUTTING STONE is one adjacent to two enemy strings,
   *     which do not have a liberty in common. The most common
   *     type of cutting string is in this situation.
   *  
   *     XO
   *     OX
   *     
   *     A POTENTIAL CUTTING STONE is adjacent to two enemy
   *     strings which do share a liberty. For example, X in:
   *     
   *     XO
   *     O.
   *     
   *     For cutting strings we set worm[m][n].cutstone=2. For potential
   *     cutting strings we set worm[m][n].cutstone=1. For other strings,
   *     worm[m][n].cutstone=0.
   
The current use is
1. worm.c, line 499: Part of the definition of inessential worms.
2. worm.c, lines 1008-1009: Used to choose between multiple worm lunches.
3. dragon.c, line 540-541: Used to choose between multiple dragon lunches.
4. dragon.c, line 1842: Used in the computation of crude_status.
5. value_moves.c, line 1565: Part of heuristics for run-away penalty.

cutstone2:
This is computed during find_cuts(), if called at stackp == 0, through
the pattern CB7 in conn.db and the cutstone2_helper() function.
Basically it looks for potential crosscuts around each string which
would work tactically if the analyzed string was first allowed a
defense move. In particular this gives a high value for a string being
chased in a ladder.

The current use is
6. value_moves.c, line 1566: Part of heuristics for run-away penalty.
7. value_moves.c, line 2407: Strategical bonus for attack/defend if
                             cutstone2>1.
8. patterns.db, line 11319:  Used in the constraint of pattern CD82.


Generally speaking I don't like cutstone because it is way too crude
(notice that it was introduced a very long time ago) and I don't like
cutstone2 because its computation is messy. Also we should really be
able to use the connection reading code to our advantage here, now
that we have it.

Some loose ideas for new cutstone definitions:
A. Count the number of pairs of opponent neighbors which cannot be
   connected.
B. Count the number of pairs of opponent neighbors which can be
   disconnected.
C. Look for crosscut and potential crosscut patterns around a string
   and count in how many of those the opponent already is or can be
   disconnected.

For uses 5-8 the dragon data is available and possibly we could
instead use the hostile_neighbors field of struct dragon_data2 in one
or more of those places. For uses 2 and 3 any cutstone measure should
be good enough. I'm not sure use 4 completely makes sense at all but I
doubt changing it to another cutstone measure would be a problem. I'm
unsure about use 1, although mostly because I'm unsure how the worm
inessentiality definition really works or ought to work.

Comments?

/Gunnar