gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] anchor_in_goal for owl_attackpats.db


From: Trevor Morris
Subject: Re: [gnugo-devel] anchor_in_goal for owl_attackpats.db
Date: Fri, 01 Nov 2002 14:54:24 -0500

At 07:42 PM 11/1/2002 +0000, Dave Denholm wrote:
>Arend Bayer <address@hidden> writes:
>
>> On Wed, 23 Oct 2002, Trevor Morris wrote:
>> 
>> > http://www.public32.com/games/go/trevor_3_11.1
>> >
>> > - Added explicit anchor for owl_attackpats.db patterns
>> >
>> >
>> > I duplicated a few patterns w/ different anchors.
>> >
>> > This explodes the size of the DFA database (about 4x !), but only
>> > if the "-m" parameter is omitted.  So, this patch doesn't actually
>> > cause any changes, since the -m option chooses its own anchor.
>> The only disadvantage at the moment are duplicated patterns, but I think
>> that is not a problem.
>> 
>> What worries me a little is the increase of the DFA size. I tried diabling
>> your additional patterns, and still got an increase to three times the
>> original size (note that there is _no_ increase without changing the mkpat
>> options in the Makefile). This is probably because "-m" is more clever in
>> selecting the anchor such that the spiral will be short.
>> 
>Possibly stupid question...
>
>do you need to disable -m globally in order that mkpat honours your anchor
>in a few patterns ?
>
>Can -m not just be refined to take into account explicit anchors, and only 
>apply
>its own heuristic if there isn't an explicit anchor ?

It's awfully handy to be able to test out explicit anchors, but yet have
them ignored by '-m'.  So, I don't have to worry about exploding the
DFA size with explicit anchors, unless there is some benefit and then
just drop the '-m'.

I think I'll create a new option ('-a'?) that makes sure that all of the 
patterns
are given an explicit anchor.  This will also set a (new) property on the
pattern database indicating that this database is designed with explicit
anchors (probably allowed us to do away with the explicit goal_in_achor
parameter).

-Trevor





reply via email to

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