Re: [gnugo-devel] trevor_1_13.2 & question

[Daniel Bump]

Trevor wrote:

>  - It seems that a lot of the owl problems depend on connections, and
> there are a number of connection-like patterns w/in the owl patterns.
> Is this the long term idea, or will the OWL code eventually all the
> connection code directly to determine cuts/connections?  This new
> test case is a perfect example of a very simple cut to kill.

There is a basic design issue with connections, which is whether
the code should be pattern based (like owl.c) or implemented
in low level C (like reading.c). In Tristan's implementation,
it is implemented directly in C without calling the pattern
matcher. This has some obvious disadvantages but it has
one important advantage, as Gunnar pointed out, namely it will
make it possible to call this code from the owl code.

There are two reasons why a pattern based connection engine
would not be called from the owl code. First, the pattern
matcher is currently not truly. Actually it can call itself
once, which we needed to do so that an autohelper could
consult the owl code. See the comment at the top of
global_matchpat.

(BTW, isn't it time we renamed global_matchpat back to matchpat?)

Second, there is the matter of speed. We don't want to
call something slow from the owl code.

I think the answer is that we should start keeping track
of positions where the owl code could make use of connection
analysis and as soon as our level of confidence in the
readconnect is high enough that we want to use it systematically
we can start thinking about calling it from the owl code.

Dan