Re: [gnugo-devel] Dragon dinners

[Gunnar Farneback]

Dan wrote:
> Yesterday during the disasterous uhu game (see my previous
> e-mail) Gunnar commented ``we should implement the concept
> of absolute life.''

Not absolute life but local life. By locally alive I mean that the
dragon can make two definite eyes within the available eyespace or
strongly connect (in the readconnect sense) to a living neighbor even
if the opponent moves first. This could be implemented as a variation
of the current owl code with the following modifications:
1. Escape potential is ignored. The dragon cannot claim life due to
   this. (owl.c line 1974)
2. If the maximum depth is reached or the owl nodes are exhausted, the
   dragon is dead. (Usual owl reading says alive in those cases.)
3. Escape patterns are not used, except ones which connect to a
   strong friendly dragon.
4. Other patterns which do not clearly aim to make eyes (including
   expanding the eyespace) are also discarded.
5. Patterns to solidify potential eyespace and to split existing
   eyespace into two distinct eyes should be added.

This wouldn't be very hard to implement, except that we need to handle
the caching issues so that the usual owl reading and the local owl
reading are not mixed up.

In order for this to be useful we need of course also to track the
"local owl status" in the dragon data and take it into account in the
move valuation. (E.g. if we are ahead, give high value to make local
life for a dragon which is involved in a semeai, even if that semeai
is thought to be won. A typical example would be move 254 in the uhu
game where J4 or G5 would make local life for a black dragon involved
in a semeai.) 

> But I'm interested in another class of worms, which
> are tactically ALIVE at the outset of reading, but
> which become lunch during reading. I'll call such
> a worm a ``dinner'' to distinguish it from a
> lunch. If a dinner exists, and if owl_defend
> returns WIN, then the fact that there is a dinner
> should be recorded. Perhaps what Gunnar meant by
> ``absolute life'' is that the dragon is alive without
> dinner.

No, that's not what I meant, although it might be somewhat related.
For example, I would regard this dragon as locally alive:

|XXXXX..X
|.O....OX
|.O..X.OX
|OOOOOOOX
|.OXXXXXX
|OOX.....
|XXX.....

even though O has to capture the initially tactically safe lone X
stone if X tries to destroy O's eyes.

> How can dinners be identified? One thing that must 
> be borne in mind is that during the owl reading, stones
> are played and removed. The function owl_find_lunches()
> can declare a lunch found to be dinner but it does not
> have access to the state of the board at the outset of
> reading.

Wouldn't the information in the worm[] array provide this to some
extent? 

> The following scheme should work. There will be
> two lists static in owl.c. The first list will be
> the origins of unfriendly worms adjacent to the
> dragon which are tactically alive. This list will
> be initialized by owl_defend.

How does this differ from the boundary[] array in struct
local_owl_data?

> There will be another list of dragon dinners,
> initially empty. If owl_find_lunches ever finds a
> dragon lunch which is in the same string as one
> of the stones in the first list, then it will add
> it to a list of dragon dinners.

Does it make sense to store this in a static list? Dinners found in
discarded parts of the search tree shouldn't be very relevant.

/Gunnar