[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Harri Salakoski
Subject: Re: [gnugo-devel] Gnu GO java1.5 porting
Date: Wed, 6 Apr 2005 23:08:25 +0300

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


t. Harri

reply via email to

[Prev in Thread] Current Thread [Next in Thread]