gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] atari_atari and restricted_defend1


From: Gunnar Farneback
Subject: Re: [gnugo-devel] atari_atari and restricted_defend1
Date: Sat, 24 Nov 2001 11:49:36 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Inge wrote:
> 1) Extend the restricted_ paradigm to include all attack and defense
>    functions.  The change would be very easy to do since it only
>    involves checking moves against a list before trying it. It would
>    also make the reading more general, but the question is wether this
>    would be useful in more places.

Notice that we can't use the caching of read results in the restricted
case and the caching scheme is not easily (without sacrificing speed
and/or memory requirements) modified to handle that.

> 2) Extend attack() and find_defense() so that they can give *all*, or
>    at least a number of, working intersections instead of just one.
>    Then we can check all the suggested defenses and see if one of them
>    works.  I even think that this would remove the need for
>    restricted_* altogether, at least in atari_atari.

This is very likely to have performance problems and possibly also
caching problems plus it adds to code complexity.

> I am interested in a discussion about this.  I will send the current
> state of my changes in my next mail if anybody wants to take a look at
> it.

3) Redesign. The restricted_defend1() was a simple way out for
atari_atari() but doesn't really scale for more general combination
sequences. It should be possible to find all relevant defense moves by
considering direct liberties, captures of opponent neighbors, and
possibly some more moves which are best found through pattern
matching.

Similarly I would recommend pattern matching instead of the general
attack_threats() function to find the attack moves. That should give
better selectivity (i.e. avoid including really silly attack threats).

/Gunnar



reply via email to

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