gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] Strategic penalty and invasions


From: Gunnar Farneback
Subject: Re: [gnugo-devel] Strategic penalty and invasions
Date: Sun, 29 Sep 2002 18:55:58 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Inge wrote:
>    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

These diagrams are rather hard to read and really only useful if you
want to know exactly how the partition into dragons looks. I recommend
that you instead use the gtp showboard command to get a diagram with O
and X. (-l and -L work properly with GTP mode, btw.)

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

As do various kakaris.

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

I have some plans to write a connect_to_something() function in
readconnect.c which would be useful for these purposes, but that's
still in the future.

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

These thoughts are similar to what I and Arend discussed on NNGS a few
days ago.

As background I should add that e and E patterns are currently handled
identically, but this has not always been the case. Once upon a time
the move valuation distinguished between a territorial value and an
influence value. Then e patterns enabled the territorial valuation and
E patterns the influence valuation (somewhat simplified). This
distinction was not very useful and has been removed.

Today it would be more useful to reserve e classification for moves
which are safely connected to an already alive dragon. Then we could
use E and/or I for the other patterns which today have an e or E
classification. It remains to discuss whether we need both E and I
patterns and exactly what those would mean.

> 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?

Generally speaking it sounds in line with what I'm been thinking.
Maybe you could say something more about what semantics you have in
mind for I patterns.

/Gunnar




reply via email to

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