Re: [gnugo-devel] Readconnect

[Tristan Cazenave]

> > 90% is a challenge, what is the time limit you have in mind
> > for connection reading ?
> > 90% is doable, but doing it very fast may be hard.
> 
> I would guess that 90% is more than we need to consider the code
> ready to start linking readconnect.c into the engine. At what
> point does the engine work better using the code than not
> using it?
> 
> Maybe we should link the code in right now on an experimental
> basis, the same way the new semeai code is experimentally
> linked in now.

I do not know, I do not even know where it should be linked,
and what is exactly expected from it.
Linking it to the engine and testing it even experimentally
is needed now I think (the code can now read non trivial
connections, and it is interesting to see what the engine
does with it).

> 
> About the time frame, there are important areas where new
> reading code is needed:
> 
> (1) Semeai
> (2) Combinations (atari_atari)
> (3) Connections
> 
> Of these connections might well be the most important!
> We see lots of big mistakes that can be attributed to
> stupidity about connections.

Is it possible to test readconnect on these mistakes ?
Where can I find them ?

> 
> Semeai are being worked on by myself, and combinations
> by Gunnar and Inge. It would be good to get a reading
> connection module working sometime during the spring of 2002.
> 
> One point is that you'll get help from us when we understand
> what to do.
> 

And I can work more efficiently, when I understand better what
is really needed :)

One thing you can do is write and optimize the move ordering in 

moves_to_prevent_connection_in_two_moves
moves_to_connect_in_three_moves

but before that, experimentally linking the code to the engine,
and having some feedback on the shortcomings that need to be
resolved the most is maybe more urgent, as well as some more tests
on monkey jumps and similar commonly occuring problems you think
are important.
(I am currently working on a general solution to problem 2, but
it is not what is the most needed by gnugo I think).

Mayb sorting the connection problem by order of importance is
also a good idea (I started doing it for vie.tst and some of
my tests).

Tristan.