This is gnugo.info, produced by makeinfo version 4.0b from gnugo.texi.

INFO-DIR-SECTION GNU games
START-INFO-DIR-ENTRY
* GNU go: (gnugo).          The GNU Go program
END-INFO-DIR-ENTRY


File: gnugo.info,  Node: Influence Usage,  Next: Influence and Territory,  Prev: Influential Concepts,  Up: Influence

Where influence gets used in the engine
=======================================

   The information obtained from the influence computation is used in a
variety of places in the engine, and the influence module is called
several times in the process of the move generation. The details of the
influence computation vary according to the needs of the calling
function.

   After GNU Go has decided about the tactical stability of strings, the
influence module gets called the first time. Here all lively stones act
as an influence source of default strength 100. The result is stored in
the variables `initial_influence' and `initial_opposite_influence', and
it is used as an important information for guessing the strength of
dragons. For example, a dragon that is part of a moyo of size 25 is
immediately considered alive.  For dragons with a smaller moyo size, a
life-and-death analysis will be done by the owl code (see *Note Life
and Death Reading::). A dragon with a moyo size of only 5 will be
considered weak, even if the owl code has decided that it cannot be
killed.

   As a tool for the owl code, an "escape" influence gets computed for
each dragon going through the life-and-death analysis (*Note Escape::).

   Once all dragons have been evaluated, the influence module is called
again and the variables `initial_influence' and
`initial_opposite_influence' get overwritten. Of course, the dragon
status', which are available now, are taken into account. Stones
belonging to a dead dragon will not serve as an influence source, and
the strengths of other stones get adjusted according to the strength of
their respective dragon.

   The result of this run is the most important tool for move
evaluation. All helper functions of patterns as explained in *Note
Patterns:: that refer to influence results (e. g. `olib(*)' etc.)
actually use these results. More important, `initial_influence' serves
as the reference for computing the territorial value of a move. That
is, from the influence strengths stored in `initial_influence', a
territory value is assigned to each intersection. This value is
supposed to estimate the likelyhood that this intersection will become
white or black territory.

   Then, for each move that gets considered in the function
`value_moves', the influence module is called again via the function
`compute_move_influence' to assess the likely territorial balance after
this move, and the result is compared with the state before that move.

   There are a number of changes from 3.0 to 3.2 in these influence
computations relevant for territorial evaluation. Also, now an
additional influence computation is done in order to compute the
followup value of a move. Some explainations are in *Note Territorial
Details::.


File: gnugo.info,  Node: Influence and Territory,  Next: Territorial Details,  Prev: Influence Usage,  Up: Influence

Influence and Territory
=======================

   In this section we consider how the influence function is used to
estimate territory in the function `estimate_territorial_value()'.

   A move like `*' by `O' below is worth one point:

     OXXX.
     OX.XX
     O*a.X
     OX.XX
     OXXX.

   This is evaluated by the influence function in the following way: We
first assign territory under the assumption that X moves first in all
local positions in the original position;  then we reassing territory,
again under the assumption that `X' moves first in all local positions,
but after we let `O' make the move at `*'. These two territory
assignments are compared and the difference gives the territorial value
of the move.

   Technically, the assumption that `X' plays first everywhere is
implemented via an asymmetric pattern database in `barriers.db'.  What
exactly is a safe connection that stops hostile influence from passing
through is different for `O' and `X'; of course such a connection has
to be tighter for stones with color `O'. Also, additional intrusion
influence sources are added for `X' in places where `X' stones have
natural followup moves.

   In this specific example above, the asymmetry (before any move has
been made) would turn out as follows: If `X' is in turn to move, the
white influence would get stopped by a barrier at `*', leaving 4 points
of territory for `X'.  However, if `O' was next to move, then a
followup move for the white stones at the left would be assumed in the
form of an extra ("intrusion") influence source at `*'. This would get
stopped at `a', leaving three points of territory.

   Returning to the valuation of a move by `O' at `*', we get a value
of 1 for the move at `*'.  However, of course this move is sente once
it is worth playing, and should therefore (in miai counting) be awarded
an effective value of 2. Hence we need to recognize the followup value
of a move. GNU Go 3.0 took care of this by using patterns in
`patterns.db' that enforced an explicit followup value. Version 3.2
instead computes a seperate followup influence to each move considered.
In the above example, an intrusion source will be added at `a' as a
followup move to `*'. This destroys all of Black's territory and hence
gives a followup value of 3.

   The pattern based followup value are still needed at some places,
however.

   To give another example, consider this position where we want to
estimate the value of an `O' move at `*':

     OOOXXX
     ..OX..
     ..OX..
     ...*..
     ------

   Before the move we assume `X' moves first in the local position (and
that `O' has to connect), which gives territory like this (lower case
letter identify territory for each player):

     OOOXXX
     ooOXxx
     o.OXxx
     o...xx
     ------

   Then we let `O' make the move at `*' and assume `X' moves first
again next.  The territory then becomes (`X' is also assumed to have to
connect):

     OOOXXX
     ooOXxx
     ooOX.x
     oo.O.x
     ------

   We see that this makes a difference in territory of 4, which is what
influence_delta_territory() should report. Then again, we have followup
value, and here also a reverse followup value. The reverse followup
value, which in this case will be so high that the move is treated as
reverse sente, is added by an explicit pattern. Other sources for
followup or reverse followup values are threats to capture a rescue a
string of stones.  See the code and comments in the function
`value_move_reaons' for how followup and reverse followup values are
used to adjust the effective move value.

   To give an example of territorial value where something is captured,
consider the `O' move at `*' here,

     XXXXXXXO
     X.OOOOXO
     X.O..O*O
     --------

   As before we first let the influence function determine territory
assuming X moves first, i.e. with a captured group:

     XXXXXXXO
     XxyyyyXO
     Xxyxxy.O
     --------

   Here `y' indicates `X' territory + captured stone, i.e. these count
for two points. After the `O' move at `*' we instead get

     XXXXXXXO
     X.OOOOXO
     X.OooOOO
     --------

   and we see that `X' has 16 territory fewer and `O' has two territory
more, for a total difference of 18 points.

   That the influence function counts the value of captured stones is
new in GNU Go 3.2.. Previously this was instead done using the
effective_size heuristic. The effective size is the number of stones
plus the surrounding empty spaces which are closer to this string or
dragon than to any other stones. Here the `O' string would thus have
effective size 6 (number of stones) + 2 (interior eye) + 2*0.5 (the two
empty vertices to the left of the string, split half each with the
surrounding X string) + 1*0.33 (the connection point, split between
three strings) = 9.33. As noted this value was doubled, giving 18.67
which is reasonably close to the correct value of 18. The effective size
heuristic is still used in certain parts of the move valuation where we
can't easily get a more accurate value from the influence function (e.
g. attacks depending on a ko, attack threats).

   Note that this section only describes the territorial valuation of a
move.  Apart from that, GNU Go uses various heuristics in assigning a
strategical value (weakening and strengthening of other stones on the
board) to a move.  Also, the influence function isn't quite as well
tuned as the examples above may seem to claim. But it should give a
fairly good idea of how the design is intended.

   Another matter is that so far we have only considered the change in
secure territory. GNU Go 3.2 uses a revised heuristic, which is
explained in the next section, to assign probable territory to each
player.


File: gnugo.info,  Node: Territorial Details,  Next: The Influence Core,  Prev: Influence and Territory,  Up: Influence

Details of the Territory Valuation
==================================

   This section explains how GNU Go assigns a territorial value to an
intersection once the white and black influence have been computed.
The intention is that an intersection that has a chance of xx% of
becoming white territory is counted as 0.xx points of territory for
white, and similar for black.

   The algorithm in the function `new_value_territory' goes roughly as
follows:

   If `wi' is the white influence at a point, and `bi' the black
influence, then ` value = ( (wi-bi)/ (wi+bi) )^3' (positive values
indicates likley white territory, negative stand for black territory)
turns out to be very simple first guess that is still far off, but
reasonable enough to be useful.

   This value is then suspect a number of corrections. Assume that this
first guess resulted in a positive value.

   If both `bi' and `wi' are small, it gets reduced. What exactly is
"small" depends on whether the intersection is close to a corner or an
edge of the board, since it is easier to claim territory in the corner
than in the center.

   Then the value at each intersection is degraded to the minimum value
of its neighbors. This can be seen as a second implementation of the
proverb saying that there is no territory in the center of the board.
This step substantially reduces the size of spheres of territory that
are open at several sides.

   Finally, there are a number of patterns that explicitly forbid GNU
Go to count territory at some intersections. This is used e. g. for
false eyes that will eventually have to be filled in. Also, points for
prisoners are added.

   To fine tune this scheme, some revisions have been made to the
influence computations that are relevant for territorial evaluation.
This includes a reduced default attenuation and some revised pattern
handling.


File: gnugo.info,  Node: The Influence Core,  Next: The Influence Algorithm,  Prev: Territorial Details,  Up: Influence

The Core of the Influence Function
==================================

   The basic influence radiation process can efficiently be implemented
as a breadth first search for adjacent and more distant points, using a
queue structure.

   Influence barriers can be found by pattern matching, assisted by
reading through constraints and/or helpers. Wall structures, invasion
points and intrusion points can be found by pattern matching as well.

   When influence is computed, the basic idea is that there are a number
of influence sources on the board, whose contributions are summed to
produce the influence values. For the time being we can assume that the
living stones on the board are the influence sources, although this is
not the whole story.

   The function `compute_influence()' contains a loop over the board,
and for each influence source on the board, the function
`accumulate_influence()' is called. This is the core of the influence
function. Before we get into the details, this is how the influence
field from a single isolated influence source of strength 100 turns out
(with an attenuation of 3.0):

       0  0  0  0  0  0  0  0  0  0  0
       0  0  0  0  1  1  1  0  0  0  0
       0  0  0  1  2  3  2  1  0  0  0
       0  0  1  3  5 11  5  3  1  0  0
       0  1  2  5 16 33 16  5  2  1  0
       0  1  3 11 33  X 33 11  3  1  0
       0  1  2  5 16 33 16  5  2  1  0
       0  0  1  3  5 11  5  3  1  0  0
       0  0  0  1  2  3  2  1  0  0  0
       0  0  0  0  1  1  1  0  0  0  0
       0  0  0  0  0  0  0  0  0  0  0

   These values are in reality floating point numbers but have been
rounded down to the nearest integer for presentation. This means that
the influence field does not stop when the numbers become zeroes.

   Internally `accumulate_influence()' starts at the influence source
and spreads influence outwards by means of a breadth first propagation,
implemented in the form of a queue. The order of propagation and the
condition that influence only is spread outwards guarantee that no
intersection is visited more than once and that the process terminates.
In the example above, the intersections are visited in the following
order:

       +  +  +  +  +  +  +  +  +  +  +
       + 78 68 66 64 63 65 67 69 79  +
       + 62 46 38 36 35 37 39 47 75  +
       + 60 34 22 16 15 17 23 43 73  +
       + 58 32 14  6  3  7 19 41 71  +
       + 56 30 12  2  0  4 18 40 70  +
       + 57 31 13  5  1  8 20 42 72  +
       + 59 33 21 10  9 11 24 44 74  +
       + 61 45 28 26 25 27 29 48 76  +
       + 77 54 52 50 49 51 53 55 80  +
       +  +  +  +  +  +  +  +  +  +  +

   The visitation of intersections continues in the same way on the
intersections marked '`+' and further outwards. In a real position
there will be stones and tight connections stopping the influence from
spreading to certain intersections. This will disrupt the diagram
above, but the main property of the propagation still remains, i.e. no
intersection is visited more than once and after being visited no more
influence will be propagated to the intersection.


File: gnugo.info,  Node: The Influence Algorithm,  Next: Permeability,  Prev: The Influence Core,  Up: Influence

The Core of the Influence Function
==================================

   While most of the engine uses the one dimensional board (*note The
Board::) the two dimensional board is still used in
`engine/influence.c'.

   Let `(m, n)' be the coordinates of the influence source and `(i, j)'
the coordinates of a an intersection being visited during propagation,
using the same notation as in the `accumulate_influence()' function.
Influence is now propagated to its eight closest neighbors, including
the diagonal ones, according to the follow scheme:

   For each of the eight directions `(di, dj)', do:

  1. Compute the scalar product `di*(i-m) + dj*(j-n)' between the
     vectors `(di,dj)' and `(i,j) - (m,n)'

  2. If this is negative or zero, the direction is not outwards and we
     continue with the next direction. The exception is when we are
     visiting the influence source, i.e. the first intersection, when
     we spread influence in all directions anyway.

  3. If `(i+di, j+dj)' is outside the board or occupied we also
     continue with the next direction.

  4. Let S be the strength of the influence at `(i, j)'. The influence
     propagated to `(i+di, j+dj)' from this intersection is given by
     `P*(1/A)*D*S', where the three different kinds of damping are:

        * The permeability `P', which is a property of the board
          intersections. Normally this is one, i.e. unrestricted
          propagation, but to stop propagation through e.g. one step
          jumps, the permeability is set to zero at such intersections
          through pattern matching. This is further discussed below.

        * The attenuation `A', which is a property of the influence
          source and different in different directions. By default this
          has the value 3 except diagonally where the number is twice
          as much. By modifying the attenuation value it is possible to
          obtain influence sources with a larger or a smaller effective
          range.

        * The directional damping `D', which is the squared cosine of
          the angle between `(di,dj)' and `(i,j) - (m,n)'. The idea is
          to stop influence from "bending" around an interfering stone
          and get a continuous behavior at the right angle cutoff. The
          choice of the squared cosine for this purpose is rather
          arbitrary, but has the advantage that it can be expressed as a
          rational function of `m', `n', `i', `j', `di', and `dj',
          without involving any trigonometric or square root
          computations. When we are visiting the influence source we
          let by convention this factor be one.

   Influence is typically contributed from up to three neighbors
"between" this intersection and the influence source. These values are
simply added together. As pointed out before, all contributions will
automatically have been made before the intersection itself is visited.

   When the total influence for the whole board is computed by
`compute_influence()', `accumulate_influence()' is called once for each
influence source. These invocations are totally independent and the
influence contributions from the different sources are added together.


File: gnugo.info,  Node: Permeability,  Next: Escape,  Prev: The Influence Algorithm,  Up: Influence

Permeability
============

   The permeability at the different points is initially one at all
empty intersections and zero at occupied intersections. To get a useful
influence function we need to modify this, however. Consider the
following position:

     |......
     |OOOO..
     |...O..
     |...a.X   ('a' empty intersection)
     |...O..
     |...OOO
     |.....O
     +------

   The corner is of course secure territory for `O' and clearly the `X'
stone has negligible effect inside this position. To stop `X' influence
from leaking into the corner we use pattern matching (pattern
Barrier1/Barrier2 in `barriers.db') to modify the permeability for `X'
at this intersection to zero. `O' can still spread influence through
this connection.

   Another case that needs to be mentioned is how the permeability
damping is computed for diagonal influence radiation. For horizontal
and vertical radiation we just use the permeability (for the relevant
color) at the intersection we are radiating from. In the diagonal case
we additionally multiply with the maximum permeability at the two
intersections we are trying to squeeze between. The reason for this can
be found in the diagram below:

     |...X    |...X
     |OO..    |Oda.
     |..O.    |.bc.
     |..O.    |..O.
     +----    +----

   We don't want `X' influence to be spread from `a' to `b', and since
the permeability at both c and d is zero, the rule above stops this.


File: gnugo.info,  Node: Escape,  Next: Influential Patterns,  Prev: Permeability,  Up: Influence

Escape
======

   One application of the influence code is in computing the
`dragon.escape_route' field. This is computed by the function
`compute_escape()' as follows.  First, every intersection is assigned
an escape value, ranging between 0 and 4, depending on the influence
value of the opposite color.

   In addition to assiging an escape value to empty vertices, we also
assign an escape value to friendly dragons. This value can range from 0
to 6 depending on the status of the dragon, with live dragons having
value 6.

   Then we sum the values of the resulting influence escape values over
the intersections (including friendly dragons) at distance 4, that is,
over those intersections which can be joined to the dragon by a path of
length 4 (and no shorter path) not passing adjacent to any unfriendly
dragon. In the following example, we sum the influence escape value
over the four vertices labelled '4'.


        . . . . . . . . .    . . . . . . . . .
        . . . . . X . . O    . . . . . X . . O
        . . X . . . . . O    . . X . 2 . 4 . O
        X . . . . . . . .    X . . 1 1 2 3 4 .
        X O . O . . . . O    X O 1 O 1 2 3 4 O
        X O . O . . . . .    X O 1 O 1 . 4 . .
        X O . . . X . O O    X O 1 . . X . . O
        . . . X . . . . .    . 1 . X . . . . .
        X . . . . X . . .    X . . . . X . . .
        . . . . . . . . .    . . . . . . . . .

   Since the dragon is trying to reach safety, the reader might wonder
why `compute_influence()' is called with the opposite color of the
dragon contemplating escape.  To explain this point, we first remind
the reader why there is a color parameter to `compute_influence()'.
Consider the following example position:

          ...XX...
          OOO..OOO
          O......O
          O......O
          --------

   Whether the bottom will become O territory depends on who is in turn
to play. This is implemented with the help of patterns in barriers.db,
so that X influence is allowed to leak into the bottom if X is in turn
to move but not if O is. There are also "invade" patterns which add
influence sources in sufficiently open parts of the board which are
handled differently depending on who is in turn to move.

   In order to decide the territorial value of an O move in the third
line gap above, influence is first computed in the original position
with the opponent (i.e. X) in turn to move. Then the O stone is played
to give:


          ...XX...
          OOO.OOOO
          O......O
          O......O
          --------

   Now influence is computed once more, also this time with X in turn to
move. The difference in territory (as computed from the influence
values) gives the territorial value of the move.

   Exactly how influence is computed for use in the escape route
estimation is all ad hoc. But it makes sense to assume the opponent
color in turn to move so that the escape possibilities aren't
overestimated. After we have made a move in the escape direction it is
after all the opponent's turn.

   The current escape route mechanism seems good enough to be useful
but is not completely reliable. Mostly it seems to err on the side of
being too optimistic.


File: gnugo.info,  Node: Influential Patterns,  Next: Influential Functions,  Prev: Escape,  Up: Influence

Patterns used by the Influence module
=====================================

   This section explains the details of the pattern databases used for
the influence computation.

   First, we have the patterns in `influence.db', which get matched
symmetrically for both colors.

   * `E'
          These patterns add extra influence sources close to some
          shapes like walls.  This tries to reflect their extra
          strength. These patterns are not used in the influence
          computations relevant for territory valuations, but they are
          useful for getting a better estimate of strengths of groups.

   * `I'
          These patterns add extra influence sources at typical
          invasion points.  Usually they are of small strength. If they
          additionally have the class `s', the extra influence source
          is added for both colors. Otherwise, only the player assumed
          to be next to move gets the benefit.

   The patterns in `barriers.db' get matched only for `O' being the
player next to move.

   * `A'
          Connections between `X' stones that stop influence of `O'.
          They have to be tight enough that `O' cannot break through,
          even though he is allowed to move first.

   * `D'
          Connections between `O' stones that stop influence of `X'. The
          stones involved can be more loosely connected than those in
          `A' patterns.

   * `B'
          These indicate positions of followup moves for the `O' stone
          marked with `Q' in the pattern. They are used to reduce the
          territory e. g.  where a monkey jump is possible. Also, they
          are used in the computation of the followup influence, if the
          `Q' stone was the move played (or a stone saved by the move
          played).

   * `t'
          These patterns indicate intersections where one color will
          not be able to get territory, for example in a false eye. The
          points are set with a call to the helper non_oterritory or
          non_xterritory in the action of the pattern.

   The intrusion patterns (`B') are more powerful than the description
above might suggest. They can be very helpful in identifying weak shapes
(by adding an intrusion source for the opponent where he can break
through).  A negative inference for this is that a single bad `B'
pattern, e. g.  one that has a wrong constraint, typically causes 5 to
10 `FAIL's in the regression test suite.

   Influence Patterns can have autohelper constraints as usual. As for
the constraint attributes, there are (additionally to the usual ones
`O', `o', `X' and `x'), attributes `Y' and `FY'. A pattern marked with
`Y' will only be used in the influence computations relevant for the
territory valuation, while `FY' patterns only get used in the other
influence computations.

   The action of an influence pattern is at the moment only used for
non-territory patterns as mentioned above, and as a workaround for a
problem with `B' patterns in the followup influence.

   To see why this workaround is necessary, consider the follwoing
situation:


     ..XXX
     .a*.O
     .X.O.
     ..XXO

   (Imagine that there is `X' territory on the left.)

   The move by `O' at `*' has a natural followup move at `a'.  So, in
the computation of the followup influence for `*', there would be an
extra influence source for `O' at `a' which would destroy a lot of
black territory on the left. This would give a big followup value, and
in effect the move `*' would be treated as sente.

   But of course it is gote, since `X' will answer at `a', which both
stops the possible intrusion and  threatens to capture `*'. This
situation is in fact quite common.

   Hence we need an additional constraint that can tell when an
intrusion pattern can be used in followup influence. This is done by
misusing the action line: An additional line

     >return <condition>;

   gets added to the pattern. The `condition' should be true if the
intrusion cannot be stopped in sente. In the above example, the relevant
intrusion pattern will have an action line of the form

     >return (!xplay_attack(a,b));

   where `b' refers to the stone at `*'. In fact, almost all
followup-specific constraints look similar to this.


File: gnugo.info,  Node: Influential Functions,  Next: Influential Display,  Prev: Influential Patterns,  Up: Influence

Influential Functions
=====================

   * `static void accumulate_influence(struct influence_data *q, int m,
     int n, int color)'
          Limited in scope to `influence.c', this is the core of the
          influence function. Given the coordinates and color of an
          influence source, it radiates the influence outwards until it
          hits a barrier or the strength of the influence falls under a
          certain threshold. The radiation is performed by a breadth
          first propagation, implemented by means of an internal queue.

   * `void add_influence_source(int pos, int color, float strength,
     float attenuation, struct influence_data *q)'
          Adds an influence source at position pos with prescribed
          strength and attenuation. color can be `BLACK', `WHITE' or
          both. If there already exists an influence source of the
          respective color at pos that is stronger than the new one, we
          do nothing.

   * `void influence_mark_non_territory(int pos, int color)'
          Called from actions for t patterns. Marks `pos' as not being
          territory for `color'.

   * `int influence_get_moyo_size(int pos, int color)'
          Return the size of the moyo around `pos'.

   * `void influence_get_moyo_segmentation(int opposite, struct
     moyo_data *moyos)'
          Export the moyo segmentation. If `opposite' is true, then
          initial_opposite_influence is used, otherwise
          initial_influence.

   * `void compute_initial_influence(int color, int dragons_known)'
          Compute the influence before a move has been made, which can
          later be compared to the influence after a move. Assume that
          the other color is in turn to move.

   * `void resegment_initial_influence()'
          Redo the segmentation of the initial influence.

   * `void compute_escape_influence(char goal[BOARDMAX], int color, int
     escape_value[BOARDMAX], int dragons_known)'
          Assume that the stones marked by the goal array do not
          generate influence and compute influence. Influence based
          escape values are returned in the escape_value array.

   * `int influence_territory_color(int pos)'
          Return the color who has territory at `pos', or `EMPTY'.

   * `int influence_moyo_color(int pos)'
          Return the color who has moyo at `pos', or EMPTY.

   * `int influence_moyo_color_opposite(int pos)'
          Return the color who has moyo at `pos', or EMPTY, using
          influence computed with the opposite color to move.

   * `int influence_area_color(int pos)'
          Return the color who has area at `pos', or EMPTY.

   * `float influence_delta_territory(int pos, int color, char
     saved_stones[BOARDMAX], float *followup_value)'
          Compute the difference in territory made by a move by color
          at `pos'.  This also includes the changes in moyo and area.
          In experimental-influence mode, followup_value must not be a
          NULL pointer, and the followup_value will be returned there.

   * `float influence_estimate_score(float moyo_coeff, float
     area_coeff)'
          Estimate the score. A positive value means white is ahead. The
          score is estimated from the initial_influence, which must
          have been computed in advance. The score estimate does not
          include captured stones (i.e., the ones having been removed
          from the board) or komi.  moyo_coeff and area_coeff are the
          relative weights to be used for the moyo and area difference
          respectively.

   * `void debug_influence_move(int i, int j)'
          Print the influence map when we have computed influence for
          the move at `(i, j)'.

   * `void get_initial_influence(int color, int dragons_known, float
     white_influence[BOARDMAX], float black_influence[BOARDMAX], int
     influence_regions[BOARDMAX])'
          Compute initial influence and export it. The color parameter
          tells who is in turn to move.

   * `void get_move_influence(int move, int color, char
     saved_stones[BOARDMAX], float white_influence[BOARDMAX], float
     black_influence[BOARDMAX], int influence_regions[BOARDMAX])'
          Compute influence after a move and export it.

   * `void print_initial_influence(int color, int dragons_known)'
          Compute initial influence and print it. Notice that it's
          assumed that the printmoyo global tells what information to
          print. The color parameter tells who is in turn to move.

   * `void print_move_influence(int pos, int color, char
     saved_stones[BOARDMAX])'
          Compute influence after doing a move and print it. Notice
          that it's assumed that the printmoyo global tells what
          information to print.


File: gnugo.info,  Node: Influential Display,  Prev: Influential Functions,  Up: Influence

Colored display and debugging of influence
==========================================

   There are various ways to obtain detailed information about the
influence computations. Colored diagrams showing influence are possible
from a colored xterm or rxvt window.

   There are two options controlling when to generate diagrams:

   * `-m 0x08' or `-m 8'
          Show diagrams for the initial influence computation. This is
          done twice, the first time before `make_dragons()' is run and
          the second time after. The difference is that dead dragons
          are taken into account the second time. Tactically captured
          worms are taken into account both times.

   * `--debuginfluence LOCATION'
          Show influence diagrams after the move at the given location.
          An important limitation of this option is that it's only
          effective for moves that the move generation is considering.

   The other options control which diagrams should be generated in these
situations. You have to specify at least one of the options above and
at least one of the options below to generate any output.

   * `-m 0x010' or `-m 16'
          Show colored display of territory/moyo/area regions.
             - territory: cyan

             - moyo: yellow

             - area: red
          This feature is very useful to get an immediate impression of
          the influence regions as GNU Go sees them.

   * `-m 0x20' or `-m 32'
          Show numerical influence values for white and black. These
          come in two separate diagrams, the first one for white, the
          second one for black. Notice that the influence values are
          represented by floats and thus have been rounded in these
          diagrams.

   * `-m 0x40' or `-m 64'
          This generates two diagrams showing the permeability for
          black and white influence on the board.

   * `-m 0x80' or `-m 128'
          This shows the strength of the influence sources for black
          and white across the board. You will see sources at each
          lively stone (with strength depending on the strength of this
          stone), and sources contributed by patterns.

   * `-m 0x100' or `-m 256'
          This shows the attenuation with which the influence sources
          spread influence across the board. Low attenuation indicates
          far-reaching influence sources.

   * `-m 0x200' or `-m 512'
          This shows the territory valuation of GNU Go. Each
          intersection is shown with a value between -1.0 and +1.0 (or
          -2 resp. +2 if there is a dead stone on this intersection).
          Positive values indicate territory for white. A value of -0.5
          thus indicates a point where black has a 50% chance of
          getting territory.

   Finally, there is the debug option `-d 0x1' which turns on on
`DEBUG_INFLUENCE'. This gives a message for each influence pattern that
gets matched. Unfortunately, these are way too many messages making it
tedious to navigate the output. However, if you discover an influence
source with `-m 0x80' that looks wrong, the debug output can help you
to quickly find out the responsible pattern.


File: gnugo.info,  Node: Moyo,  Next: Utility Functions,  Prev: Influence,  Up: Top

Moyo
****

* Menu:

* Moyo history::		History of `moyo.c' and `score.c'
* Bouzy::                       Bouzy's algorithm

   The file `score.c' contains algorithms for the computation of a
number of useful things. Most can be displayed visually using the `-m'
option (*note Colored Display::).


File: gnugo.info,  Node: Moyo history,  Next: Bouzy,  Prev: Moyo,  Up: Moyo

Moyo history
============

   In GNU Go 2.6 extensive use was made of an algorithm from Bruno
Bouzy's dissertation, which is available at:
<ftp://www.joy.ne.jp/welcome/igs/Go/computer/bbthese.ps.Z> This
algorithm starts with the characteristic function of the live groups on
the board and performs `n' operations called dilations, then `m'
operations called erosions.  If n=5 and m=21 this is called the 5/21
algorithm.

   The Bouzy 5/21 algorithm is interesting in that it corresponds
reasonably well to the human concept of territory.  This algorithm is
still used in GNU Go 3.2 in the function `estimate_score'. Thus we
associate the 5/21 algorithm with the word "territory". Similarly we
use words "moyo" and "area" in reference to the 5/10 and 4/0
algorithms, respectively.

   The principle defect of the algorithm is that it is not tunable. The
current method of estimating moyos and territory is in `influence.c'
(*note Influence::). The territory, moyo and area concepts have been
reimplemented using the influence code.

   The Bouzy algorithm is briefly reimplemented in the file `scoring.c'
and is used by GNU Go 3.2 in estimating the score.

   Not all features of the old `moyo.c' from GNU Go 2.6 were
reimplemented--particularly the deltas were not--but the
reimplementation may be more readable.


File: gnugo.info,  Node: Bouzy,  Prev: Moyo history,  Up: Moyo

Bouzy's 5/21 algorithm
======================

   Bouzy's algorithm was inspired by prior work of Zobrist and ideas
from computer vision for determining territory. This algorithm is based
on two simple operations, DILATION and EROSION. Applying dilation 5
times and erosion 21 times determines the territory.

   To get a feeling for the algorithm, take a position in the early
middle game and try the colored display using the `-m 1' option in an
RXVT window. The regions considered territory by this algorithm tend to
coincide with the judgement of a strong human player.

   Before running the algorithm, dead stones (`dragon.status==0') must
be "removed."

   Referring to page 86 of Bouzy's thesis, we start with a function
taking a high value (ex : +128 for black, -128 for white) on stones on
the goban, 0 to empty intersections. We may iterate the following
operations:

   "dilation": for each intersection of the goban, if the intersection
is `>= 0', and not adjacent to a `< 0' one, then add to the intersection
the number of adjacent >0 intersections. The same for other color : if
the intersection is `<= 0', and not adjacent to a `> 0' one, then
subtract the number of `< 0' intersections.

   "erosion": for each intersection `> 0' (or `< 0'), subtract (or add)
the number of adjacent `<= 0' (or `>= 0') intersection. Stop at zero.
The algorithm is just : 5 dilations, then 21 erosions. The number of
erosions should be 1+n(n-1) where n=number of dilation, since this
permit to have an isolated stone to give no territory. Thus the couple
4/13 also works, but it is often not good, for example when there is
territory on the 6th line.

   For example, let us start with a tobi.


                128    0    128

   1 dilation :


                 1          1
     
            1   128    2   128   1
     
                 1          1

   2 dilations :


                 1          1
     
            2    2     3    2    2
     
        1   2   132    4   132   2   1
     
            2    2     3    2    2
     
                 1          1

   3 dilations :


                 1          1
     
            2    2     3    2    2
     
        2   4    6     6    6    4   2
     
     1  2   6   136    8   136   6   2   1
     
        2   4    6     6    6    4   2
     
            2    2     3    2    2
     
                 1          1

   and so on...

   Next, with the same example

   3 dilations and 1 erosion :


                  2     2     2
     
         0   4    6     6     6    4
     
     0   2   6   136    8    136   6    2
     
         0   4    6     6     6    4
     
                  2     2     2

   3 dilations and 2 erosions :


                      1
     
           2    6     6     6    2
     
           6   136    8    136   6
     
           2    6     6     6    2
     
                      1

   3 dil. / 3 erosions :


                5     6     5
     
           5   136    8    136   5
     
                5     6     5

   3/4 :


               3     5     3
     
           2  136    8    136   2
     
               3     5     3

   3/5 :


               1     4     1
     
              136    8    136
     
               1     4     1

   3/6 :


                     3
     
              135    8    135
     
                     3

   3/7 :


              132    8    132

   We interpret this as a 1 point territory.


File: gnugo.info,  Node: Utility Functions,  Next: Incremental Board,  Prev: Moyo,  Up: Top

Utility Functions
*****************

   In this Chapter, we document some of the utilities which may be
called from the GNU Go engine. If there are differences between this
documentation and the source files, the source files are the ultimate
reference. You may find it convenient to use Emacs' built in facility
for navigating the source to find functions and their in-source
documentation (*note Navigating the Source::).

* Menu:

* General Utilities::              Utilities from `engine/utils.c'
* Print Utilities::              Utilities from `engine/printutils.c'

