[ List Latest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Comments/Ratings for a Single Item
I improved the implementation of Seirawan Chess in Fairy-Max. It now has the gating moves fully integrated in its search process, so it should be no longer possible to surprise it by gating. (With the exception of gating at the Rook position in castling.) In theory it can still be stupid, because it does not realize there is a last opportunity for gating. But since I built in a large preference for gating moves, it always gates early, so it is not likely to be ever left with un-gatable pieces in hand. Still obtainable at http://hgm.nubati.net/WinBoard-4.5.beta.zip .
I tried to figure out what is wrong with Elephant Eye that it would neither ponder nor analyze, but it merely seems that this was because it was still in book. When I first do a crazy move to get it out of book, pondering and analysis seem to work normally. I also fixed a bug in HaQiKi D. Analysis and undo both worked, but undo did not work in analysis mode... HaQiKi D is a bit hard to test, because it does not do illegal-move checking. (I was kind of in ahurry when I wrote it.) But from the things I tried now, it seems completely OK. I also improved UCCI2WB, so that it now prints time and node-count for Elephant Eye (who sends those in separate infomessages) as well. I put it all in the http://hgm.nubati.net/WinBoard-4.5.beta.zip package.
I think I fixed HaQiKi D (implementing both 'undo' and 'analyze' commands). The fixed version is now included in the http://hgm.nubati.net/WinBoard-4.5.beta.zip download. In a quick test it seemed to work (with still a small cosmetic error that it reports the score from the POV of the side not to move, as it usually does when pondering).
> Mats wrote: > WinBoard for Xiangqi doesn't allow analysis mode, and I cannot retract > moves and make another move, so this software is largely useless as > it stands now. I was shocked to hear this, as I remembered explicitly having implemented analysis mode in UCCI2WB. You seem to be right, however: for none of the included engines analysis seems to work. For MaxQi this is no surprise, of course; it does not even print a PV, so I never bothered to implement analyze mode in it. Fairy-Max also does not support analysis, as it does not support pondering at all, as analysis is a form of pondering. I am ashamed to say that HaQiKi D does not support analysis either. There really is no good reason for this, as it does support pondering. The SMP version I am curently developing actually does support analysis (as I support SMP by starting several engine processes with a shared hash table, where one of the processes is playing, and will eventually perform a move, and all other processes are analyzing the same position to fill the hash table with results the master process can use). I have not worked on HaQiKi D since May, I had forgotten that the single-CPU version did not have this yet. But you are definitely also right about another thing: HaQiKi D does not support 'undo'! This escaped my attention completely, as I only use it in engine-engine games. The 'undo' command is recognized in the interface code, which I simply stole from Fairy-Max, but it only resets the game to the initial position, and the routine that is supposed to re-enter all played moves is commented out. I will fix all this as soon as possible. Isee I also forgot to include HaQiKi D in the list of engines in the WB startup dialog... Elephant Eye simply seems broken. I have not figured out what the problem there is yet, but both pondering and analysis seem not to work. This is not a problem with the UCCI2WB adapter or with WinBoard, that much I already know. I do have other UCCI engines that seem to work for analysis without problems. In particular Binghewusi. A lot of free UCCI engines can be downloaded from www.xqbase.com (you will need a translator, as it is all in Chinese, but it is worth it). You can download Binghewusi (sometimes referred to in translations as 'Soldiers Creek 54') there. If that does not work, or you want a newer version, I can send it to you by e-mail.
OK, I started a new thread for this to put an end to the off-topic posting. OK, the Seirawan algorithm Fairy-Max uses obviously sucks. Let me tell you the full story about this: A colleague engine author of mine recently converted his very strong Chess engine (2800 Elo, so about 800 Elo stronger than Fairy-Max) to an S-Chess engine, as a commercial project. I learned this last spring, and we came to the conclusion that it would be nice if we could use XBoard as a GUIfor it. So we agreed that he would convert his engine to WinBoard protocol (it was originally UCI), and that I would add it to the variants supported by WinBoard. And we defined the necessary protocol extensions that would be needed to encode the gating moves. After that, nothing happened for some time. (I was busy writing a Shogi engine.) But a few weeks ago we set a release point for WinBoard 4.5.0, (early December), and I wanted Seirawan Chess to be in before that. So I just plunged ahead without an engine, and implemented it in WB. But I had nothing to test the engine functions, which is a bit risky. So I decided to do amakeshift implementation of Seirawan Chess in Fairy-Max, which already knew the pieces, so that I just had to add the gating. But I implemented it through a kludge, as my only interest was really to have an engine that would support the protocol, and I did not worry much about playing quality. (As that would be exceeded by 800 Elo when the other engine became available anyway.) So what I did was implement gating at the levelof the game move, but not in the search. Fairy-Max selects its moves without being aware that any gating is possible, and if it happens to move a piece from the back-rank, it gates in any yet un-gated piece (first Hawk, then Elephant). I later refined this a bit by checking that the score of the opponent reply after gating was not suddenly much higher than it was in the original search without gating,in which case I would cancel the gating, as I was apparently gating in a super-piece on a square that was under attack. The idea was that by gating in at the earliest opportunity, before there were any tactical complications, I could get away with doing it without thinking about it. Now I see this reasoning was flawed: Fairy-Max does his own gating, all right, but the opponent can of course still delay the gating for as long as he wants. And then surprise Fairy-Max with it while engaged in tactics. This is exatly what happens here. Fairy-Max plays 9.Bg5, because he thinks he can refute 9... Qxg5 with 10.Hc7+ to grab a Rook. (That this locks in its Hawk this way, so that it might be doomed in the long run, is beyond its strategic abilities to recognize, and even in engines with mobility evaluation the poor Hawk mobility would never outweigh a Rook. Otho-Chess engines program this as a pattern (with N in stead of H) to discount such a doomed Knight.) So the plan is good, but of course did not count on an Elephant suddenly appearing on d8(9... Qxg5/E) to defend c7, and thwart white's ill intensions... I guess this proves that my makeshift approach is just too simple,and that you can never play decent Seirawn Chess this way. The gating really has to be fully in the search. I amnot sure it would be worth it todo this in a general-purpose variant engine, though. Anyway, thank you for exposing this weakness. As for the possibility to drop the pieces: the strong engine I was talking about actually supports two variants: official Seirawan (or S-Chess, as they call it nowadays), and a variant where you can drop the pieces on the back rank whenever you want. I wanted to make it possible to play both variants as 'Seirawan' under WinBoard, and let the engine decide which drops or gatings are legal according to its current settings. WinBoard also does not check, for instance, if the piece that effects the gating has already moved or not. So one could say that Seirawan is only a partially defined variant in WinBoard. This is not uncommon: some of the other variants are even supported to a lesser degree, and can only be played with legality testing off to prevent WinBoard from interfering with the game because it thinks some of the moves are forbidden. In that case the engine is in full control, and when it decides an entered move is illegal, it tells so to WinBoard, and WinBoard will then refuse the move from the user. I probably should let WB forbid drops anywhere else than on the back-rank, however. These would be illegal under any circumstances, and it is easy to do. Note that I only started implementing Seirawan a week ago, or so, and that it is still in development.
Mats Winther wrote in another thread: WinBoard-4.5.beta.zip: In Seirawan Chess I can introduce an external piece to an empty square, which is against the rules. Another bug: I cannot introduce an external piece to the corner square at castling. I played a 3 game match between Fairy-Max and Zillions in Seirawan Chess (approx. 10 sec. per move). Zillions is vastly better and won by 2½-½. In game 2 and 3 Fairy-Max blundered away a piece. This must be a bug in the algorithm. Below is game 3. Notice Zillions's remarkable rook sacrifice at the end. [Event 'Computer Chess Game'] [Site 'DELL-7B4236477D'] [Date '2010.11.21'] [Round '-'] [White 'Fairy-Max 4.8P'] [Black 'Zillions'] [Result '0-1'] [TimeControl '30/600'] [Variant 'seirawan'] [Annotator '1. +0.24'] 1. c3 {+0.24/9 53} c5 2. Nf3/H {+0.28/9 17} d6 3. d4 {+0.23/9 16} cxd4 4. Nxd4 {-0.10/8 17} f5 5. f4 {+0.01/8 14} Nf6 6. Hf3 {+0.13/7 34} e5 7. fxe5 {+0.83/10 15} dxe5 8. Hxe5 {+0.82/9 15} Ng4 9. Bg5 {+0.87/9 44} Qxg5/H 10. Hf3 {-2.60/10 14} Qf4 11. g3 {-2.33/8 14} Qh6 12. Na3/E {-2.38/8 19} Ne3 13. Qc1 {-2.42/8 27} Nc6 14. Nac2 {-2.37/9 17} Nxc2+ 15. Nxc2 {-2.43/10 15} Qd6 16. Hh5+ {-2.24/7 14} g6 17. Hf4 {-2.18/9 14} Ne5 18. Bg2 {-2.14/8 24} Bg7 19. O-O {-2.03/8 28} O-O/E 20. Rd1 {-2.17/7 15} Hb6+ 21. Ne3 {-2.14/7 16} Nf3+ 22. Bxf3 {-2.27/10 21} Qxf4 23. gxf4 {-2.30/10 15} Hxe3+ 24. Qxe3 {-2.27/10 16} Exe3 25. Kf2 {-2.15/9 14} Re8 26. h4 {-2.22/8 15} Bf6 27. h5 {-2.23/8 14} gxh5 28. a3 {-2.96/8 28} h4 29. Rd6 {-2.82/9 14} Bg7 30. a4 {-2.88/9 13} Kh8 31. Ed2 {-3.03/10 14} Bf8 32. Rd5 {-3.04/10 15} Bh6 33. Rd4 {-2.94/10 13} h3 34. Rh1 {-2.42/10 14} Bg7 35. Rd8 {-2.38/10 14} Bf6 36. Rxe8+ {-2.25/12 14} Exe8 37. Rxh3 {-2.25/10 15} Eg7 38. e3 {-2.22/8 14} Be6 39. c4 {-2.16/8 17} Rd8 40. Ec2 {-2.30/9 15} Ec7 41. b3 {-2.31/8 15} Ec5 42. Eb4 {-2.33/8 14} a5 43. Ec2 {-3.55/10 15} Exb3 44. Bd5 {-3.56/9 15} Ed3+ 45. Kf3 {-3.55/10 15} Bxd5+ 46. cxd5 {-3.60/10 16} Exd5 47. Eg2 {-3.74/10 14} Rg8 48. Eh2 {-3.77/10 14} Rg7 49. Ef2 {-3.82/10 15} Ec3 50. Rh5 {-3.77/10 14} Bd4 51. Ee2 {-3.76/11 14} Rg3+ 52. Exg3 {-13.29/13 16} Exe3+ 53. Kf2 {-13.36/13 26} Ee4+ 54. Kg2 {-13.38/13 17} Exf4+ 55. Kh2 {-13.99/13 15} Ef2+ 56. Kg1 {-14.00/12 14} Ee2+ 57. Kf1 {-14.59/13 15} Exg3+ 58. Ke1 {-18.00/12 17} Exh5 59. Kd2 {-79.95/13 14} Ef4 60. Kc2 {-79.95/13 13} Ef2+ 61. Kb1 {-79.96/19 9} Ed2+ 62. Kc1 {-79.97/28 6} Ea2+ 63. Kd1 {-79.98/28 4} Be3 64. Ke1 {-79.99/28 5} Ec1# {Xboard adjudication: Checkmate} 0-1 /Mats
7 comments displayed
Permalink to the exact comments currently displayed.