gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnugo-devel] Strategic penalty and invasions


From: Inge Wallin
Subject: [gnugo-devel] Strategic penalty and invasions
Date: Sat, 28 Sep 2002 22:54:45 +0200 (MEST)

There is a function in value_moves.c called strategic_penalty().  The
reason for this function is that the influence module overvalues moves
creating a new group in the opponent's sphere of influence, i.e. an
invasion.  The purpose of the function is to offset this overvaluation
by giving such moves a small penalty.

However, the current implementation of this function has a drawback:
It doesn't differentiate between real invasions and deep incursions
into opponent territory that are still connected to our own stones.
The test 13x13:20 is such an example:

   A B C D E F G H J K L M N
13 . . . . . . A . . . . . . 13
12 . . . . . z z A A . . . . 12
11 . . z z . . . z A . A . . 11
10 . . z B . z + z A + . . . 10
 9 . . . . . . . . . . . . . 9
 8 . z . z . . . A . A . * . 8
 7 . . . + . z + . . + . . . 7
 6 . C . C C z . . A . . . . 6
 5 . y C . x . w . . A w . . 5
 4 . C v v C C + w w w w w . 4
 3 . C C C . C . . w D w D w 3
 2 . . . . . C w . w D D D . 2
 1 . . . . . . . . . D . u . 1
   A B C D E F G H J K L M N

Here we would like to play M8, but that will never happen since M8 is
punished by strategic_penalty().  (It will not happen even if this
problem is fixed, because F5 gets a huge strategic effect for the L5
group, but that is another matter.)

Another case is the monkey jump that Gunnar mentioned just the other
day is never played any more.

I have thought of ways of fixing this, but I can't find an easy one.
My first thought was to see if the move is a EXPAND_TERRITORY_MOVE.
My belief was that such moves are always connected to our own stones,
but that turns out not to be the case.  Real invasions like
3,3-invasions (patterns F6 and F7 in fuseki.db) also generate this
move reason.

My next thought was to write some code or use connection patterns to
see if the move really was connected, but that is both expensive and
complex.

The reason for this mail is that I want to discuss if we should create
a new move reason, INVASION_MOVE.  That would let us handle the two
cases differently.  Perhaps we could also create patterns for common
invasion sequences and clearly label them as such.  The pattern
attribute 'I' is not used and would be intuitive enough.  In most of
the code, we could treat INVASION_MOVE as a EXPAND_TERRITORY_MOVE, but
in some cases, like above, the difference is crucial.

I could do the work, but I don't want to do it if will be turned down
by Dan or Gunnar.  I have wanted to handle invasions for a long time,
and this seems like a good time to do it.

So, what do you say?

    -Inge




reply via email to

[Prev in Thread] Current Thread [Next in Thread]