Friday, December 28, 2007

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.

Thursday, December 27, 2007

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:

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.

Saturday, December 8, 2007

A bug or not?

In the previous post, Michael mentioned in the comment stating the EGDB is good except a bug related to indefinite checking and chasing. I will take this chance to explain the situation. Chinese chess is different from western chess in interpreting indefinite checking/chasing. In western chess, three-fold repetitions lead to a draw. However, the win/draw/loss condition is depending on the context of checking/chasing in Chinese chess. The best solution I can come up so far is to treat indefinite checking/chasing as seed positions with win/draw/loss status based on Asian rules. Retrograde analysis was then used from this point on. This method lead to some problems (or bugs in some people's mind). First of all, distance to mate is hard to define if indefinite checking/chasing is involved. How many moves will you count when the losing side repetitive checks several times then moves to an inferior position? Since I could not solve this problem, I define the indefinite checking/chasing positions as seed positions with order. They are treated as final positions if the losing side refuses to change the pattern and is declared loss. In this case, this is the terminal node. However, if the losing side finally decide to move to inferior position with lesser order, there are more moves to be played. Take the first position raised by Michael as example, 硨七進三 keeps the following positions in the order 0. By keeping the positions in order 0, final win is ensured with certain depth. However, 硨七進二 will force positions to order 1, then drop back to order 0. We don't know for sure it is a longer sequence or shorter one. My current strategy is to keep it in lower order. As for the second position, moving red pawn left and right will force black knight to indefinitely chasing, so it has to move out of pattern or lose immediately. However, keep moving red pawn left will also force black knight to break out chasing pattern. These are two different ways to win. I propose a way for sure win. However, it may not be the shortest win due to the indefinite checking/chasing condition. To some people, it is not "perfect" in the sense it is not aesthetic to their point of view. To me, it is a practical way to solve indefinite checking/chasing situation with perfect win/draw/loss information. I don't have better solution so far. Is it a bug? To me, it is just a practical solution given the problem set. It's not a bug to me. :-)

Thursday, December 6, 2007

马兵残局 -- 马底兵能否必胜单士象?

马兵残局 is a interesting and difficult endgame. 马底兵vs单士象 is especially interesting. It was said to be a win pattern in some places, and draw pattern in other places. If you look 马兵残局 up at 东萍棋谱仓库, you will see 5 positions are said to be draw. These positions are copied from endgame book. However, if you look up these positions from EGDB, you will see they are all win positions. According to the statistics page of EGDB, 马兵vs单士象 is win for red, even it is 马底兵vs单士象. The following links are some posts pertain to this topic.

Here is another link that concludes knight-bottom pawn side will win.

Sunday, December 2, 2007

The endgame play in Movesky

I was fortunate to meet the author of 东萍棋谱仓库 over MSN last night. He offered me a VIP account in his database. I finally can check the so called 顶尖对局 in the database. The games are played in the highest level of Movesky with 30-minutes time control. I have checked with some endgame play to see in this over-the-board plays, how often do these top players, some with computer assistance, miss the winning or drawing move?

In the case of knpkpbb endgame, there are 12 incidents in the 顶尖对局 database. There are 3 wins and 3 draws hold, which means the outcome of the games matches the calculation of EGDB. In other word, the players didn't make blunder. In other 6 games, there are 5 missed win and 1 missed draw, which means the moving side missed the chance to win or to draw. These are 50% of improving space. I wonder if people study EGDB more, these kind of misses will be reduced.

With the method I mention in the previous post, this kind of survey became relative easy. If you find this to be useful, you may want to consider registering a VIP account from 东萍棋谱仓库.