gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] look at regress file 13x13b:6


From: Evan Berggren Daniel
Subject: Re: [gnugo-devel] look at regress file 13x13b:6
Date: Tue, 1 Apr 2003 11:24:56 -0500 (EST)

On Tue, 1 Apr 2003, kevin yong wrote:

> Hi, Evan:
>
>   there are a couple of things i need help:
>
>   > Using the sgf tracing to follow the owl code,
>
>   how? this is what i m using:
>
>   ..\interface\gnugo --quiet --t --w -d DEBUG_OWL
> --mode gtp <z13x13b.tst

you want to run it like this:

gnugo --mode gtp --quiet

and then run the gtp commands

loadsgf ...  (as from the testcase)

start_sgftrace

owl_...  (as from the testcase)

finish_sgftrace trace.sgf

This will get you an sgf file with information about gnugo's owl reading;
it can also be used for other parts of the engine.

>
>   but when i look at log file, it seems i dont get
> full trace of how owl thought.
>
>
>   Another question is:
>
>   concerning 13x13b:8. you and Gunnar suggest to exam
> the pattern:
>
>
> Pattern ED66
> # tm Modified (3.1.18) (see trevorb:610)
> # FIXME: Is this just too generic?
> # gf This pattern is way too general, see e.g.
> 13x13b:8.
> #    Furthermore the second half of the constraint
> doesn't really make
> #    sense. Consider removal. (3.3.17)
>
>
> ?x?         draw back for safety
> O.X
> .*O
> ...
> ...
> ---
>
> :8,OJ
>
> ?x?
> OaB
> .*O
> ...
> ...
> ---
>
> ; xplay_defend(*,a,*) && !xplay_attack(*,a,B)
>
>
> tell you the truth, i read the patterns.texi doc, but
> i have not fully understand yet. in the doc, it says
> '*' indicate next move for O. but in the case of
> 13x13b:8, F11 means X move at '*', not O move at '*'.
> By the way, just look at pattern, i dont see anything
> wrong for O move at '*'.

That's why the pattern is problematic.  In itself, there is nothing wrong
with the move.  But in some cases, like 13x13b:8, the pattern is
incorrect; there is a better move available.  Also, valuing the move as a
full J pattern is probably an overvaluation here.  One solution might be
to devalue ED66 from J to j, and change ED67 to propose the move at F10,
with a suitable constraint that makes sure the move works.

The way the patterns work is that O means friendly stones and X means
enemy stones; in the case of 13x13b:8, gnugo is playing for black, so
black is friendly and O as relates to the pattern.

Evan Daniel




reply via email to

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