Re: [gnugo-devel] new_semeai(void)

[Gunnar Farneback]

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?

Possibly because the valuation of SEMEAI_MOVE reasons has been more or
less broken, possibly because a semeai move is effectively very
similar to a combination of owl moves.

> 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.

> (I have changed the territory valuation of SEMEAI_MOVE, which was still
> in old effective_size style, to match the OWL_..._MOVE version.

Good, now it might be unbroken for possibly the first time. :-)

> 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.

> P.S.: The old function analyze_semeai() implicitly contains the color
> parameter pretty hardwired. I don't think I want to touch that function.
> Do we want to keep it at all?

Definitely not in the long run. Its only interest is in the
possibility to turn off experimental-semeai and see what difference it
makes. I wouldn't mind removing it right away.

/Gunnar