Do we need a new mailing list ? PLEASE SHOUT NOW !!!

["P.J.Leonard" <P.J.Leonard@xxxxxxxxxx>]

Matt Gokey wrote:

> [I wrote]
> > I found it quite interesting. If this is not the forum for discussion
> of such
> > matters then I think we do need another list.  An  open-go mailing
> list ?...
> 
> Maybe it got lost in the fray of messages, but I didn't see much
> discussion about OpenGo.   Not as I understand it at this point.  I
> think this is a perfect forum for OpenGo as I understand it.

 I thought we had a few complaints about some of the stuff and requests
for a seperate list. I am happy talking in computer-go, but 
I think if we actually start arguing about classes and such there may be
subscribers to this list who will get a bit narked about the amount of
noise. An open-go list which would be a forum for nitty gritty debate.
What should I do ? Is there any harm in having 2 lists ? Only for the
administrator of the new list ? 

 So I guess it is up to people in this list to express a desire for this
discussion to be taken to another list. If no one speaks then I will
leave the open-go list asleep.

[snip]

> If we are talking about the high level interface to a go engine, I think
> we should see what Jeff Greenberg has to offer in his environment
> first.  I think we should slow down and look at the API Jeff has
> developed and perhaps use it to come to consensus.
> 
> If we are talking about internals of a Go engine I would prefer to keep
> it to code snippets, ideas, algorithms, techniques, etc.   Unless
> someone wants to contribute a go engine for GNU go or OpenGo (as a
> player proxy implementation) as a starting point as Stuart Cracraft
> would like to happen.
> 
> Here's a short list of different types of go engines/techniques being
> used:  Neural Networks, GAs, pattern matching, alpha beta searching
> (local and global), board evaluation based on probably thousands of
> different criteria and algorithms, goal directed searching, proof number
> searching, mathematical go endgames, databases for joseki and fuseki,
> many differing life/death algorithms, etc. etc. etc.  And combinations
> of these working in carefully constructed concert.   I think our
> abstractions of a go engine are radically different.  How can we agree
> on specific objects and interfaces for an open go engine and if we do
> will there be any breakthroughs with everyone working on the same
> potentially "flawed" engine?  Am I making sense or am I misunderstanding
> something?

 All these things sit on top of a low level goboard manager ? It is the
specification of this low level that I think is important at this stage.
E.g the GoBoard and BoardView classes in the pubgo scheme. If you can
not extract
such a scheme from your code than it is likely (IMHO) to be flawed.

 It is very likely that these components can be shared between many
GoEngine
schemes. The code snippets you mention above will only be of use if we 
share a common base. It is this base that should be the focus
at present. The GoModem etc stuff is important but it is not really
needed until
you have a program that can play GO ?  What we really need to think
about are things
like

 Program X can calculate some useful information,
 how can program Y use components of X and use this information during a
search ?.

 THE WRONG SOLUTION:

 Program X and Program Y are coupled via some loose protocol which means
they
both need to manage the low level board state (probably using different
representations).
When programY needs the information it gives programX its board state. 

It gets worse: it may well be that programXs information is described in
terms of features
which programY does not even know about !!! This means programX has to
minic the board state
during the search and provide call backs if certain features are
detected.

 THE RIGHT SOLUTION:

 Share a common low level board and base information processing on
layers of features extracted 
from the minimal representation. You only have to maintain one board.
You only need to maintain the
features that you are interested in. It is simpler. 


 Wake me up once all the GUI stuff is done :-)

 Cheers  Paul.