[Top][All Lists]

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

Re: [gnugo-devel] evan_5_1.2

From: Evan Berggren Daniel
Subject: Re: [gnugo-devel] evan_5_1.2
Date: Sat, 6 Sep 2003 01:48:46 -0400 (EDT)

On Sat, 6 Sep 2003, Arend Bayer wrote:

> I have two remarks about this:
> 1.) The move at * wouldn't have occurred to me. Then I checked with
> kombilo (I really recommend installing kombilo to everyone interested
> in joseki study -- whether for gnugo or for your own games), and I indeed
> did find it in a lot of pro games. But they were all in the following
> situation (or similar):
> -------------+
> .............|
> .............|
> ..aX......*..|
> ...,.....X...|
> .............|
> ..........O..|
> .............|
> .............|
> In all the games, X had a stone at the hoshi on the left side, or as
> in  the diagram, or at "a". What is the reason behind this?
> Usually, the variation in the diagram above (without a pincer) is bad for
> white. But when it's played in the situation as in the last diagram,
> the black stone on the top ends up badly placed, thus leading to
> a fair result overall.

I think there is more to it than that.  The patch was in response to the
testcase nando:210, etc, which was taken from a pro game.  In the
testcase, there is no extension.  I confess I do not know why the invasion
was chosen; presumably there is some other reason that the sequence played
was reasonable.

> 2. Now if black does have a stone at the top, than its usually better
> (and probably even more so for gnugo) to block on the other side
> (i.e. B2 at 3 in the variation above.)

In the testcase, blocking on the other side seems highly unreasonable.

> So I think the joseki needs a little more context. Maybe we should merge
> the patch as it is, however, without marking W1 above as joseki.

I like that approach; expecting gnugo to decide when an invasion is better
than something else like a double kakari seems unreasonable to me.

Evan Daniel

reply via email to

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