Posts

Showing posts with the label chess engines

Copy to Clipboard (PGN/FEN)

Image
Version 1.2.9 of Chess for Android will enable users to export a game to another application, such as an editor, email, or another chess program: copy all moves to the clipboard as PGN (Portable Game Notation) copy the position to the clipboard as FEN (Forsyth–Edwards Notation) To use these options, long-press anywhere in the move list area. Then, the following menu appears. Select one, then exit the chess application and go to the application where you want to paste the game. For example, I picked Copy Moves as PGN and went to messaging and long-pressed the text area. Then Paste the contents of the clipboard into the message, and the game appears in PGN format (note that, for convenience, I use a slightly more elaborate algebraic chess notation than strictly required; readers should still accept that format though). Likewise, using Copy Position as FEN , the contents would look as follows.

Opening Book

Image
I added an opening book to Chess for Android. The opening book is small (slightly over 150 opening lines) and simple (transpositions are not recognized, unless the line is explicitly stored). Nevertheless, since the engine picks a matching line at random during the opening, the variety of play will increase. Version v1.2.8 (and onwards) supports the opening book, as well as a new copy-to-clipboard feature (more about that later). While still in an opening line, the message "opening" appears at the position that usually shows the engine evaluation, as shown below.

Miscellaneous Updates

Just a few unrelated updates. First, the Android App Review Source website posted a brief online interview with me on developing Android applications. Also, version 2.01 of BikJump ended at second place in the CCC 17th Amateur Series (Division 8) , which opens the possibility of promotion to a higher division. Many thanks to Graham Banks for running this tournament! Finally, Martin Fierz published Checkers Tutor for Android , a strong checkers program for Android.

Back to BikJump

November last year, I posted a blog entry on my progress with "Deep" BikJump, i.e. adding multi-threading to my engine to speedup the search. Due to many distractions, I have not worked on that feature since that posting.... The chess engine bug is starting to itch again, however, so I decided to pick this up. Hopefully I can release a SMP version of BikJump soon!

WBEC-Ridderkerk Ratings

Leo Dijksman kindly posted a chess engine rating list on the WBEC-Ridderkerk forum , based on edition 11 to 16 of the WBEC-Ridderkerk computer chess competition. Below I show some stats for various versions of BikJump. Rank Version Elo + - games score oppo. draws 517 BikJump 2.01-x64 2111 105 105 30 50% 2109 27% 609 BikJump 1.8-x64 1995 132 125 30 70% 1798 20% 662 BikJump 1.1 1911 141 160 26 23% 2199 8% 693 BikJump 1.5 1851 131 131 25 50% 1823 12% Many thanks to Leo for providing the ongoing WBEC tournaments!

UCI option: Processors

My attempts to get consensus on standardizing an option to define the number of processors for an UCI engine on talkchess failed miserably, so I simply picked "Processors". The output of the prototype Deep BikJump on the "uci" command is shown below. id name BikJump v2.1P (64-bit) id author Aart J.C. Bik option name Hash type spin default 32 min 1 max 65536 option name NalimovPath type string default option name NalimovCache type spin default 8 min 1 max 2048 option name Ponder type check default true option name Processors type spin default 1 min 1 max 4 uciok I completed the threading toolkit for Linux and MacOS using pthreads and for Windows using the Windows threads. The latter was slightly more elaborate as I found out that CONDITION_VARIABLE (a synchronization primitive) is only supported on Vista, but not XP. Since I want to keep BikJump as portable as possible, I had to rewrite the Windows version using the slightly less elegant, but more widely supported

"Deep" BikJump

The 32-bit version of BikJump v2.01 (after a minor bug fix) received a first rating of 2103 RUEL . Since this was tested on a Pentium IV processor (not good for bitscans), I am looking forward to get results back for the 64-bit version running on a Core 2 Duo or Quad platform. In the meanwhile, I have started work on Deep BikJump, featuring multi-threading to perform the search in parallel (commonly referred to as SMP support). Upcoming versions will be designated with the suffix P (e.g. v2.1P) to denote this new parallel support. Because I want to continue support for all major platform (Windows, Linux, and MacOS), I am working on a small threading toolkit that provides the right abstraction for keeping the major part of the chess engine unaware of details on Windows threads and pthreads.

BikJump v2.0 released

Besides switching to a home-brewed bitboard representation, other parts of BikJump underwent refactoring as well. Some modifications turned out to modify strength negatively. I already wrote about null moves below. Furthermore, because the new bitboard move generator generates legal captures much faster than all legal moves, the quiescence search originally had been modified to look at captures only. After including checks again in the first few nodes, some bad tactical errors were avoided. Similarly, late move reduction had become too optimistic, and needed some adjustment towards the scheme used by the older BikJump. The "perft" nodes-per-second performance (which everybody measures differently; I simply traverse the complete tree with the same move generator that is used in search, including some bookkeeping) is about 13000KNs on a 2.66GHz Core 2 Duo. The nodes-per-second of the actual search in the first Nunn position is now about 1070KNs (64-bit) and 790KNs (32-bit)

A nice result

While I am struggling to translate all "improvements" of BikJump v2.0 into actual stronger play, BikJump v1.8 became third in group A of the 5th Division WBEC Ridderkerk edition 16 and qualified for the final.

A new logo for BikJump

Image
Now that the new BikJump is taking shape, it is also time to upgrade the UCI engine logo to reflect the new version. The old logo of v1.x and the new logo of upcoming v2.0 are shown below (both kindly designed by my sister Elies ): The new logo no longer contains version information, since most chess GUIs show the version information elsewhere anyway. Furthermore, now I can keep this logo for many BikJump generations to come. As for some background on the logos, the three colored bands hint at my Dutch origins (our flag). The jumping horse obviously relates to the knight in chess as well as the name BikJump (derived from my last name, not yet hinting at a "big jump" for computer chess unfortunately). Graham Banks also designed the following nice logo for BikJump that is used to post the results of tournaments on the CCRL Forum .

Another anti null move position

Image
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).

Some chess ramblings

Image
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