gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] Inge's patches


From: Arend Bayer
Subject: Re: [gnugo-devel] Inge's patches
Date: Wed, 23 Jan 2002 18:13:59 +0100 (CET)

> Arend wrote:
> > > Dan wrote:
> > > > The two patches of Inge's seem beneficial on the basis
> > > > of the regressions. 
> > > 
> > > That is nice although surprising.  The patches are purely
> > > infrastructure and are not meant to change any regression results.
> > > I think I will have a look and see what is going on.
> > I think I can explain that. In discard_rules, there is the rule (which
> > I adapted from the old code when I introduced the discard_rules in 3.1.17 or
> > something)
> > 
> >   { { ATTACK_EITHER_MOVE, DEFEND_BOTH_MOVE, -1 },
> >     tactical_move_vs_either_worm_known, REDUNDANT,
> >     "  %1m: 0.0 - att. either/def. both involving %1m (direct att./def. as 
> > well)\n"},
> > 
> 
> Yes, after I had written my mail I had a look at what happens and came
> to the same conclusion.  However, I think that your line above might
> be wrong since you cannot treat attack_either the same way as
> defend_both. 
Hmm, I still think that this rule (that was made up by someone else btw,
I only adapted it) is logically correct. DEFEND_BOTH means that opp. can
attack there and either (up to my choice) attack a or b. Well, if he can
attack a anyway, and if my move defends against that, then "defense of a"
is how my move should be valued.
Having said that, the reason why dropping this rule is successful is that
the influence function doesn't weigh the capture of a string sufficiently
high if capturing it means the opponent breaks into our territory.

Btw, some of the PASSES seem to be due to another change (which you
did not intend I suppose): you now count 4* the size of the attacked
strings as move value, instead of twice the size as before. I am not
sure whether this will be an improvement in general.

Arend





reply via email to

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