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

[Yllman, Jens]

But does he not ask about not replaying ALL of the moves of the game. He
want to analyze ONE move. I guess that he uses --replay. I guess using
-L to move to the move you want to analyze is one whay to speed up. But
how how to analyze only the next move? Do you do that by using GTP. Will
you be able to get the debug output in GTP?

Or am I reading "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." wrong.

Jens

On 2010-05-15 23:03, Gunnar Farnebäck wrote:
> 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
> 
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnugo-devel