gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] new_semeai(void)


From: Arend Bayer
Subject: Re: [gnugo-devel] new_semeai(void)
Date: Sun, 23 Mar 2003 17:15:06 +0100 (CET)

Gunnar wrote:

> Arend wrote:
> > The old semeai code added SEMEAI_MOVE as move reason, the new one
> > OWL_ATTACK/DEFENSE_MOVE. Is there any reason for this?

(...)
> > I think we should stick with SEMEAI_MOVE. If we want to treat them
> > identically in value_moves.c, that should be an explicit decision there,
> > and not forced by the semeai code.
>
> Well, either use it or remove it completely. The latter would reduce
> code complexity so we need some compelling reason why it would be
> worthwhile to distinguish between them in the move valuation.

Well, at least at the moment I see reasons to treat them differently.
Owl moves are still far more reliable, and I think it makes sense
to treat them differently in find_more_owl_attack_and_defense_moves
and induce_secondary_move_reasons (that's where the two passes are
coming from btw).

> > The patch produces two lucky passes. global:3 shows an enormous semeai
> > misunderstanding, which I have added to semeai.tst. It shows a problem
> > Gunnar has pointed out recently (declaring dragons dead too quickly).
>
> I'm somewhat surprised that no regression failed, because...
>
> -     if (DRAGON(d1).color == color
> -         && defense_move != PASS_MOVE) {
> -       add_owl_defense_move(defense_move, DRAGON(d1).origin, WIN);
> -       DEBUG(DEBUG_SEMEAI, "Adding owl defense move for %1m at %1m\n",
> -             DRAGON(d1).origin, defense_move);
> -     }
> -     if (DRAGON(d1).color == other
> -         && attack_move != PASS_MOVE) {
> -       add_owl_attack_move(attack_move, DRAGON(d1).origin, WIN);
> -       DEBUG(DEBUG_SEMEAI, "Adding owl attack move for %1m at %1m\n",
> -             DRAGON(d1).origin, attack_move);
> -     }
> +     dragon2[d1].semeai_defense_point = defense_move;
> +     dragon2[d1].semeai_attack_point = attack_move;
>
> ...where we previously could get multiple moves for the same dragon,
> now only one attack point and one defense point are stored. I do think
> we should reserve space in struct dragon_data2 for a list of semeai
> moves.

I think you are misreading the function. The if (semeai_found) is
outside the "for (d2..." dragon loop, so we are using one move both
before and after the patch.

Still your suggestion to store more semeai attack/defense points makes
sense. (Or at least try a better heuristic which one to choose if there
are several.)

Arend





reply via email to

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