Aart's Blog

I just released version 4.1 of Chess for Android, available at Google Play or as direct download (including a version with network/SMS permissions). The new features include: Ability to send SMS messages (PGN, FEN, UNICODE, engine analysis) Ability to enable/disable built-in book (useful when imported engine book should be preferred) Larger engine analysis font Further localization and internationalization To send an SMS, long-press the notation window, and select "Send SMS", which pops up the window shown below. Simply fill out the phone number (which will be remembered for next time), and select between PGN, FEN, or UNICODE format (or engine analysis of an imported engine). Pressing the "Send SMS"  button will send the text message. The concise FEN format will be useful for correspondence players, since it can be directly copied and pasted by the other player (I have not implemented an SMS listener yet). The UNICODE format sends the current chess

Like many others, I learned Basic and 6510 machine code on the Commodore 64, a present from my dear grandfather and parents. Although nowadays one can relive the good old times with emulators, such as CCS64 or Vice, and a cross-assembler, like my own win2c64 , nothing beats the real deal! Today I tried to get my old Commodore 64 and 1541 disk drive, bought in Europa, running again. A few 110-220V adapters, a S-Video cable, and some PAL/NTSC settings later, I have my old friend running again. What made me extra happy is that the 1541 could still read the 5¼" floppy disks with my old programs that I wrote back in the eighties, such as the music editor on the screen shot. I am going to try to copy those onto my hard disk, so others can run these in an emulator.

Inspired by Rein Halbersma's kind encouragement, I have started some work on an international checkers engine. After all, " dammen " is the variant I grew up with in The Netherlands. Since I have implemented BikJump for chess, BikMove for American checkers, I decided to name this upcoming engine BikDam . I already had some fun hacking a, hopefully, efficient move generator. The rules for captures were very interesting to implement. Here are the perft number from the start position of 10x10 international checkers (a.k.a. dammen). In contrast with my American checkers move generator, here duplicate captures are removed. perft(1) = 9 in 0 ms. perft(2) = 81 in 0 ms. perft(3) = 658 in 0 ms. perft(4) = 4265 in 0 ms. perft(5) = 27117 in 1 ms. 27117.0 KN/s perft(6) = 167140 in 3 ms. 55713.3 KN/s perft(7) = 1049442 in 22 ms. 47701.9 KN/s perft(8) = 6483961 in 78 ms. 83127.7 KN/s perft(9) = 41022423 in 434 ms. 94521.7 KN/s perft(10) = 258895763 in 2599 ms. 99613.6 KN/s perf

My quest for deeper perft numbers for 8x8 checkers using has reached depth 28. Below you see the perft(28) breakdown per move, called "divide". As stated before, the numbers were computed on a cluster of machines, optimized with a "hard collision"-free transposition table as well as bulk counting. The move generator does not eliminate duplicate captures. At this point, the limits of 64-bit unsigned integers have been reached. Although there are obvious ways around these restrictions, this seems a very good time to give this (by now probably insane) project a rest. I have updated this OEIS entry up to depth 26, and may add the higher depths also when I am a bit more comfortable with these most recent results. divide(28) 12-16 = 2400708339858199191 11-16 = 2431386196712611878 11-15 = 2231787529331259810 10-15 = 2186446356811761737 10-14 = 1872427919495823777  9-14 = 2285893686261887442  9-13 = 2969067990365356900  -------------------------- perft(28) =

With the new improvements in place, it would almost be a waste not to go deeper with my perft for checkers computation . Therefore, I computed perft(27) from the initial position of 8x8 checkers. Below you see the perft breakdown per move, called "divide". As stated before, these numbers were computed on a cluster of machines, further optimized with a "hard collision"-free transposition table as well as bulk counting. The move generator does not eliminate duplicate captures.   move                 divide(27) ------------------------------ -  12-16    =  516399283859880203  11-16    =  519502096014967805  11-15    =  476666239516455180  10-15    =  468705060101275533  10-14    =  400425747281243848   9-14    =  486493422418651579    9-13    =  631652334435528457   ------------------------------- perft(27) = 3499844183628002605 The implementation is "fault tolerant" against machine failures. Nevertheless, since I saw a few of these recove