OpenGo

[Matt Gokey <mgokey@xxxxxxxxxx>]

I think there may have been some misunderstandings here.

Paul wrote:
>Matt Gokey wrote:
>>
>> I just finished reading 22 messages about int vs struct, byte
ordering,
>> data representation, and API philosophy, etc....
>>
>> IMHO, we're getting WAY off the mark!
>
> 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 wrote as a reminder:
> Lets finish discussing Jeff Greenberg's proposal for a flexible and
> portable Go environment "OpenGo" with a GUI, SGF support, GMP support,

> referee, and player proxies.  This code is not performance critical
and
> if the interfaces to these main components are reasonable -  the
details
> are irrelevant (just overload or wrap with a conversion fn.).

This restates the goals of Jeff Greenbergs first offer for a go
programming environment, most of which as I understand it is already
coded and functional.  And it the first few replies to his message there
seemed to be  the name of "OpenGo" being attached to this environment.
This is what I understand as "OpenGo".  His API certainly includes a
high level interface to the go engine as the player proxy interface.
And as I said before, if the interface is reasonable the details don't
matter.  Its a high level interface and can be altered within the player
proxy and go engine implementation in whatever way you wish.

Paul writes in response to the Jeff Greenberg OpenGo synopsis above:
> As you can see I rate these issues as slightly less important than the
GoEngine.
> But the nice thing about OO design is these tasks can go on in
parallel
> once the interface is specified.

I agree the go engine is the most important and the most difficult
aspect, however, without all this other stuff you don't have a go
program, and its difficult to experiment with an engine without a good
user interface.  It would facilitate testing engines, training engines
for those using AI techniques, and playing different engines against
each other.  I really would like this "OpenGo" to materialize.  Many of
us have full time jobs, and don't have the time to invest in coding a
full computer go program.  We really need to hear from Jeff Greenberg
though - we can't speak for him.

I got the impression the many messages were attempting to workout
classes and interfaces internal to, or used to implement a go engine as
opposed to a high level go engine interface.  Its hard to tell, since
the arguments seemed to lose focus and start talking about ints vs
structs...

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?

I'll repeat:
>I'd like to see Jeff's "OpenGo" full spec and interfaces published
>publicly here for comments by computer go programmers to allow Jeff
time
>to incorporate any agreed changes before he first releases the "OpenGo"

>code.  Jeff, is this something you would be willing to do?

Matt