[Top][All Lists]
[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-----