[Top][All Lists]

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

Re: [gnugo-devel] Patch: New move generator

From: Gunnar Farneback
Subject: Re: [gnugo-devel] Patch: New move generator
Date: Sun, 28 Oct 2001 12:19:40 +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)

Inge wrote:
> > (As a side note the valuation of ATTACK_EITHER and DEFEND_BOTH is a
> > complete mess. I don't think it's possible to do this well without
> > actually playing out the local position.)
> True, but we are wading in approximations everywhere.

Actually, if we could determine which attack in ATTACK_EITHER is
(likely to be) most valuable it should be possible to convert the
other branch to an ordinary ATTACK_MOVE reason (and if needed add
DEFEND_MOVE reasons for saved neighbors) before doing the evaluation.
(The most valuable branch would be an attack_threat instead.)

DEFEND_BOTH is harder to deal with. It might be possible to do
something similar but that would involve removing DEFEND_MOVE reasons
for nearby moves which don't defend against the simultaneous attacks.

> As I said above, this code was just copied from the valuation of
> ATTACK_THREAT_MOVE.  You have to ask yourself that since you wrote it
> originally.  :-)

I'm fairly certain that's not my code originally. Besides the worm
data can't be used there since it's run at stackp = 1.

> > > valuation.  I will carry the same ideas to defended worms and to
> > > attacked/defended dragons.
> > 
> > You're welcome to try this but I'll promise that doing it for dragons
> > will break things horribly.
> I was mainly thinking of worms, but why would it break things horribly?

Because it would cause a lot of double counting of stones. This does,
by the way, not necessarily show up much in the regressions since
those generally involve positions we've had trouble evaluating, not
the ones where we've been doing well.


reply via email to

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