gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] endgame tuning


From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] endgame tuning
Date: Thu, 09 Sep 2004 03:11:20 +0200
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)

Evan wrote:
> Also, it looks to me like something is wrong with kgs:230.  Is it loading 
> the wrong sgf or something?

Hopefully Arend knows something about it.

I should take this opportunity to advertize the --check-unoccupied
option of regress.pike.

virihaure 47% ./regress.pike kgs.tst --check-unoccupied
kgs:23013       FAIL black [empty]

The output is not very obvious but the way this works is that the
original test cases are replaced by a number of "color" commands
checking that vertices listed in the correct answers are indeed empty.
The new testcases have numbers given by the original number appended
by 11, 12, 13, and so on. Thus kgs:23013 means that there is a problem
with the third vertex in the correct answer to kgs:230.

Doing this for the full regressions turns up another problem with
semeai:99. The first vertex M12 should be L12.

> +Pattern EE806
> +# evand new (3.7.1)
> +# see kgs:70
> +
> +|.O??
> +|.OX.
> +|.*X.
> +|....
> ++----
> +
> +:8,OXe,terri(3)

This should be possible to handle with influence tuning but until
someone does that the pattern looks fine. I'm not sure about 3 points
of territory, however.

> +Pattern CE34
> +# evand New pattern. (3.7.1)
> +# see endgame:920
> +
> +?OO
> +...
> +O*X
> +
> +:8,OXe,terri(1)

Should also eventually be solved by influence tuning.

> +
> +?OO
> +a..
> +O*X
> +
> +;xmoyo(a)

But this constraint can't be right. Should be omoyo(a).

> +Pattern CE35a
> +# evand New pattern. (3.7.1)
> +# see endgame:850
> +
> +?X??
> +.*.o
> +O..O
> +?..?
> +
> +:8,OXe
> +
> +?X??
> +.*.o
> +O..O
> +?ab?
> +
> +;omoyo(a) || omoyo(b)
> +
> +
> +Pattern CE35b
> +# evand New pattern. (3.7.1)
> +# see endgame:850
> +
> +?X??
> +*..o
> +O..O
> +?..?
> +
> +:8,OXe
> +
> +?X??
> +.*.o
> +O..O
> +?ab?
> +
> +;omoyo(a) || omoyo(b)
> +
> +
> +Pattern CE35c
> +# evand New pattern. (3.7.1)
> +# see endgame:850
> +
> +?X??
> +..*o
> +O..O
> +?..?
> +
> +:8,OXe
> +
> +?X??
> +.*.o
> +O..O
> +?ab?
> +
> +;omoyo(a) || omoyo(b)

These all look fine, but I wonder if they shouldn't go into patterns.db.

> --- patterns/patterns.db      22 Aug 2004 13:07:31 -0000      1.129
> +++ patterns/patterns.db      7 Sep 2004 02:13:59 -0000
> @@ -1254,6 +1254,7 @@
> 
>   Pattern CC81
>   # db added (3.1.4)
> +# evand modified (3.7.1) -- see endgame:910
> 
>   O*X
>   XO?
> @@ -1265,7 +1266,7 @@
>   XO?
>   ?O?
> 
> -; does_attack(*,a)
> +; does_attack(*,a) && lib(a) > 1
> 
> 
>   Pattern CC82

This constraint revision doesn't make much sense to me.

/Gunnar




reply via email to

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