Re: [gnugo-devel] a patch from a newbie :)

[Arend Bayer]

Dan wrote:

> > * Change 1, 2, 3 to KO_B, KO_A, WIN wherever those macros are
> >   appropriate.
> > * Change any occurences of the form "3 - code" or "WIN - code" to
> >   "REVERSE_RESULT(code)".

> My impression is that the scheme is basically sound. Its principal
> defect is that it doesn't track of which piece is discarded in a
> partially successful attack.  This seems less important than
> the simple fact that something does get cut off. Arend suggested
> something more complicated but at this time I would favor a simple
> scheme.

First I'd like to make clear that my ambitious suggestion was not meant
as being against a simpler solution for now. Anything we learn when
implementing a simpler scheme will remain useful, and in particular we
will learn whether a more complex scheme is necessary at all.

> To summarize, I like the patch, though of course it now needs
> to be resubmitted.

Well, I like it too, but...let me explain what I think the current effects
of the patch are:
(I gather that nando is already working on refinements, but I hope that
this discussion is still worthwile.)
The most important code for handling owl return values is in
make_dragons(), dragon.c starting around lines 380:
* If a tail of the dragon can be captured, there will be "acode != 0". We
then look for a defense move, which will probably return WIN. The result
will be that the whole dragon is CRITICAL. If it is our dragon, the
defense move will count as defending the whole dragon, if it is
opponent's dragon, the attack will be valued as if attacking the whole
dragon. (This is taking into account the changes in owl_move_reasons.)
I am not so sure this is much better than ignoring the possibly lost tail.

* The other case is: a dragon can get killed, and if it is defended only
a part will be saved. I think this case is not so much worrying about (I
also _think_ there is no change in this case due to the patch.)

[Nando, I didn't think about what happens when changing move reasons to
tactical attacks/defenses. It could be that e.g. a tactical defense move
is simply ignored, because the worm is considered alive anyway.]

Probably as a start it would be absolutely sufficient to start with a
heuristic such as "a owl attack move with result GAIN is worth
0.5*dragon[aa].effecive_size". One way to implement such a thing would
be to set such dragons ALIVE, and make two new move reasons such as
OWL_GAIN_S_TH, OWL_PREVENT_LOSS.

Anyway, I think the most relevant parts in the code are
- owl_move_reasons (as addressed already in the patch)
- make_dragons() as mentioned above
- in case of new move reasons: add some code in in value_moves.c:
  estimate_territorial_value()
There are, of course, lots of other places that gather information from
owl_... calls, but they are not as important I think (and can be adjusted
later).

I hope this is helpful.

Arend