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: grok
Subject: Re: [gnugo-devel] An Inquiry about how to modify GUN Go's Replay method .
Date: Sat, 15 May 2010 19:43:03 -0700
User-agent: Mutt/1.5.18 (2008-05-17)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


As the smoke cleared, Gunnar Farnebäck <address@hidden>
mounted the barricade and roared out:

> 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

That reply is so clear and succinct, it is almost breath-taking.
;P

- -- grok. 






- -- 
The Financiers & Banksters have looted untold trillions of our future earnings.
Their bureaucratic police & military goons are here to make us all pay for it.
Forever.
Well FORGET THAT. Let's get it *ALL* back from them -- and more.

**Socialist revolution NOW!!**

Build the North America-wide General Strike.
TODO el poder a los consejos y las comunas.
TOUT le pouvoir aux conseils et communes.
ALL power to the councils and communes.

And beware the 'bait & switch' fraud: "Social Justice" is NOT *Socialism*...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkvvW7cACgkQB9bXLLhitTM8jwCbBB4zWYGppWFvoWCDJ+wl6nXM
V0kAn219s6Nfk+0aqLbeaoIekIhozQ3F
=6aWE
-----END PGP SIGNATURE-----



reply via email to

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