gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] An Inquiry about how to modify GUN Go's Replay method


From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] An Inquiry about how to modify GUN Go's Replay method .
Date: Sat, 15 May 2010 23:03:31 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100411 Icedove/3.0.4

On 05/12/10 05:17, Amr Ahmed Sabry Abdel Rahman Ghoneim wrote:
Good Day …

I’m a Post-Graduate Student at the University of New South Wales
–Australia. I’m using GNU Go in my research and I need to make a
modification to its code. But since the GNU Go is life-size and has been
developed over a long time, I need help on that from any of the
developers who did develop the engine.

My problem is as follows: I’m using GNU Go’s debugging options to
analyse the reasons behind the moves in certain Go games. So, I use GNU
Go to replay specific go games, generating the reasons for each of the
moves in this game. But, the replay option makes the engine actually
plays the whole game, and thus generating reasons for all of the
possible moves the engine was considering. The engine takes around 15 to
20 minutes using my desktop to analyse a single game, and I effectively
need to cut down the time utilized. So, instead of generating the
reasons and values for all the considered positions in each move, I’d
like to modify the engine to do that only for the positions actually
played in the game replayed by the engine. And I need to do so without
affecting the reasons generated for those actually payed positions. Can
this be done? And how?

For all practical purposes it cannot be done. Somewhat simplified GNU
Go starts its analysis by determining tactical status of strings and
connectivity between strings, then collecting strings into dragons and
doing life and death analysis. When something is found to be unstable
the corresponding critical points produce move reasons. Thus if you
only want move reasons for a single move you would have a hard time
determining which local analyses to perform, and for other pattern
induced move reasons you would also need correct worm and dragon
status for a difficult to determine part of the board.

It might be feasible to shortcut some of the computations made to
refine the move reasons for other moves than the played one, but the
primary board analysis would still take a considerable time and it
would be easy to miss some side-effect that would actually affect the
reasons for the played move. It's unlikely to be worth the effort.

/Gunnar



reply via email to

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