gnugo-devel
[Top][All Lists]
Advanced

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

[gnugo-devel] Owl cuts, goal dragons and origins


From: N N
Subject: [gnugo-devel] Owl cuts, goal dragons and origins
Date: Tue, 18 Oct 2005 15:09:07 +0200

Hi,

Just reproducing the ticket I just opened at
http://trac.gnugo.org/gnugo/ticket/43

I witnessed recently something weird while analyzing some OWL reading.
It happened that an owl attack against an isolated (invading) stone
succeeded (at stackp == 14 or so), just by tactically capturing that
original lonely stone, despite the following facts:

* the original stone had been at some point cut off from the goal
* the rest of the group built along the variations had managed to get life

The appended patch is an attempt (IMO incomplete, see below) at fixing
this problem.

Breakage:

auto02:7        PASS 1 S15 [1 (S15|R15)]
auto02:8        PASS 1 M18 [!0]

Nodes counts:

Total nodes: 1651143209 3235170 11909903
I didn't bother analyzing those passes, because the patch looks so
much like a bugfix that I strongly doubt that they could be
accidental. Moreover there are problems I'd like to discuss before
going further.

The first problem I can see with this patch, is that it doesn't fix
the problem: it is still possible that an owl reading focuses on a
target (the str parameter) which is no longer part of the goal. This
is due to the fact that I followed the convention previously used for
captures in the new static function select_new_goal_origin(), namely
that the new origin has to be one of the original strings under
attack. Which brings me to the second topic.

Given the above mentioned convention, it is likely that GG will refuse
to sacrifice a light invasion stone for the sake of making a group
alive in the opponent's sphere of influence. Conversely, GG might be
too optimistic in the treatment of such opponent stones filled with
aji when the opponent is invading GG's moyo.

A test of a different policy (use whatever string still present in the
goal as new origin) is quickly done and shows 11 passes and 18
failures. Do you guys think this issue is worth investigating or did I
miss some important point ?

-- nando

PS: I'm not too sure how to handle the new trac service and the list,
is it ok to use both and duplicate, or is there a better (or
preferred) way ?




reply via email to

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