FORTH GO

The Java port of GNU Chess is now doing well enough to play a game and beat me. To get the main alpha-beta engine to work I had to track down about a half-dozen or so translation errors I had made in going from C to Java. Fortunately, I got the C version to build under Xcode, which gave me a IDE with debugger that I could use to compare my code with the C code as they were both running. Just as fortunately, most of the errors made themselves felt pretty early in the move evaluation process, so it wasn’t too tough to track down what was going wrong by narrowing the window between when things were good and when they were bad.

There are several sets of “find the best move” problems that are used for evaluating chess programs. With 5 seconds per problem for the “BT2630″ set, my Java version of GNU Chess gets 7 out of 30 correct (10 if I increase the hash table size from 1K to 16K entries, and 16 if I give it about 30 seconds per problem), and the C version gets 11 out of 30 correct (12 with the bigger hash table). The C version is still running about twice as fast at processing positions. The hash table management appears to be a place where improvement is possible.

The toughest errors to track down were those that originated in the C source. In one case the Java version would get an IndexOutOfBounds exception evaluating a position, and it turned out the position was invalid as there was a black pawn on its eighth rank (it hadn’t been promoted). It made me feel a little better than the C code had the same problem, except that negative array indices executed silently there. I couldn’t find any problem with the move generation code or the move execution code, but I eventually found that there was a backdoor for stale moves to enter into consideration.

Moves in the hash table that were once good “killer” moves would be considered later even if the board had changed, as long as they were still legal. So at some point a move such as g2-g1 would make it on the list with a rook on g2. Later the move would be considered again when a black pawn was on g2, and the legality-checking code wasn’t watching for such a pawn move (since none would be generated by the move generator without also setting the promotion info). So a fix to IsLegalMove finally got things going.

Everything I test shows new errors, and now I’m seeing problem processing the opening book…

I decided to go ahead and convert the remaining printf() calls (too chicken to try switching to Java 5 at this point) and ignore the signal() calls so I could try running GNU Chess/Java. The signal() calls are only used for handling control-C to allow interupting of the think process. Not sure what the Java equivalent would be.

For a while, I would get early crashes when trying to run. Usually these were NullPointerExceptions due to uninitialized array members. IndexOutOfBounds errors were a little trickier to fix, and for one of them I had to actually run the C version to compare values. Turns out the array index was -1 there, too! I’ve already marked a half dozen or so places where the C code looks suspicious, so I think this effort will unearth a few problems in the original source.

There were a couple of errors to get around when trying to build the C version, which I’m guessing are due to different versions of the developer tools on Mac OS X 10.4. There is also a problem running the C version. It seems to process one command and then get a bus error. Coincidentally, the Java version has a similar problem. After processing one command, it gets lost trying to look for more input — there’s some threading issue going on.

The program has some self-test commands that I was able to use to compare speeds. The Java version appears to be about half the speed of the C version. Some results

Not bad.

Other tests, which actually try to find the best moves, are crashing …. If I can get past that, I may need a catchy name for this project. Jnuchess?

I’ve almost finished the mostly-mechanical first pass of converting the C GNU Chess code to Java syntax. I haven’t tried to compile yet, but there’s about six files out of thirty-plus that IDEA (world’s greatest IDE) says contain syntax errors. Most of them are complicated printf() calls that I put off, thinking I might just start using Java 5, which comes with a printf() of its own. Also remaining are some threading issues like the use of the signal() function.

The most common C features in C GNU Chess that needed converting to Java:

primitive typedefs

better readability and type-checking by using BitBoard instead of long. I started using Java classes for these typedefs, but BitBoard operations much be fast, and I’ve have to deal with translating between the different semantics for assignment of primitives and objects.

macros

most were just constants; I made functions for most of the others, except a few like CLEARBIT that seemed easier to inline.

primitive reference parameters

I used the return value if possible; otherwise I passed the params in an array.

printf and scanf

only a few of these we hard to convert; Java 5’s printf will help

enum

something else that’s available in Java 5

implicit bools

I can’t count how many times I converted “if (c)” to “if (c!=0)“

goto

Java doesn’t have goto, but it does allow labels on break and continue, which sometimes resulted in creating dummy loops just so I could use a labeled break instead of a goto.