Re: GO engine interface

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

Henrik Rydberg wrote:

[snip]

> assuming something like: struct Point2D { int x,int y; }. As far as I
> know,

Ah ha . . . we already hit a question about representation. I would use
a single int. In this case there are trade offs each way. I would not 
argue about it much (I can always provide my own map onto an integer
from a pair).
But many of my things would suffer (maybe a 3 times reduction in speed
?) ON the other
hand some other schemes may suffer if forced to use a single int. 

> > I think it would be nice if a set of basic GO types could be agreed
> > between programmers
> 
> I agree, but only for more complex types that cannot be treated in
> the above fashion. It's hard to know where to draw the line, though. :)

 Yep. I would argue that the types required for a reasonable effecient
low level board managment such be standard types.


> > there could be standard library for all to use. Legacy code would need
> > to provide an interface to these types but new code could be based on the
> > predefined types and develop faster because there will be a base of code
> > that operates and the predefined types.
> > ...
> 
> You do have a point here, and I definetely agree with you that with such
> a
> codebase, things would develop quicker. But as I see it, there are two
> ways
> to go: either one starts with something very simple, and let the
> community
> develop the standard as it grows,
> or one could try to do it correctly
> from
> the beginning. I think all experience points at doing the former, since
> even
> the core code probably will be rewritten several times anyway, before
> everyone
> is pleased.

 The amount of time to spend in design is always a difficult question. 


> > Also if you go for using simple types you lose the posibility of
> > passing references to structures to comunicate. This of course will slow
> > things down considerably
> > ...
> 
> Yes. No point in using a language inefficiently. But what the data
> for such issues should look like is likely to be argued about, and that
> is
> why we need a coordinator, I think.

 How about a show of hands to see how many people would be interested in 
contributing to such a project. I think the first job would be hammering
out
the spec for the lowlevel board management and basic classes. This would
need
a fair amount of discussion,  (is this list the forum for such a debate
?)
Questions that can not be resolved by argument could be resolved by a
vote
(we need an odd number of people ?) I would be interested in being part 
of a core team. I am not sure if we need a co-ordinator (what would be
the role
of such a job).


 cheers Paul.


p.s. <pubgo history mode on for any one interested>

In the initial phase of pubgo (several years ago) I came along 
with a program written totally by myself, I had
at that time virtually no experience of OO design and only parts of the
program had been implemented in C++ by myself. Bruce Cropley (an
experienced
OO programmer) took my code and decided that it needed a rewrite. He
took
it on himself to reimplement the board managent. I was slighted  miffed
because
of course a thought there was nothing wrong with my code :-) However we
spent
quite a long time and many e-mails. Before the board spec was decided,
Bruce
rewrote the board manager from scratch and I had no difficulty what so
ever 
in interfacing it with my search engine code. Since that time the code
has
hardly been touched (just some minor bug fixes). I learnt a lot about OO
programming  in this process. I have had to live with a few things that
I would have done different but Bruces code was far more robust than my
original
code (but significantly slower). My own contribution has been
investigating
the use of proof number searching and attempting to embed GO logic into
the search tree. For example in my search engine it is possible easy 
(If you know what you are doing) to settup  a search node that looks at
the
stabiltity of an objective (the most interesting things in GO are things
that
change status if the person to move changes). The search engine I have
developed
is IMHO very powerful but very abstract. I have tried to put as much of
the intelligence
as possible into the leaves of a search. This probably makes it fairly
difficult for
other people to understand and use. The coupling of the absract search
engine to the GoBoard
is trivial all that is required is a hash state so the  search tree can
merge duplicate states.
I also require an additional hash code for the current battle/objective
(If a duplicate board
state is found I need to know if this was for the same objective before
merging the tree).
I am pretty confident that I could interface the search engine to any
lowlevel board manager. (My actual
move suggesters is a different matter, here lies a tricky coupling
problem :-) ).


 Currently pubgo can solve string tatics problems. The same search
stratergy can solve life and death
by brute force (OK for strings that die but needs life detection to make
survial better, at present
life is when there are no opponent moves, statisfying that this works
but not really on).

 The search nodes for string tactics are very simply first and second
order liberties. Not very
clever but it is proof of concept stuff.

 For me to progress any further would require a massive effort in
programming lots and lots
of GO heuristics and analysis. I would very much like open-go to succeed
because I could
then concentrate on the search engine stuff which is what I find most
interesting.