Broken computer fixed

My 64-bit machine that I used for constructing the endgame databases was broken for a while. It took some time to fix. Finally, I got it back two days ago. Now I can continue to run the verification program as well as build new suggested ones. Between the long time it took to build the databases and multiple changes to the program, some mistakes (such as the one meifire pointed out) bound to creep in. I hope the verification procedure will reduce the chance as much as possible.

64-bit Forth

One of the limitations in building larger EGDB lies in the biggest continuous memory that can be allocated in 32-bit system. Theoretically, 4G can be allocated. However, I can only manage to allocate around 1.4G in VFX Forth in my 32-bit intel box running Windows XP. I had a 4 core 64-bit system for a long time, but the 32-bit VFX Forth system can only get 1.4G memory again even though I have 8G sitting on the main board. Due to this reason, the biggest endgame databases I can build are with 11.2G (1.4G x 8) elements. As far as I know, there is no 64-bit Forth available for Windows at this time. The only one I know is gForth for Linux. Recently, I installed Ubuntu linux on my 64-bit system and tried out gForth. Converting my endgame program to gForth and to 64-bit is surprisingly easy. Suddenly, I have the capacity to produce endgame databases larger than the ones with 11.2G elements. Unfortunately, gForth is not known for its speed. It is estimated to be about 10x slower than VFX Forth for my endgame program. I am now testing 64-bit iForth. Since it is still in alpha stage, there is still long way to go. I shall update the progress here.

EDGE signal in Taiwan

Recently, a friend of mine told me there is EDGE signal from Chunghwa telecommunication company. Maybe they are preparing for official iPhone launch. I tried my iPhone and it works beautifully. The speed is acceptable. If there is difference between my 3G setting and EDGE, I don't notice. The feeling of not having to bring another smart phone around and enjoy internet connection everywhere with iPhone is pretty good. If you have iPhone and live in Taiwan, you may try it out.

Have fun!

Some further explanation of EGDB

meifire 其實對殘局庫的瞭解已經很透徹了。很多地方也解釋得比我清楚,所以我就從他的回答基礎上,再加說明。

meifire:

"order的含义在残局库的主页上有说明.我理解是:在当前局面前往被吃子的局面的途中,还要经过多少次弱势方可以长将或长捉的局面.

由此得到的几点推论:

對於只有一方有攻擊子的盤面，Order 都是 0,因为弱方无法长捉或长将

在order是正数时,value的值表示距离下一个弱势方可以长将或长捉的局面的着数.

当order 是正数,value为0时,弱势方的推荐着法都会造成长将或长捉对方,当弱势方被迫变着时,order就会减少(感觉似乎应该是减1,但我发现过例子是减很多的),而value重新变为正值,开始前往下一个长将或长捉局面,直到order为0,value也为0,则是到达吃子局面."

___________

meifire 的解釋清楚而正確。對order不見得只減1的觀察也是正確的。order會逐漸變小,通常在換捉不同子時,減的數目較可能會大於1。

關於看起來像是錯的推薦走法,我己經被問很多次了。不少人因此而認為殘局庫的結論是錯的。我一直想解釋清楚,但一直沒有用中文做過。一樣,我們從meifire的說明開始:

meifire:

残局库推荐着法首先当然是看结果,如果一种走法的结果为和,另一种为胜,当然选可胜的;

其次看哪种着法可以最快的吃子,不单独考虑"将死"和"欠行",因为残局库认为出现这些情况后,就是一方被迫送吃自己的将/帅,包含在"吃子"这种情况里了.而在考虑吃子时也不会优先考虑将/帅被吃的情况.

~~~~~~~~

會有看似錯誤的推薦走法,最主要根源於我最原先的一個設計決定。殘局庫可以記錄到吃將軍的步數(distance to mate, DTM),或是到吃任何一子,而進入子殘局庫的步數 (distance to conversion,DTC)。
在考慮過象棋的特性,以及殘局庫製造的效率,我最後選擇了 DTC。原因如下:
1. 由於象棋有長將及長捉的規定, DTM 似乎不太能夠成立。每次長將或長捉應算幾步?
2. DTC 在程式的運行上有較高的效率。

然而在選擇 DTC 後,便帶來了一些人觀察到的不自然現象。由於吃子勝和將死被視為同等,所以會有推薦走法出現一步殺的情形。在沒有更好的方法前,我只能選取我覺得最好的方法。

WMWifiRouter

WMWifiRouter

What is this to do with EGDB? You will ask. To be able to access my EGDB website through iPhone, I used an O2 Windows Mobile phone as interface to the 3G mobile network. The way I introduced in previous blog will work well, but it suffered from one drawback. The connect will drop out every 5 to 10 minutes. It is quite annoying if you want to use it for a long time. I came across WMWifiRouter the other day, and found it to be a excellent program for this purpose. It keep the connect on and you can even turn off the screen. My O2 can last for about 1 hour continuous use. I once even used it inside a car running on the highway without problem and disconnection. You can try it out. Here is another review which give high mark to the program. The main page may be down sometimes. You may have to try often.

Safari in iPhone

The bigtext version of EGDB query system is usable now over Safari for iPhone. Some improvements are wanted. However, it is usable for now.

3G iPhone

iPhone? What is the relationship between EGDB and iPhone? Since the day I had EGDB posted on the net, I always want to be able to access EGDB anywhere I want, which could be the park people playing Chinese chess. I have a Palm Treo 650 connecting to a 3G phone just to do that (among other things). Being able to connect to internet anywhere has a special appeal to me for a long time. The Treo interface is not so great when compared to iPhone. What if I can have a iPhone with 3G connection? It will be great. I didn't know a way to achieve that until one day I saw the following article:

http://www.pyrofersprojects.com/3gipod/3gipod.html

It described exactly what I want before Apple starts to sell 3G iPhone. Immediately, I tried out the idea in Apple store and prove it works as expect. I then bought a iPhone, and a XDA O2 atom as my 3G/3.5G modem. The combination works wonderfully. Now I can access my EGDB anywhere I want with good speed and good interface as long as there is 3G service available, which is pretty ubiquitous here.

I am pretty happy to have the combination. Saying that, there are still some rooms for improvement.

1. Of course, if there is true 3G/3.5G iPhone then I don't have to carry another phone as modem, it will be much better. For this, we have to wait for Apple.

2. XDA O2 atom runs out of battery really fast when both data connection and WiFi are on.

3. Safari refuses to run my big text interface as I intend it to be and no Java is available for it. I now stick to small text interface. Let me see if I can fix big text version from my cgi script.

If you also use iPhone to access EGDB, welcome you to leave your comments here.