One GNU Chess source file I didn’t port to Java was the random number generator, and that turned out to be a problem for processing the binary opening book files.
The board position hash codes are 64-bit numbers created by xor’ing a set of hash codes that come from the random number generator. These hash codes are written to the binary book file, so in order to read a binary book file, you have to get the exact same sequence of “random” numbers from your random number generator. So I ported over the random number algorithm and was then able to read the binary book files which allows the program to play moves from the opening book.
I also got PGN file reading working, so I don’t know of any remaining functional issues (except for the i/o handling, especially control-C, which I may just ignore).
I tried the program on the 300 “Win at Chess” problems. The Java version got 278 correct, and the C version got 284 correct. Both used 5 seconds per move on my Mac G5.
Is there any glory in winning the B division? That’s what it came down to in my final round game. I needed a win against Kevin to claim the “title” outright and a draw to tie for it. It looked doubtful for a while, but I got the win.
I traded queens early to force his king to recapture and lose its right to castle. At the first diagrammed position, I thought I saw an easy way to win a pawn–just trade away the knight at f6 and then take the now-unguarded pawn at h7. I regretted it immediately when he played g6 to trap my bishop. However, computer analysis says the capture was actually a good move, and it turned out I was able to hang onto the bishop for quite a while, partly due to threats against the king and other Black pieces.
Our moves weren’t always best, but they were usually in the top 5, according to Fritz. Until the position of the second diagram, that is, where Black blundered. Fritz recommends Bh6, threatening my knight, pawn, and king all on the same diagonal, but Black moved Rh8 allowing the knight fork. A few trades later, we arrived at the final diagrammed position where Black is tied down to watching over the advanced g-pawn and can’t keep the White king out of the center.
I probably could have scrimped by with 4 scoops of hardwood mulch, but it was nice having 5 scoops so I could be generous with it. I also bought cedar mulch in bags for the paths. At right is a shot of the backyard, which was tougher than the front since I had to carry the mulch up the stone steps where the cart couldn’t go. So in total, I’ve spread out 5 cubic yards of hardwood mulch for the beds and 18 bags (2 cubic feet each) of red cedar mulch for the paths.
Shoot. Just remembered I have seven more bales of pine straw to spread out…
Bonnie says we have weird azaleas. Most azaleas stopped blooming around here weeks ago, but here’s one that’s just peaking. We have others that are just starting to bloom, and we have some that bloom in the spring and in the fall.
The weirdest of all are those that die and bloom at the same time, like the one below. You can see a dying branch in the upper-right of the photo. I don’t know what’s going on, but it seems like whole sections of a plant dies off and those branches become brittle enough to snap off.
I’ve uploaded PGN players for my round 4 and round 1 games. Both of these games were wins playing black, which gives me 3 wins and a draw with one round to go. The round 4 game got off to a quick start with all 8 minor pieces traded off by the 16th move. That was fine by me since it would reduce the chance of time trouble, and it left my opponent with doubled pawns, but it also cut down on the tactical possibilities. However, the rest of the game was not dull. Douglas put all his hopes on a king attack by lining up all three major pieces on the f-file. I thought I had it covered and took the opportunity to pick up a few neglected pawns. He made the best move in the diagrammed position, but after a sequence of less-than-perfect moves for both sides, I avoided trouble and started pushing my passed a-pawn to win.
The round 1 game against Nancy had a couple of similarities. Both started with a Sicilian defence and with my queen venturing into enemy territory to pick up a pawn, but instead of counter-attacking like Douglas, Nancy made an effort to trap my queen. The net was getting pretty tight until she blundered and left a rook unguarded. Otherwise I think my queen can barely escape by giving back the pawn. The computer shows that my previous move (h7-h5) was a waste, and I should have moved my knight to d7 and then c5 instead with prospects for trading my queen for a rook and a bishop.
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…
The rhododendrons at the Rhododendron Bluffs at Duke Forest off Whitfield Rd. are in bloom these days. It was hard to get a decent photo since the plants are scattered along the hillside and they don’t get enough sunlight to have spectacular flowers. The trails, bluffs and the creek are plenty to make the trip worthwhile, and having the rhododendrons in bloom is just a bonus.
To get to the bluffs take the first Duke Forest entrance on Whitfield if you’re coming from Old Erwin. Then go left when the trail forks, and you’ll come out at the top of the bluffs. Google satellite map