gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] influence and more


From: Arend Bayer
Subject: Re: [gnugo-devel] influence and more
Date: Sat, 23 Nov 2002 16:46:06 +0100 (CET)

Dan wrote:

> > 1. I'd like to get rid of the distinction in influence.c according to
> > "territorial_influence". This will require reevaluating the long "if"
> > clauses in dragon.c that decide (based on pre-owl influence)
> > (a) whether a dragon shoould be owl analyzed
> > (b) its safety.
> > As I am somewhat skeptical about how tunable such if-constructs are, I'd
> > suggest to
> >
> > 2. use compute_dragon_weakness() already pre-owl for this decision.
> > As far as I am concerned, the safety values
> > WEAK, WEAKLY_ALIVE, ALIVE, and STRONGLY_ALIVE could be all be treated
> > as ALIVE, and if we need to make a decision based on the weakness of
> > a dragon, we use the continuos .weakness instead. (INESSENTIAL,
> > TACTICALLY_DEAD and INVINCIBLE should stay, as they do contain
> > important additional information that .weakness cannot provide.)
>
> If I understand correctly you want to get rid of the function
> segment_influence. You don't like this whole approach and
> you are probably right that you can do better. The question
> is when, should we do this before 3.4?

This has little to do with segment_influence. With
--standard-connections, both these long if statements and
compute_dragon_weakness() have their input based on segment_influence().
With --experimental-connections, neither of them has. See
compute_surrounding_moyo_sizes().

> At issue is the partitioning into territory and moyo from
> the function segment_influence. This is an ingredient in
> the conditional
>
>       if (DRAGON2(str).escape_route > 25
>         || DRAGON2(str).moyo_size_pre_owl > 20
>         || (DRAGON2(str).moyo_size_pre_owl > 10
>               && DRAGON2(str).moyo_size_pre_owl > dragon[str].size)) {
>
> around line 350 of dragon.c. I think these are the if clauses
> you are referring to.

The other is around lines 560--600.

> Currently the sequence of events regarding the computation
> of influence and weakness. From examine_positions:
>
> (1) First compute_initial_influence() is called at line 134 of
> genmove.c. From this, segment_influence is called.
>
> (2) Then make_dragons() is called. The influence is resegmented
> at line 294 of dragon.c. Calls to segment_influence also
> occur just before this during compute_escape().
>
> (3) Still in make_dragons, the conditionals arrived at above are
> reached.
>
> (3) Next compute_initial_influence() is called again from line 172
> of genmove.c.
>
> (4) Next compute_refined_dragon_weaknesses() is called from line 180
> of genmove.c. This function calls compute_dragon_weakness_value
> around the board. After this, dragon2.weakness is available.
>
> Currently the dragon2.weakness is *not* available until after
> make_dragons is finished.
>
> Therefore when you say ``use compute_dragon_weakness() already pre-owl''
> this means a very major revision.

Sure it's not yet available. I would insert a call to
compute_dragon_weakness() after (2) above, and then again where it is
currently called. So .weakness will always hold the most up to date
information (corresponding to the current state of
initial_(opposite)_influence). The only thing that will
affect behaviour is:
(a) converting the remaining places that depend on .safety to use .weakness
instead (I don't think there are many left after my recent connection
values patch),
(b) basing the decision when to call owl on .weakness instead of the
if-clause you cite above.

I don't think it will be such a major change. I'd expect no more than
around 20 changes in regression results, e.g. But of course I will have
to see.

> I think before making a change this big we should consider
> where we are in relation to 3.4.

That is still a valid concern. But as we appartently haven't achieved a
substantial improvement in playing strength yet, I didn't assume we are
close to 3.4 yet.

Arend







reply via email to

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