Symbolic: Status Report 2007.05.24

[sje]

Symbolic: Status Report 2007.05.24

The attempt at getting the cognitive search running on FICS is still delayed due to lack of time. Also, I still haven't upgraded the memory on the Compaq/Ubuntu machine; presently, it has only 512 MB RAM less 64 MB for vampire video. I'd like to bump the total to at least 1 GB to match the other machines in capacity, if not in speed.

Overall, my experience with Ubuntu environment is positive. The update mechanism works smoothly, although I wouldn't recommend it to anyone without a broadband connection.

New to me and available via the Ubuntu package mechanism is the Mingw32 tool chain that allows cross development of Windows applications on Linux. I'll have to look at this further to see if it's worthwhile. However, Symbolic relies extensively on the Posix pthread routines and maybe this won't transfer well via Mingw32. I really don't give a crap about Windows except that there's the slight chance that testing on yet another platform might help find portability bugs.

--------

Regression testing on an old Macintosh running Mac OS/X 10.2 Jaguar has shown a new bug in the ChessLisp interpreter that doesn't appear in any other platform. The cognitive search runs normally, but the program crashes with a couple of unexpected signals when trying to write the HTML for the search narration. My suspicion is that there's a problem in the g++ 2.95 library run time routines that handle file stream objects. I'm not looking forward to pursuing this as it just might not be fixable in my code and, if so, I'll have to abandon testing on the old machine.

--------

I've been making some minor progress on the upgraded mate threat management in Symbolic's cognitive searcher's specialized checkmate drive. It's slow going in part because I've been unable to find much relevant material in the literature on adversarial game tree search where the entire tree is retained in memory. A big help here are the Lisp routines VerifyTree and VerifyNode, both loaded with assertions and run after every significant action during testing. Of course, the post search HTML tree dump is quite handy -- if the search hasn't crashed, that is.

One goal in the upgraded mate threat management is to use incremental updating instead of a whole tree minimax to locate the next permissible mate threat. The lure here is having an O(log N) vs an O(N) algorithm, so there's a big tolerance for any added complexity. Furthermore, there's the promise of extending the method to cover non mate threats and possibly various defense selections. I note in passing that it's also possible to use A/B for the threat minimax and get an O(sqrt(N)) algorithm, but I'm holding out for a better approach.

--------

Testing the mate search on various mate in two positions always appears to work. The tree dump shows a complete proof variation set; each defense move appears, and each of them also has a correct checkmating reply. However, this is somewhat verbose and redundant as well -- the appropriate productions will always detect a mate in two and so an explicit, complete subtree is unneeded. My idea here is to smarten up the search to omit the forced subtree and have a concluding routine fill in nodes along a single variation. A similar extender routine can fill in other forced moves (e.g., tablebase moves). There's a big savings if these extensions are run only on the tail of the predicted variation and not on all forced subtrees.

[Alessandro Scotti]

New to me and available via the Ubuntu package mechanism is the Mingw32 tool chain that allows cross development of Windows applications on Linux. I'll have to look at this further to see if it's worthwhile. However, Symbolic relies extensively on the Posix pthread routines and maybe this won't transfer well via Mingw32. I really don't give a crap about Windows except that there's the slight chance that testing on yet another platform might help find portability bugs.

Mingw32 will let you call the native Windows API (e.g. CreateThread) but if you have a lot of POSIX code then going with Cygwin might be a better choice. I usually like to have explicit control over the platform dependent stuff so I generally compile with MS Visual C++ or Mingw32 on Windows, and gcc with the POSIX API on the other platforms.

[sje]

I've already gotten Symbolic to run under Cygwin. It works, but the execution is a little choppy with respect to pipe I/O and thread scheduling fairness. At least this is the case on my 1.83 GHz Core Solo Toshiba notebook; it's possible that a dual core Cygwin environment would perform better.

In defense of Cygwin, I note that the project has a fairly aggressive update policy and the product just keeps getting better. It may be only a matter of time until it can run Symbolic as well as does Linux or Mac OS/X.

A very limited test of MS Visual C++ compilation failed on most of Symbolic's sources as it couldn't handle a "use namespace std" statement appearing prior to various include directives. I suppose I could fix this if I had to.