Re: Comment: Is this the computer go mailing list?

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

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 ? Do we have any volenteers ? I might
be able to set something up but I have never set up a mailing list
before
(but I have a friend who has).

> As Stuart Cracraft has been asking, if anyone wants to donate their go
> engine to GNU Go or otherwise share the source to their go engine that's
> fine and would be greatly appreciated by the go programming community I
> think.   Likewise, if we share code or pseudo code for particularly
> interesting or clever algorithms/techniques that would probably be
> appreciated too.
> 
> But we are not going to agree on objects, or internal interfaces for a
> go engine - look at the trivial matters no-one can agree on already!

 I am not sure that this can not be resolved. It is healthy to argue
about
such matters. In the end of the day people will have to yeild a little
to go with 
a majority opinion. If they don't then then they will not be able to
share
in the fruits of the rest.


> Go
> playing software is at way too infantile a stage to jump to that!  The
> go engine is not a good choice for standardization.

 I think we are in need of some definitions here so we know what we are
talking
about. I have already got quite confused with some of the discussions in
these
threads because I do not share the same definitions. Here are mine (I
hope these
comments are of a general interest to this list)


GoBoard -- The role of this is to maintian a the board state and be
capable of
           undoing moves. The GoBoard understands about legal moves Ko
etc. It
           takes off captured strings and replces them.
           Because the GoBoard requires a certian amount of data
structure to maintian
           itself but it should not attempt to do much more than this. 
           I believe the GoBoard should be the kernel of open-go and all
the initial
           effort should be in getting this right. The GoBoard should
not be subclassed
           but extended using views. This keeps the coupling down to a
minimum.
        
GoGui  --  maintians a view of the GoBoard and may also act as a
controller. It is highly
           likely that individuals will need specialized GUI components
to display and interact.
           (for example in pubgo  I like to be able to draw the
boundaries of areas). I do not
            think to much about the GUI. GUIs are trivial compared to
most other  things in GO.
            However, a minimal class with the basic capabilities would
be nice. This would then
            be subclassed to allow specialized behaviour.

GoEngine -- I have not got such a class in pubgo. The nearest thing I
have to, what I think others
            mean by this term, is the GoGame class. The GoGame class
collaborates with 2 absract
            GoPlayers and the GoBoard. In pubgo these classes are quite
small and trivial.
            Because people will be wanting to try out there own stuff.
The GoEngine must be extendable.            
            I have not thought too much about this.

SearchEngine -- Computer GO players tend to have these. The role of the
search engine is to 
                suggest moves. Normally it involves some sort of
recursive search.
                It will also involve some kind of strategic reasoning.
IN pubgo the reasoning
                is emmbed in the absract search tree. This appears to be
a very personal area. 


MoveSuggesters -- In pubgo the movesuggesters are integral to the leaves
of the search tree.
                  This is one area which there is potential for code
sharing. A move suggester
                  will tend to transform the basic data of the GoBoard
into a higher level 
                  representation in order to detect some kind of
feature. The routines that
                  do this transformation will depend on the interface to
the information
                  contained in the GoBoard (so it is important to get
this interface stable at
                  an early stage). Because these transfromation routines
depend only on the
                  GoBoard which is stable. It should be easy for me to
reuse another persons
                  analysis because we share the same GoBoard. I
visualize a utility library
                  which can extract features from the GoBoard. 
           

                

>  There are too many
> variations and ideas being experimented with to solidify anything
> non-trivial.  Furthermore, the engine must normally be optimized for
> performance and might not be a good match with generic C++ classes which
> will tend to produce comparatively slower code.

 At some point we need to clarify the design objectives. Speed is
important
but not as important as a simple clear structure. I estimated that using
a clean OO structure for the pubgo GoBoard made it about 6-10 times
slower
than my convoluted raw C version. It is my belief that the ultimate
computational
bottle neck will be in the movesuggesters. Even with pubgos simple
string tactic
suggesters profiling showed the most time was spent in these routines
(iterating on
string liberties, adjacent hostile strings and flood filling).  


> 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.).


 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.

 all the best Paul.