gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] Decide dead stone


From: Gunnar Farneback
Subject: Re: [gnugo-devel] Decide dead stone
Date: Thu, 09 Jan 2003 20:53:36 +0100
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)

Amour Tan wrote:
> I have an idea of using GNU Go to decide and remove dead stone upon 
> completion of the game.  The requirement is fairly simple, upon feeding 
> a GTP or SGF file to GNU Go, I need a list of dead stone on the 
> goban from GNU Go. 
>   
> I have some questions 
> [...]
> 2. What is the equivalent GTP command?  Is there? 

The official command according to the GTP version 2 specification is
"final_status_list dead". As Dan suggests it's also possible to obtain
the status with "dragon_data" or "dragon_stones" + "dragon_status".

The main difference is that the latter method is relatively fast but
not quite reliable with respect to sekis. The first command is
generally more robust but much slower since it plays out the position
until the status of all stones are known without a doubt. Issuing
"final_status_list" for a game which is far from finished can take
lots of time since GNU Go effectively finishes the game by selfplay.

Marco wrote:
> However, I am not so sure it is a good idea to rely on GNU Go to
> score server games. It can be slow and it's not perfect.

For games it has played itself, I would estimate the failure rate to
maybe 1%. For scoring of games between other players it's probably
higher, possibly much higher.

Paul wrote:
> i wouldn't recommend using dragon_status since it might have some
> problems in its current state. since recently, ld_owl:161 failed,
> though owl correctly understood the position if asked through
> owl_attack and owl_defend.

It was overruled by the semeai code.

> this test now passes, but that's not because dragon_status has been
> fixed. so, i don't think that using it is a good idea.

The test started passing when the experimental semeai code was made
default. I don't think there's anything wrong with the dragon_status
command itself.

/Gunnar




reply via email to

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