Aart's Blog

My eight year old daughter Karina is learning chess and we have gotten into the habit of solving a few mate-in-one puzzles from Laszlo Polgar's book Chess - 5334 Problems, Combinations, and Games every night after homework. She is really enjoying it, especially when we are using an electronic DGT board coupled to Chessbase Fritz . Each time she solves a puzzle, Fritz rewards her by saying "checkmate" with a German accent.

I ran various tournaments using the " Max Euwe suite ", from the hand of the famous grandmaster who inspired many Dutch aspirant chess players, including myself. During the first tournament, Chess for Android detected bugs in positions 146 and 148 , where the castling rights are not set properly for white, even though white actually castles in the first given move (that is, the move the engine is supposed to find when used as a tactical test suite). For example, in position 146, the embedded FEN string in the PGN file: r1b1kb1r/p3q1pp/2pp1p2/4n3/3N4/8/PPP1BPPP/R1BQK2R w kq - 0 1 should really be: r1b1kb1r/p3q1pp/2pp1p2/4n3/3N4/8/PPP1BPPP/R1BQK2R w KQkq - 0 1

As a fun way to test the new opening suite feature , I conducted a fast match between the very strong Komodo 3.0 chess engine and the built-in Java engine of Chess for Android using the " beat the masters suite " (a version with 251 test positions). Komodo is clearly much too strong for my own humble engine and the suite was meant to test the quality of moves found by chess engines, not as an opening suite. Nevertheless, since some positions give one side a very strong advantage, it seemed like a fun way to test the new opening suite feature. The outcome was as expected: Komodo won most games and only a few draws occurred. However, Chess for Android had one victory. 1 Komodo32 3 AB    +491/  -1/=10 98.80%  496.0/502 2 Chess for Android  +1/-491/=10  1.20%    6.0/502 In the position below, with black to move and only half a second thinking time per move, Komodo played 1... Rxe2, which yields a lost position (black should have played 1...hxg6)....

Here is another interesting anti null move position, actually derived from a chess problem by Troitski. With null move pruning, engines are at risk of overlooking the simple mate in four (even Fritz11 under default settings fails to find the mate while search depths go over thirty!). The mate is found quickly, however, without null move pruning or by skipping the heuristic if only a few moves are possible. In this case, simply not trying a null move if few pieces remain on the board also works. Since I see no simple, yet general way to detect for what positions null move pruning should be disabled to deal with zugzwang, I decided to apply full move generation prior to the heuristic in the second generation BikJump as well. Overall tactical play seems to improve, at the expense of slightly slower searching speeds (luckily, move generation has become a lot faster compared to the first generation).

I am spending some free time rewriting the first generation of my UCI chess engine BikJump into the second generation by replacing the "mailbox" representation with a home-brewed bitboard representation, while carefully revisiting all other parts of the engine as well. The switch to bitboards has improved search speed substantially. In a typical middle game position, the nodes-per-second rating of the search increased from around 500Kns to close to 2000Kns on a Intel Core 2 Quad Q6700 2.66GHz (single-threaded 64-bit binary). Interesting enough, the strength increase is still disappointing given the major rewrite. Therefore, I am now performing experiments with tournaments and test positions to find more opportunities to enhance its strength. I like this test position (white to move wins), which I found on TalkChess , one of my favorite forums on chess (thanks to Chess Imager for generating the diagram). This is an anti "null move" position. The old BikJump, which t...