Re: [gnugo-devel] Gnu GO java1.5 porting

[Harri Salakoski]

> Just to note: I'm not a Java-hater, I'm programming in Java at my current
> paid job.  I just happen to be sceptical about this stuff...
I understand that, it is quite big project to port.

> Where do you get this information from?  Pointers r g00d.  Besides, GNU Go
> is written in C, not C++.
Aha. Pointer code is not used other "modern" languages also than Java.
You can code things efficiently without pointer logic.

> Simply translating something in a different language doesn't make anything
> clearer.  The most complicated things in the GNU Go is the engine.  I doubt
> you will manage to clean it up a lot while translating.
> Also, simply translating something into a language that is object-oriented
> doesn't automagically make that something object-oriented.  You could write
> OO-styled in C or not OO-styled in Java.  Java just makes going OO easier.
Even you point is ok, I am quite happy results of irrelevant code removal as 
one target.
Off course after all logic remainds or it could be impossible use testers in 
full benefit.

> > Computers change faster and base speed is not so important anymore
> Yet we prefer to optimize for speed when possible.  GNU Go is a 
> CPU-intensive
> program.
Ok, results for that part I don't know yet.

> > (actually it is easier to code very advanced data structures using
> > java and so on results can be sometimes even better)
> That depends on your being able to code advanced data structures in C.
Ok, I understand why "optimal c speed" is good. But AI is so much other 
things also,  more abstractions
benefit in many things, it is anyway different way of doing things. 
Forexample mentioned porting BoardLocation is class having lot of 
attributes, it makes code quite different than in GnuGo even logic is same.

> > Most of data structures are change dynamic size for example. XML makes 
> > input
> > output implementations simpler and cooler :). XML is used file format.
> > There is converter to      convert GnuGo patterns for XML. XML is used 
> > also
> > in game format instead of SGF(and converter still misses branches).
> I don't think this is a good idea.  XML is OK, but SGF is an established
> and widely supported format for Go game records.  By switching to XML you
> are losing compatibility with many programs.  GTP also relies on SGF to
> some small extent.
I intend keep SGF support using converter.

> > Out of porting or don't work:
> > Pattern reading and usage don't work yet.
> > Caches role are unclear or are out of porting like this new persistent
> > cache. all parts not belong AI are out of porting.
> > testing procedures are not ported(quite much work there)
> > features marked as #if 0 are out
> > ..
> To summarize, you are leaving out large part of the infrastructure we use 
> for
> developing and debugging GNU Go.
Yep. Goal is get same logical results from testers as minimum work effort.

> Can you please explain what are aiming at with your Java port?  Do you 
> intend
> to fork off when you catch up with GNU Go 3.6 and develop independently?
My goal is make good GO AI using java. My hoppy is EA, GA, GP related AI 
algorithms.
One of the plans is use GNU-go direct evolution in co-operational EA.
Another is evolve patterns using EA.
Anyway good GO libraries for Java are needed for many reasons, It seems 
there is none.

> fork off when you catch up with GNU Go 3.6 and develop independently?
It depends how good porting result is. If it is good I am sure there is some 
intrest for that.

> Paul

t. Harri