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: Wed, 02 Oct 2002 19:01:03 +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)

Dan wrote:
> If I understand you e/E/I is a pattern classification

Yes.

> but there would be a corresponding field in move_data.

Currently e and E pattern generate move reasons EXPAND_TERRITORY_MOVE
and EXPAND_MOYO_MOVE respectively. The simplest extension would be to
add an INVASION_MOVE move reason to use for I patterns. It's possible
that it would be advantageous to instead handle this with a field in
the move_data struct. A potential disadvantage is that we might want
to record which dragon an e move is supposed to be connected to. That
is easier to do with move reasons.

I wrote:
> I propose the following scheme:
> e: extending moves which are safely connected to a living dragon.
> E: loose moves which extend from a living dragon without a safe connection
> I: invasion moves without direct support from own living stones

It is maybe not clear how to distinguish between E and I. My current
thought is that while E moves may be possible to cut, the opponent
should not be expected to want to, e.g. because he would get a weak
group in our zone of influence. A typical example is a longish jump
towards the center to build moyo.

An I move can of course be a deep invasion into enemy area with no
nearby friendly stones at all but it can also have some support from
friendly stones which the opponent can easily cut off. A typical
example would be a 3-3 invasion with support from a low kakari like
this: 

|.............
|...X.........
|.............
|...X.....O...
|..*..O.......
|.............
|.............
+-------------

/Gunnar




reply via email to

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