Re: [gnugo-devel] pre-rotate implemented

[Trevor Morris]

>I'm still interested in seeing what happens if we let the dfa
>provide a shortlist of patterns which *might* match, and let
>a separate matcher check them in detail. This might help with
>the explosion in data size.
Yes, this might help w/ the size a lot.

Any idea what percentage of states lead to only one possible
ultimate success state?

I'm wondering if it wouldn't also be useful to customize each DFA's
"spiral' path to minimize DB size.

I'm not too surprised by the database increase -
>Just out of interest, I tried kludging mkpat to add all 8 transforms
>of a pattern to a dfa, to see how well my implementation scales.
>(Adding one pattern at a time in situ).
IIsn't this just what I did?

>Unfortunately, I got fed up after 11 minutes on owl_defendpat.db :-(
>The current 3.3.8 mkpat did it in about 3 minutes, but it consumed
>vast quantities of memory (100Mb ?) to do so.
>
>Maybe building dfa's at run time is something we could do during
>opponents thinking time..? Should be plenty of time before
>the position gets interesting enough to need them.
I'm not sure that having huge DFAs will be a win, since there
would be almost no caching advantages.

>( Unfortunately, could be hard to debug, since the bug could be
>  due to a dfa which was built dynamically, and not available
>  when reproducing.
>)