gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] overlaps/duplications of move reasons


From: Gunnar Farneback
Subject: Re: [gnugo-devel] overlaps/duplications of move reasons
Date: Wed, 12 Dec 2001 17:37:55 +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)

Arend wrote:
> As for overlaps in general, I suggest the following change in
> move_reasons.c to centralize the handling of such duplications.

I'm not sure if this scheme will prove sufficient in the long run, but
it should at least simplify the current code.

> (I have currently only included overlaps of tactical attacks with
> owl-attacks, so this is not yet for CVS. )
> As this patch's only purpose is to make maintaining the code easier, I
> would like to get a public opinion whether this scheme looks
> convenient.

It looks fine, except for the fact that actually deleting the move
reasons makes me very nervous. I see three potential problems with
this
1. A lot of time can be wasted in debugging missing move reasons if
   one forgets, or don't know, about this discardment.
2. It's not entirely unreasonable that it may be useful to have the
   discarded move reasons available, although they are not used
   directly in the valuation.
3. There's a risk this could interfere with a future caching scheme
   similar to the one used in examine_position().

Instead of deleting the move reasons I think it would be better to
somehow just mark them as redundant, e.g. using a new field in struct
move_reason.

A comment on the proposed code:
> +#define NUM_DISCARD_RULES 18
> [...]
> +static struct discard_rule discard_rules[NUM_DISCARD_RULES] =
> +{
> +  { ATTACK_MOVE, owl_attack_move_reason_known,
> +    " - attack on %1m (owl attacked as well)\n" },
> [...]
> +  { DEFEND_MOVE_BAD_KO, owl_defense_move_reason_known,
> +    " - defense of %1m (owl defended as well)\n"},
> +};

Constants like NUM_DISCARD_RULES are bothersome for code maintenance
and should be avoided. Better to leave the array size unspecified (the
compiler can compute it itself) and finish with an "empty" entry that
can be used to terminate loops.

> +void
> +discard_obsolete_move_reasons(int pos)

I believe "redundant" comes closer than "obsolete" to describing the
state of these move reasons. If some native speaker disagrees, please
tell.

/Gunnar



reply via email to

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