Tuesday, July 27, 2010

Endgames with DTC value greater than 240

In my previous version of program, I used one byte for storing DTC (distance to conversion) value. The biggest number allowed was 240. I used number greater than 240 for house keeping purpose. At that time, I was hoping there would not be DTC value too big and planned on solving it only when it is necessary. It is necessary! When I was building krn*kr* endgames, there were a few endgames exceeding this limit. I have done the changes to the code and solved the problem, but I didn't have their corresponding statistic pages until today. In the rook endgame list, you should be able to find:

krnbkrbb
krnekrbe
krnekre

These three endgame databases have DTC value greater than 240. The krnbkrbb endgame even has order upto 81 -- the biggest I have ever seen. You can enjoy them through the autoplay function of interactive Javascript board. It's mind boggling to me, and I could not understand them at all. :-) However, you are welcome to study it and post your comments.

Thursday, May 13, 2010

Endgame pages status update

It has been long time since I posted in this blog. However, the endgame database project is still undergoing, although in a slower pace. Nevertheless, there are some breakthroughs in this period of time. Maybe this period is so long. :-)

1. First of all, I have modified the endgame code so now it can handle steps to conversion greater than 240, which was the limit before due to one byte information less some maintenance space. When I was making krn*kr* endgames, I found out some lines are greater than 240. That forced me to modify the program. I believe this part is done correctly now. Just one example here:

http://lpforth.forthfreak.net/xiangqi-js/xiangqi.htm?3BK2R195B399992n64bk3r8

Look at the steps to conversion is now 273!

2. As you may notice from above example, I have to also modify the Javascript code so it can handle steps to conversion greater than 240. Now the number for draw is 999. The old draw number 255 now stands for win in 255 steps, just like the other odd number except 999.

3. In the previous post, I mentioned the multi-thread ability of the endgame code. It worked quite well. However, the hard disk access time became even more unbearable as the other parts are now so much faster. One day, I was talking to one of my friends, who had just brought an 8-core server with 24G RAM with price at around $5,000. This prompted me to research the price of RAM. I was then surprised to find the 4G RAM can be found at the price around $130 in Taiwan. I then maxed out the RAM space of the motherboard of the 8-core server that I am using, which is 32G RAM. With RAM this big, I can now put all the database information in the RAM while computing until I finish all the computation for each endgame database. I modified the endgame code again and the speed is much faster than the hard disk version. Now I can construct endgame databases at faster pace as long as the database size is under 32G. The limitation can be further raised by simply upgrading hardware. More cores, more RAM, and sadly more money going with it. :-)

4. The progress are not all rosy here. Since my computer is now working at much higher speed with motherboard harboring 32G RAM, I am seeing some new problems. The computer now shuts down by itself from time to time. One of my friend help me trace the cause to the overheating. It is not hard to imagine now that all 8 cores are running at 100% most of the time. I changed the harboring case for better heat dissipation. It was fine for some period of time until one day, one stick of memory failed. Replaced it, ran it, and then motherboard failed. I have just replaced the motherboard and running tests now. Hopefully, this time it can start doing some work and not just whining.

5. Another setback was the breakdown of my web server machine. It had severed me for many years and finally gave away. That forced me to move the web service to another machine. I have to modify the CGI code to accommodate the bigger conversion number and much much more endgame definitions anyway. It is not all bad that it is much easier for me to modify code in the newer machine. This work took me some time and I still have some problems with the server settings. It is very slow serving file bigger than trivial size, and it cannot serve the old Java chess board. As a result, the endgame databases are only usable with the Javascript interface, but at a slower pace. Please be patient waiting for me to solve these problems. If you have ideas on why it behaves this way, please let me know. I am running Apche2 web server on an Ubuntu distribution. I also have a firewall separating web serving space and my network space.

6. Since I still have some problems to solve, I have not updated the index pages yet. It means some available endgame databases are not listed in the index pages. You can try arrange endgame position of your choice. If you are lucky, you may find your position is available in the databases. :-)

7. I learned again that this Blog space is not available to the huge Chinese population. Is the relation of Google and Chinese government that bad? I may someday move this Blog to another space so Chinese Xiangqi fans can have access to it.

8. It looks like my main web pages need some updates. :-)

These are for now. Stay tuned....