gnugo-devel
[Top][All Lists]
Advanced

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

Re: Work in progress (was : [gnugo-devel] a patch from a newbie :))


From: Arend Bayer
Subject: Re: Work in progress (was : [gnugo-devel] a patch from a newbie :))
Date: Mon, 16 Sep 2002 00:40:36 +0200 (CEST)

Hi,

wow, impressive list...

> - added 2 new move reasons
>     OWL_ATTACK_MOVE_GAIN
>     OWL_DEFENSE_MOVE_LOSS
>   The associated .what field references the biggest affected _worm_
> - added 2 new fields in the dragon_data structure :
>     int owl_attack_kworm;
>     int owl_defense_kworm;
>   which account for the (k)illed worm in case of GAIN/LOSS
>   attack/defense codes
> - added supporting code in :
>     dragon.c :
>       make_dragons()
>     move_reasons.c
>       get_pos()
>       owl_attack_move_reason_known()
>       owl_defense_move_reason_known()

I am not sure you should add code here. These are mostly used to e.g.
forget the strategic effect of a STRATEGIC_DEFEND_MOVE if we have
already counted the move as an owl defense (otherwise we would count the
effect twice). But if it's a OWL_DEFENSE_MOVE_LOSS, we should probably
still count the strategic effect.

>       get_biggest_owl_target()
>       add_owl_attack_move()
>       add_owl_defense_move()
>       get_saved_worms()
>       mark_changed_dragon()
>       list_move_reasons()
>     owl.c
>       owl_attack()           needs a supplementary parameter
>       do_owl_attack()
>       owl_defend()           needs a supplementary parameter
>       owl_reasons()
>       owl_confirm_safety()
>       catalog_goal()         has been resurrected
>     value_moves.c
>       examine_move_safety()
>       estimate_territorial_value()

Just to understand what you are doing: Did you explicitly add the
effective worm size to the territorial value? (The other option would be
to have the worm marked as critical/captured/defended for evaluation by
influence.c).

> * There are plenty small FIXMEs left behind, specially in play_gtp.c and
>   sgfdecide.c. I guess the tracing macros also would possibly need an
>   update...
>   [Of course, I'm willing to do the dirty job, but I'd prefer first to
>   know if there's any chance for this patch to get in the CVS]
Well, I cannot speak for Dan and Gunnar, but it looks like a clear
improvement, so I'd just say go ahead with it.

> * Almost forgot another TODO: I haven't looked at the move reasons
>   discarding mechanism.
I don't expect you have to touch that. (Depending on details of your
patch I could imagine adding a case there, though.)

> PS: damn, that's a lot of work, for deceptively few PASSes... oh well, I'm
>     having fun here, so... :)
I always think getting some PASSes by doing s.th. right is worth more
than PASSes by (say) some tuning that could turn out badly in other
situations :)

Arend





reply via email to

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