FORTH GO

I went on my first backpacking trip this week-end. It was a one-night trip with Scott in the Uwharrie National Forest which is a little-known park in central North Carolina. We combined two trails to make about a 10-mile loop, camping somewhere in the middle. The book, Uwharrie Lakes Region Trail Guide had good coverage of the trails, except for the campsite locations. The book showed 3 or 4 campsites on the trail we hiked, but there were probably twice that many decent sites.

The weather was great, with the Friday’s 90° heat mitigated by the forest canopy and no rain. Unfortunately, the Uwharrie/Dutchman’s Creek trails don’t offer much scenery. The forest is actively logged, so it’s fairly young with no big trees and instead lots of underbrush. The pictured mushroom is about the only interesting site we ran across; it must have been 6-8 inches tall.

All my equipment did OK except for my new backpack, which seems to be too short for my tall torso. It’s an ultralight Granite Gear Vapor Trail. Anyone want to buy a slightly used backpack? The other stuff (boots, sleeping mat, freeze-dried food, hydration pack, wool socks) all worked fine.

I’ve updated the FindPrimes Benchmark page with results running under Windows. I also updated the C++ code to work around the GCC compiler bug that produced incorrect results at higher levels of optimization, so now the Xcode C++ times are as fast as the Java times. On Windows, all the languages produce about the same times except that the Java version is slower on the first test (Linked List).

I’ve posted a short write-up with code of a FindPrimes Benchmark to compare Java, C++ and C# execution speeds on my Mac. Summary: C++ takes 1.5 - 2 times as long as Java and C# takes 3 times as long as Java. I didn’t expect much from C# (Mono) on the Mac, but who knew Mac Java was so good or that Mac C++ compilers/libraries were so bad?

Is this a positive sign?

I’ve been playing around with the GNU Chess code trying to understand the minimax algorithm and its alpha-beta pruning. The pruning offers a chance for a huge optimization if you can immediately refute candidate moves. Unforunately, refuting a move often requires finding the best response, which means searching the whole subtree, which defeats the purpose of the optimization. So implementers typically guess at the best refutations with checks, captures and moves that scored well in other subtrees (a.k.a. “killer” moves). My tinkering didn’t have any real impact on performance, but I’m getting a better idea about how things work.

Anyway, in the process of exploring the code, I noticed some of the output was being duplicated. I’ve posted a new version to chessbox.org with the minor bug fixes.

One downside of living in a heavily-wooded neighborhood is the abundance of deer and other pests. They decimated our azaleas over the winter but have left us mostly alone this spring. I guess there’s plenty to eat this time of year.

However, we only had our annuals in the ground a couple of days before I found the bare stalks in thid photo. One half-buried leaf remains. It’s as if the leaf dove into the mulch to avoid being eaten by the deer. Time to spray more Deer-Off.

My Java port of GNU Chess is now available at a new domain name www.chessbox.org, which is just a redirect to www.forthgo.com/chessbox/. The tagline for chessbox is “a collection of chess pieces” allowing it to be a home for various open source chess programs that I (or friends!) might port/derive/create as time and interest allows. The Java port of GNU Chess is now called “chessbox_gnu4j”. If you’ve got a better name, I’d like to hear it.

The code is released with the same license as GNU Chess, GPL. I’m not sure if I had a choice in the matter since it is clearly a derivative work of GNU Chess.