gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] trevor_1_20.8


From: Gunnar Farneback
Subject: Re: [gnugo-devel] trevor_1_20.8
Date: Tue, 08 Jan 2002 17:51:25 +0100
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)

Trevor wrote:
> http://www.public32/com/games/go/trevor_1_20.8
>  - tuning
>
> It seems like every tuning patch I submit breaks about
> 1/2 the number of problems that it fixes.  Is this to
> be expected in the tuning dance:  2 steps forward, 
> 1 step back?

That depends on what you do. Owl tuning has a tendency to have
unexpected side effects due to the node and variations per node
limitations, so then a 2:1 ratio is not unexpected. Tuning of other
databases is usually more a question of adding obviously missing
patterns or fixing clear mistakes in existing patterns, so there a
better result should be expected. Still there are many test cases
which pass by accident and may break from perfectly valid tuning, so
some "unexpected failures" are almost bound to turn up if you do a
substantial amount of tuning.

For what it's worth, I often get 3:1 or 4:1 ratios when I'm doing
non-owl tuning, including code revisions.

Comments to the patch:
> +# tm removed this pattern (3.1.20)
> +#   almost identical to D308 - in fact more restrictive, with lesser value.
> +#Pattern D308b

The value was higher before you revised the value of D308, so maybe
the value of D308b should have been increased accordingly. But I don't
remember why the D308b variation was introduced, so it's possible that
it's redundant now.

>  Pattern D309
>  # tm modified (3.1.16)
> +# tm reduced value (3.1.20) (see dniwog:5)
> +# FIXME: Adding B attribute solve niki:14 - not sure why -tm.
> +#     adding it breaks a lot, however (i.e. trevorb:590)
>  
>  ?O?        block off area
>  X*.
>  ooo

The B attribute would definitely be wrong here, but it may certainly
happen to solve some test case where the owl code makes a mistake in
the implicit connection analysis.

> +Pattern RE7
> +# tm New Pattern (3.1.20) (see strategy4:173)
> +# FIXME: This seems a little underhanded, prob. not best fix.
> +
> +|.??   better for ko threats
> +|*.?
> +|XO?
> +|X.o
> +|?O?
> +
> +:8,-
> +
> +|.??   better for ko threats
> +|*.?
> +|bO?
> +|bao
> +|?O?
> +
> +; oplay_attack(a,b) &&
> +; (oplay_attack(a,b) == oplay_attack(*,b))
> +
> +> replace(a,*)

Not sure if it applies here, but shape values are effective also for
ko threats.

/Gunnar



reply via email to

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