gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] End game strategy


From: Gunnar Farneback
Subject: Re: [gnugo-devel] End game strategy
Date: Tue, 02 Sep 2003 22:43:16 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

SP Lee wrote:
> Currently, gnugo enters engame mode when there is no move found of
> value greater than 6. However, there are many typical big end game
> moves worth 10 to 30 points. I would think the gnugo should enter
> end game mode when :

The 6 point cutoff is only an optimization, avoiding to spend time on
many very small moves while they are irrelevant. This optimization was
very important before the persistent caching was introduced but is
probably still significant. (Didn't someone measure this some time
back?)

Moves which humans like to describe as "big endgame" should be in the
main pattern databases if they are larger than 6 points.

> 1. All b/w groups are non-critical

I think you mean something else, or possibly something fuzzier. Saving
or capturing a single stone can be very small, especially in a ko with
no strategical value or followup potential.

> 2. There is no more invasion chance to either color
> 3. The only task for both color is to expand or defend territory.

Somehow I think determining this is enough work that there's not much
left to gain by declaring the position as endgame.

> The following situation from the game with go ++ maybe a illustration
>    A B C D E F G H J K L M N O P Q R S T
> 19 . . . . . . . . . . . . . . . . . . . 19
> 18 . . . . O X X . . . . . . . . . O . . 18
> 17 . . . . O O X . . . X . O . O . O X . 17
> 16 . . O + . . X . . + . . . . . O X . . 16
> 15 . . . . . . . . . . . . . . . . X . . 15
> 14 . . . . . . . . . O . . . . . . . . . 14
> 13 . O . . O . O . . . . . . . . . . . . 13
> 12 . X O . . . . . . O . . . . . X . . . 12
> 11 . X O O X . . . . . . . . . . . . . . 11
> 10 . O X O . X . . X + . . . . . + . . . 10
>  9 . X X . . . . . . . . . . . . . X . . 9
>  8 . . . . . . . . . . . . . . . . . . . 8
>  7 . . X . . . X . . . . . . . . . . . . 7
>  6 . . . . . O . . . . . . . . O . X . . 6
>  5 . . . . . . . . . . . . . . . . . . . 5
>  4 . . . + . X . X . X . . . . . O . O . 4
>  3 . . . X . . . . . . . . . O . . . . . 3
>  2 . . . . . . . . . O . . . . . . . . . 2
>  1 . . . . . . . . . . . . . . . . . . . 1
>    A B C D E F G H J K L M N O P Q R S T

Is this supposed to illustrate endgame? Looks like middle game to me.

> I think in this case, gnugo should turn off all minimum accepted value such 
> as a J pattern and calculate territory value solidly. Gnugo played S18 which 
> doesn't worth much, just due to the minimum accepted value of 13.24.

If a J (or some other class) pattern isn't worth its fixed value it
shouldn't be a J pattern, regardless whether the position is
considered endgame. In the position above 13 points for S18 doesn't
seem unreasonable to me.

> Furthermore, both the best move of black and the best move of white should 
> considered. Using gg_genmove I got the following top moves:
> 
> Top moves (white) :
> 1. M4  17.08
> 2. E9  16.01
> 3. M3  14.91
> [...]
> 
> Top moves(black):
> 1. S18 13.24
> 2. E9  11.77
> 3. J16 11.47
> 4. M5  11.37
> [...]
> 
> Interestingly E9 is valued high for both black and white. Same as M5 and M4. 
> Thus gnugo should play E9. There should be cases where black and white's 
> moves differ a little bit, but that is still the position of interest.

Looking for moves which it agrees are worth much for both colors
doesn't seem like a reasonable strategy. If a move is found for only
one color it may either mean that one color has found a bogus moves or
that the other color has missed a big move. The problem with different
points for each color in the same area is also a real problem for such
a strategy.

It does point to an effective method to detect problematic positions
for potential test cases though.

/Gunnar




reply via email to

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