After one month of disconnection, the endgame databases finally is back on line again. The building that my new place resides has no internet connection until we apply for it. To me, internet connection is like water and electricity that are very hard to live without. :-)
Friday, November 9, 2012
Thursday, October 4, 2012
Sunday, October 9, 2011
Wednesday, September 28, 2011
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.
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....
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....
Monday, March 30, 2009
Ideal iPhone browser
I have an iPhone. I use it for web browsing when I don't have access to desktop. However, the Safari coming with iPhone leaves a lot to be desired. Some fairly common features are lacking, although the multi-touch ability really makes it the best browser on mobile phone to date. The ideal browser for iPhone pretty much can be summed up as "Desktop Firefox" on iPhone with multi-touch ability. The following is the list of things to improve. If someone write such app, I imagine it to become a big hit.
1. REAL tab browsing: Why tab browsing? Some may ask. For people like me, it is close to insane to not have tab browsing. I don't know why. :-) Of all the browsers I tried on iPhone, and I have almost tried all the browsers, none of them come close to real tab browsing. A few of them do have tabs, but they won't load the page in the background, and they don't keep the page and position you are when you move around tabs. When you tap on a link, there should be choice of "open in the same window" or "open in a new tab." If "open in a new tab" is chosen, it should be immediately loaded while the user is still reading on the current page. There should be a indicator to let the user know the loading status. The user can then switch to the loaded page when it is ready, hence waste no time on waiting the page to be rendered. Once you move back to the original page, it should be quick and it should go back to the original stopping point. One example for this utility is to read Google news. When you are in the index page, you will find some interesting pages that you want to read, but you don't want to waste the time to wait for them to be loaded, especially on relatively slow 3G or EDGE network. You can then open them in the background tabs and keep on reading the current one. When you see the signal indicating a page is ready, you can then go to that page and read. When you done, you can go back to index page to continue reading. However, you don't want to waste time for the index page to reload, so the switch should be fairly fast. For this to work, I believe some cache work should be done. Also, one should be able to open as many tabs as he want. There, of course, will be limit, but it should be technical one, not arbitrary placed.
2. Save pages. Some web pages are long and informative that you want to visit in the later time after you have laboriously load it to the iPhone. Save page function will be very useful and time saving. A page should be saved with all the its accompany images if so desired, so when you read it from iPhone memory card, it should look exactly the same and all the links should still works. Of course, the link should link out to the unsaved page through network. This function actually is important part of the first function. As far as I know, the RAM of iPhone is quite small. You cannot load too many page on the RAM, especially you still have to share it will many other programs. In order to have many tabs, you have to push pages into flash memory at some point. Hence, it is very important to have a mechanism to save and load pages from flash memory.
3. Misc.: You should be able to find items list below in other iPhone browsers. These are some things I found to be good. Option to have auto-rotation on and off. Full screen browsing if so wished. History. Bookmark and mangement tool. Open page to Safari. Open from Safari. Clear browsing history and cache as a feature, not as lack of feature. :-) Recover to the state where you leave the program upon re-enter the program. The page you are viewing should be showed first, then work the other pages in the background and from flash memory, not from network. Stop loading upon command.
Really, all these functions are very common in desktop browser. I don't know what kind of restriction iPhone SDK has forced on developer. Hope someone somewhere can develop this app quick. I wish him or her making a big fortune.
1. REAL tab browsing: Why tab browsing? Some may ask. For people like me, it is close to insane to not have tab browsing. I don't know why. :-) Of all the browsers I tried on iPhone, and I have almost tried all the browsers, none of them come close to real tab browsing. A few of them do have tabs, but they won't load the page in the background, and they don't keep the page and position you are when you move around tabs. When you tap on a link, there should be choice of "open in the same window" or "open in a new tab." If "open in a new tab" is chosen, it should be immediately loaded while the user is still reading on the current page. There should be a indicator to let the user know the loading status. The user can then switch to the loaded page when it is ready, hence waste no time on waiting the page to be rendered. Once you move back to the original page, it should be quick and it should go back to the original stopping point. One example for this utility is to read Google news. When you are in the index page, you will find some interesting pages that you want to read, but you don't want to waste the time to wait for them to be loaded, especially on relatively slow 3G or EDGE network. You can then open them in the background tabs and keep on reading the current one. When you see the signal indicating a page is ready, you can then go to that page and read. When you done, you can go back to index page to continue reading. However, you don't want to waste time for the index page to reload, so the switch should be fairly fast. For this to work, I believe some cache work should be done. Also, one should be able to open as many tabs as he want. There, of course, will be limit, but it should be technical one, not arbitrary placed.
2. Save pages. Some web pages are long and informative that you want to visit in the later time after you have laboriously load it to the iPhone. Save page function will be very useful and time saving. A page should be saved with all the its accompany images if so desired, so when you read it from iPhone memory card, it should look exactly the same and all the links should still works. Of course, the link should link out to the unsaved page through network. This function actually is important part of the first function. As far as I know, the RAM of iPhone is quite small. You cannot load too many page on the RAM, especially you still have to share it will many other programs. In order to have many tabs, you have to push pages into flash memory at some point. Hence, it is very important to have a mechanism to save and load pages from flash memory.
3. Misc.: You should be able to find items list below in other iPhone browsers. These are some things I found to be good. Option to have auto-rotation on and off. Full screen browsing if so wished. History. Bookmark and mangement tool. Open page to Safari. Open from Safari. Clear browsing history and cache as a feature, not as lack of feature. :-) Recover to the state where you leave the program upon re-enter the program. The page you are viewing should be showed first, then work the other pages in the background and from flash memory, not from network. Stop loading upon command.
Really, all these functions are very common in desktop browser. I don't know what kind of restriction iPhone SDK has forced on developer. Hope someone somewhere can develop this app quick. I wish him or her making a big fortune.
Subscribe to:
Posts (Atom)