gnugo-devel
[Top][All Lists]

Re: [gnugo-devel] regress endgame:603

 From: bump Subject: Re: [gnugo-devel] regress endgame:603 Date: Fri, 11 Apr 2003 06:32:34 -0700

```> By my count, G6 is 2.5 miai and C1 is 3 miai, but tedomari concerns mean
> that G6 is the correct play for black, and C1 is the correct play for w.
> Is this incorrect somehow?  I'm not terribly confident in my endgame
> counting, but that's how I read it...

G6 is the best point for either player in this position. However
there may to be a (sort-of) valid reason for having the engine
prefer C1, as I will explain.

G6 is 5 points gote. C1 is 3 points reverse sente.

Whether 5 points gote or 3 points reverse sente is preferrable
depends on the whole board position.

It's sente for W to hane at D1. The difference on the board between
W:D1 B:E1 W:C1 B:F2  and  B:C1 W:B1 B:D1 is 3 points. The points
at issue are at B1, E1 and F2.

The difference between B:G6 and W:G6 is 5 points.

If there is another yose point on the board it is conceivable
that a 3 point reverse sente move would be preferrable to a 5 point
gote position. Suppose that it's like this:

[3 point reverse sente]  [5 points gote] [3 points gote].

If B takes the 3 point reverse sente, then W takes the 5 gote,
B takes the 3 gote, then B gets 6 points and W gets 5. If
B takes the 5 gote then W gets both the other two by taking
his sente first.

But in this position, there is no third yose point. Each
player will get one of the two plays and it's better to
chose the big one.

I think the point of the problem is that it is supposed to
be policy to prefer a 3 point reverse sente to a 5 point gote.
The engine does endgame analysis locally without taking into
account what other local games (in the sense of combinatorial
game theory) exist on the board. A real combinatorial endgame
engine would definitely prefer G6 in this position, and the
problem could be revised by placing another 3 point gote
position on the board.

The test was submitted by Gunnar in this archive link:

http://mail.gnu.org/archive/html/gnugo-devel/2002-09/msg00390.html

Dan

```