gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] trevor_1_14.2


From: Gunnar Farneback
Subject: Re: [gnugo-devel] trevor_1_14.2
Date: Fri, 09 Nov 2001 23:35:32 +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:
> As part of this tuning exercise, I removed a few patterns that
> didn't make sense to me or were causing problems.  The removal
> helped or made no difference, so feeling that less is more, it 
> seems good.

In general I agree that if patterns can be removed without damage,
that's a good idea to do.

> -     TRACE("Pattern %s joins dragons %1m, %1m\n",
> -           pattern->name, first_dragon, second_dragon);
> +     /* Want this output if verbose or DEBUG_DRAGONS is on, but not both.*/
> +     if (verbose) {
> +       TRACE("Pattern %s joins %C dragons %1m, %1m\n",
> +           pattern->name, color, first_dragon, second_dragon);
> +     } else {
> +       DEBUG(DEBUG_DRAGONS, "Pattern %s joins %C dragons %1m, %1m\n",
> +           pattern->name, color, first_dragon, second_dragon);
> +     }

Better to use the construction

if (verbose || (debug & DEBUG_DRAGONS))
  gprintf(...);

so we don't have to duplicate the printing statement.

> +Pattern A1343
> +# tm new pattern (3.1.14)
> +# See strategy4:208
> +
> +|.Xx  1-2 point often vital in this shape
> +|.oX
> +|.*.
> ++---
> +:8,s,value(50)
> +
> +
> +Pattern A1343
> +# tm new pattern (3.1.14)
> +# See strategy4:208
> +
> +|XX?   Try destroying X's eye.
> +|.X?
> +|*Xx  
> +|OoX
> +|...
> ++---
> +
> +:8,s,value(50)

I think both these patterns, or at least the second one, would be
better implemented as eye patterns instead.

> +Pattern D1136
> +#tm new pattern (3.1.14)
> +#See strategy:206
> +
> +OOO  very low value - can't hurt to try!
> +..X
> +X*.
> +???
> +
> +:8,b,value(5)

The reasoning in the comment is faulty. Even with a small value it may
happen that this move is tested in a lot of variations without being
effective. That is problematic for two reasons. First it takes time
and second it may lead to the node limit being reached, giving an
uncertain reading result.

/Gunnar



reply via email to

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