[Top][All Lists]

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

[gnugo-devel] inconsistnies in owl_attack and owl_does_attack

From: Evan Berggren Daniel
Subject: [gnugo-devel] inconsistnies in owl_attack and owl_does_attack
Date: Tue, 13 Aug 2002 22:40:47 -0400 (EDT)

OK, I've been looking at and thinking about the results from the automated
regression tests.  Basically, under some cases we get illegal switches in
the result of the matcher_status (now dragon_status?) function.  This is a
result, I believe, of moves which gnugo can tell are attacks on a dragon
but does not recognize as such when listing attacks.  (ie, not included in
the output of owl_attack, but owl_does_attack returns true.)

The reason, as best I can tell, is that essentially owl_does_attack looks
one level deeper in the tree than owl_attack does.  After some thought, I
believe this is the correct behaviour.  Also, this means there is no
simple solution.

One option is to improve attack recognition, but I believe this will only
mitigate and never fully solve the problem.  A perhaps better solution is
to find a way to look for general patterns that may have attacks, and
mark such cases critical without actually knowing the exact attacks.

Another option that doesn't fix anything but will probably improve play
would be to run owl_does_attack on all the top moves proposed, and make
sure that all attacks are being counted in the final valuation.  This way,
if, say, the third ranked move has an attack that isn't found, with a high
enough value to be worthwhile, gnugo will find it and play that move
instead of the previously ranked top move.

Anyone else have any thoughts?  I propose to begin working on this, but
probably won't get much done for a week or two...  school's starting back


Evan Daniel

reply via email to

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