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: bump
Subject: Re: [gnugo-devel] gnugo 3.4 problems
Date: Sat, 20 Nov 2004 21:31:22 -0800

Here is a cleaned-up copy of the position at move 60 in
the game previously discussed.

(;GM[1]FF[3]
SZ[19]
GN[GNU Go 3.5.10 load and print]
DT[2004-11-20]
KM[0]RU[Japanese]AP[GNU Go:3.5.10]PL[B]
AW[ha][ab][bb][ib][mb][pb][qb][cc][ec][fc][gc][hc][ic][oc][pc][ad][cd][fd][jd][ld][be][ce][de][ee][cf][qf][mg][ph][qq][pr][rr]
AB[ba][cb][db][eb][fb][gb][hb][kb][rb][bc][dc][qc][dd][ed][gd][nd][od][pd][qd][fe][bf][ef][ff][bg][cg][jh][dj][jj][pj][pm][dp][jp][pp][qp][rp][mq][rq]
)

There are some difficulties in writing a proper semeai test
here. For one thing, the dragons at B18 and C17 are not
amalgamated. But if W plays first, presumably

118 analyze_semeai C17 C18
#? [1,0]

is a good test.

The question is what happens if B plays first. If B plays
at C19, he gets a favorable ko, whereas a different move
such as A14 allows W to throw in at C19 and get a seki.
So at a first take the test should be written:

119 analyze_semeai C18 C17
#? [2,2 C19]

W gets the ko by answering C19 with W:A14. And it isn't
a very good ko. W has to win it multiple times and if B
can't fight it, he can lose it about twice (taking
profit elsewhere) then chicken out and the worst that
can happen to him is seki. So W is fighting a very
uphill ko for seki. So the test should be written:

#? [1,2 C19]

But I actually think a ko this bad is not much
different from no ko at all, so the test should be
written:

#? [1,0 C19]

This touches on the question Gunnar asked:

> 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?

A proper solution to this might require expanding
the data bits in struct Hashnode (see cache.h). A
comment there suggests that this is not too bad.

If we can find two bits somewhere in the Hashnode our
existing KO_A and KO_B could be arranged in a hierarchy
of eight possibilities, from best to worst:

       very indirect ko, favorable to me
       2 move yose (approach-move) ko, favorable to me
       1 move yose ko, favorable to me
KO_A = direct ko, I make first ko threat
KO_B = direct ko, you make first ko threat
       1 move yose ko, favorable to you
       2 move yose ko, favorable to you
       very indirect ko, favorable to you

Bill Spight worked on the difficult problem of
describing ko from the point of view of combinatorial
game theory. I found a paper on this subject at:

http://www.msri.org/publications/books/Book42/files/spight.pdf

Dan




reply via email to

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