gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] owl:11


From: Gunnar Farneback
Subject: Re: [gnugo-devel] owl:11
Date: Thu, 10 Apr 2003 21:21:21 +0200
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)

Evan wrote:
> I was looking through the owl test suites, and noticed that owl:11
> performs very poorly.  Specifically, it uses 848943 reading nodes, and
> only one owl node.  The reading nodes are used in evaluating the O6 eye
> (GTP command eval_eye O6 uses most of the reading nodes).

To evaluate an eye it's necessary to first examine the position.
That's what takes time, not the actual eye evaluation.

To find out what tactical reading calls take time you can use
DEBUG_READING_PERFORMANCE (0x8000). However, this is disabled in the
silent_examine_position() call used by eval_eye and similar. But if
you just do 

../interface/gnugo --quiet -l games/incident236.sgf -L 116 -d0x8000

you get a somewhat lengthy output including

attack T14(T14) = 4 T15, 13511 nodes W:S14 
attack T14(T14) = 4 S14, 5510 nodes W:R14 
attack C12(C12) = 5 D12, 3465 nodes W:C11 
attack S12(S12) = 5 R11, 1464 nodes B:R12 
attack T12(T12) = 5 Q13, 3220 nodes W:T11 

where the first of these lines says that after white S14, an attack
with ko is found on T14 after reading 13511 variations.

> Is there a convenient way to trace what is going on in the optics code, eg
> an sgf trace?

Well, yes, but usually no actual reading is done during the eye
evaluation (topological eye status has already been computed during
examine_position()), so the output tends to be very small. :-)

/Gunnar




reply via email to

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