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

[Arend Bayer]

On Tue, 10 Sep 2002, Portela Fernand wrote:

> Dan wrote:
>
> > I also think that WIN should be the same code for the owl code as
> > for the reading code so if nothing is broke it doesn't matter
> > if there are some codes that are never realized by the reading code.
>
> After reviewing a bit more the source, I now tend to agree with that.

One thing to note is that this way we need one more bit for the result
in the reading cache.  While we currently have sufficiently much space there,
this can change (alpha-beta cut would need two more bits per result,
iterative deepening one, ...).
Maybe not yet worth worrying though, no strong opinions here.

I can see some advantes of having comparable results between owl and
tactical reading, though, yes. (I am not sure in how many places they
actually get compared.)

> > it is also a potential big complication in implementing Nando's
> > patch.

Well, in any case we need to go through the code and see what we do
with the new owl return values.

> Yes. Still... would it help if the moves found by this mechanism
> would be reported as tactical moves instead of OWL attack/defend
> moves ? I guess their valuation wouldn't be a problem any longer.
> Thoughts ?
Well, to report them as tactical attacks you would have to know which
worm can be captured in the process. Maybe what you have in mind is
close to what I was thinking of:

I'd make the ambitious suggestion to try and do it as precisely as we
can:

* At the start of each owl computation, make a list of worms that belong
to this dragon. Order the worms by size. Save that list.
* Once the dragon is alive, check which of these worms are still on
board (later: check whether they are still connected to the living part
of the dragon).
* Make a bitmap out of that, with as many bits as we can spare in the
reading cache (that would currently be 8 bits, i.e. we could remember
whether we rescued the 8 biggest worms of the dragon).
* The result would then be: (traditional code) << 8 | bitmap.

The semantics of the result would be:
owl_defend:
WIN << 8 | bitmap -> dragon alive, kept all pieces set in bitmap
KO_? << 8 | bitmap  -> can live with ko, if alive keep all worms set in bitmap
0 << 8 | 0 -> dead (0 << 8 | bitmap doesn't make sense).

owl_attack:
WIN << 8 | 1111111 -> killed dragon
...
0 | bitmap -> can't kill, but can capture worms set to 1 in the bitmap.

I see some advantages and disadvantages for this:
++ These can be handled very precisely in the move valuation (e.g. by
treating the owl status as a per-worm variable, or by cheating and
treating these moves as tactical attacks for now as Nando suggested),
without introducing new heuristics
++ Should be very reusable for tails that get cut-off once we can
analyze this
++ If we one day decide to care about comparing "defend everything with
ko" vs "defend part of it unconditionally", it would be easy to introduce
(I agree not to worry about this for the moment.)

Disadvantages:
-- its obviously strangely limited to 8 worms of the dragon
-- more work to implement this


Arend