gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] gnugo 3.4 problems


From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] gnugo 3.4 problems
Date: Sat, 20 Nov 2004 20:25:58 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.9) MULE/5.0 (SAKAKI)

Dan wrote:
> On my machine, GNU Go still generated 118 at O15 when the game was
> replayed using --replay black. When I loaded the game and
> generated a move it played S19.

Ok, I didn't try replaying.

> > Since GNU Go only distinguishes between good ko where the opponent
> > must find the first ko threat and bad ko where itself must find the
> > first ko threat, it's only at move 114 where it has a chance to tell
> > the good moves from the bad moves.

Sooner or later we need to expand the set of ko result codes if we
want to be able to meaningfully analyze this kind of positions. Can
anybody come up with an elegant scheme which is more powerful than
what we have today but still of reasonable complexity?

> Black should have killed the upper right corner at 42.

Huh? Do you mean defended the upper right corner?

> At move 58 if B connects at C19 W can only get a very bad
> ko.

How? As far as I can tell white must immediately answer at H19, and
then black has time to play A14 too.

> But the correct local move is A14 which wins the ko
> outright.

I suppose you mean semeai. I agree that A14 wins outright.

> Move 59 is W's move but this is also a good test. W's
> move is wrong, and W should throw in at C19 to get seki.
> 
> At move 60 B can get seki at A14 or a favorable ko at
> C19.

Also agreed. Please add to semeai.tst. These should be possible to
solve.

/Gunnar




reply via email to

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