gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] Owl mistake and thrashing dragons.


From: Gunnar Farneback
Subject: Re: [gnugo-devel] Owl mistake and thrashing dragons.
Date: Mon, 20 Jan 2003 20:57:31 +0100
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:
> At least the thrashing dragons are found in each case, and B is
> known to be ahead. The problem is that the steps that are taken

There seems to be a couple of problems both with the implementation
and the heuristics used to find a move.

> One thing is that in genmove.c, revise_thrashing_dragon is not
> called if a move bigger than 10 points is found on the board.
> This may be something we want to change.

Yes, 10 points seems somewhat low if both the lead and the dragon are
largish.

> This is not the problem at move 220. Unfortunately revise_thrashing_dragon
> only revises the status of the single stone at P7, which is not
> amalgamated with the big dragon.

It would probably be better to have a boardsized array marking all
thrashing stones rather than a single dragon pointer. If the last move
played is part of a dead dragon which neighbors another dead dragon of
the same color, it seems natural to mark both dragons as thrashing.

> But if you change the thrashing dragon to R13 and ask to generate a
> move, GNU comes up with P14, relevant to the big dragon but not
> effective as an attack.

The move valuation doesn't work as intended after the status revision
of the thrashing dragon. For example points are awarded for tactical
attack threats (such as P14 if R13 is considered as thrashing) but not
at all for actual tactical attacks (such as Q7). Furthermore, and
somewhat related to the previous problem, the territorial evaluation
often fails badly due to interference from caching in the influence
code. 

> I think the real revisions to fix this problem will be in
> value_moves.c. For one thing,estimate_strategical_value()
> should handle STRATEGIC_ATTACK_MOVE's against thrashing dragons
> more aggressively. At move 220, no such moves are found,
> however. Perhaps we should have some 'a' patterns which are
> ONLY matched if there is a thrashing dragon in the pattern.

What kind of pattern are you thinking about here?

Something to discuss is what moves are effective for restraining
thrashing dragons. Suggestions:

1. Moves to limit access to largish open areas which might give
potential for eyes. It is also good practice to keep the thrashing
dragon out of large territories in case it should survive. This idea
is in principle implemented by the revision of thrashing dragon
status, but it isn't working well as discussed above.

2. Moves to connect surrounding strings. This is partially overlapping
with 1. This is implemented and I believe it usually works well, with
the notable exception of move 230 at T6 in the Temnik game. Generally
it may be useful to connect also to inessential strings but apparently
we should check whether it has any effect on the eye potential.

3. Moves to cut the thrashing stones into smaller pieces. This is not
implemented today at all.

4. Moves to eliminate owl defense threats. This is implemented today
and is to some extent the basis of the thrashing dragon strategy. I'm
doubtful about the effectiveness, however. A good example where it
fails is move 228 at P8 in the Temnik game. P8 is definitely an owl
defense threat but black playing there does nothing to restrain the
thrashing dragon. It only removes a ko threat.

More ideas?

/Gunnar




reply via email to

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