Author: Heiner Marxen
Date: 13:27:29 12/24/01
Go up one level in this thread
On December 24, 2001 at 15:09:45, leonid wrote: >On December 24, 2001 at 13:30:10, Heiner Marxen wrote: > >>On December 24, 2001 at 06:47:47, leonid wrote: >> >>>On December 23, 2001 at 11:51:53, Heiner Marxen wrote: >>> >>>>On December 23, 2001 at 08:18:16, leonid wrote: >>>> >>>>[snip] >>>> >>>>>Probably our chess solving part is very close in response, even if your initial >>>>>speed is much better. How we ever come to this closeness is a mystery for me. >>>>>Few times I tryed to find some visible explanation for this but each time I >>>>>could see later that my explanation was wrong. Fact is that our two solvers >>>>>stays completely aside from main part of mate solvers in "heavy positions". >>>> >>>>That is not so much of a mystery to me: our two programs are the only >>>>non-trivial, brute-force, full-width mate solvers I know of. I.e. these two >>>>programs share a certain approach/algorithm which others don't do. >>>>[Alybadix may be an exception (I just don't know)] >>> >>>I am not that sure about this since I used special mate solver inside of Hiarcs >>>package. I presume that this specialized engin use brute force and full-width >>>search. It have nothing like selective search. Its work also give impression >>>that it make its hunt for mate in the same way like your program do. It look for >>>it at constantly growing depth. In the same time, I found no visible difference >>>between this engin branching factor for heavy positions and some other good >>>chess programs, like Genius, when those programs explicitly look for mate. >> >>(I do not have Hiarcs and have never used its mate solver, so I'm guessing) Hello Leonid! >I bought my Hiarcs around 2 years ago and it went with many engins inside. One >of those engins is Mate 2.0. It cold be that you will be able to find this >program on Web. Since I have a Linux-only box I suspect it will not run here. Most commercials only have Windows versions. From the icdchess store I see that Hiarcs 7.32 is avalaible for Windows 95, Windows 98, or Windows NT 4.0. Since I'm not going to install any Windows on my box, I'm not able to try Hiarcs myself. Such is life ;-) >It is after seeing mate solving engin that I was puzzled why your is not there. >Your is already compatible in many ways and you can ajuste even farther if this >will be needed. I don't know why nobody appears to be interested to integrate Chest. Maybe they just do not know about it, or dislike the non-commercial nature of it, or maybe just do not care enough about mate solving to even try. >>So the Hiarcs mate solver is "brute-force" and "full-width". I suspect it is >>not non-trivial, i.e. not many hours of programming/testing/development >>have been spent to speed it up. >> >>Whether this is correct or not should be possible to decide by the "basic speed" >>(time needed for say a mate in 4) and the EBF, as compared to your and my >>values. If the basic speed of off by a factor of 10 or more... there surely >>is something to improve easily. And if the EBF is consistently say twice as >>large, dito. > > >Today I looked into one position where I could see that our programs do quit >differently its inner work. In it your program went almost instantly where mine >was slow in responding. > >[D]RqqkqqqR/QPqbbqPQ/rNPBBPNr/PnpQKpnP/8/8/8/8 w - - > >8 moves deep mine took already 11 min and 28, when you only 8.62 seconds. >Conditions and computer are identical. Interesting! A factor of 79.8! On my K7/600 I did some experiments with this position: Chest 3.19 without hash: 8.44 secs Chest 3.19 with 42MB hash: 3.49 secs (says speed=2.15, really is 2.418) Chest 3.23 without hash: 7.55 secs Chest 3.23 with 42MB hash: 3.24 secs (says speed=2.13, really is 2.33) 42 MB was not necessary, 1MB would have been enough. 3.23 is my current development version. Why Chest here is much faster than your program I can only guess. For version 3.19 without hash (what you most probably did use), which is most comparable to your own program, I will give some info (statistics) and some comments, so you may come up with an idea, what could be improved for you. Timing info for 3.19: # 1 0.00 1.00 0- 0 # 2 0.00 1.00 0- 0 # 3 0.00 1.00 0- 0 # 4 0.02 1.00 0- 0 # 5 0.08 1.00 0- 0 # 6 0.36 1.00 0- 0 # 7 1.65 1.00 0- 0 # 8 8.44 1.00 0- 0 Timing info for 3.23 contains more details (that may help): # 1 0.00s 0kN 1.00 0- 0 # 2 0.00s 0kN [ 25.00] 1.00 0- 0 # 3 0.01s 0kN [ 5.54] 1.00 0- 0 # 4 0.02s [ 2.00] 1kN [ 4.42] 1.00 0- 0 # 5 0.09s [ 4.50] 5kN [ 4.17] 1.00 0- 0 # 6 0.33s [ 3.67] 22kN [ 4.24] 1.00 0- 0 # 7 1.48s [ 4.48] 97kN [ 4.48] 1.00 0- 0 # 8 7.55s [ 5.10] 482kN [ 4.95] 1.00 0- 0 The refutation table for 3.19 (command line option "-r") shows the top two plies, and the computed sub-result: refu 1: gxf8=Q Qxf6+ [ 7-] refu 2: gxf8=R Qxf6+ [ 7-] refu 3: fxe7+ Qf8xe7 [ 7-] refu 4: bxc8=Q+ Qcxc8 [ 7-] solu 1: Bxc8 [ 1+] refu 5: bxc8=R+ -- [ 7-] prom beaten refu 6: Bxc7+ Qbxc7+ [ 63-] refu 7: gxf8=N Qxf6+ [ 7-] refu 8: gxf8=B Qxf6+ [ 7-] refu 9: cxd7 Qxf6+ [ 7-] refu 10: bxc8=N Qxf6+ [ 7-] refu 11: bxc8=B Qxf6+ [ 7-] refu 12: Nxe7 Qxf6+ [ 7-] refu 13: Nxf8 Qxf6+ [ 7-] refu 14: Nf4 Qxf6# [ 63-] refu 15: Nh4 Qxf6+ [ 7-] refu 16: Na4 Qxf6+ [ 7-] refu 17: Nxc8 Qxf6+ [ 7-] refu 18: Nc4 Qxf6+ [ 7-] refu 19: Nxd7 Nf3+ [ 7-] refu 20: Bxf7 Nf3+ [ 7-] refu 21: Bxf5 Qxf6+ [ 7-] refu 22: Bxd7 Qxf6+ [ 7-] refu 23: Rxg8 Qxf6+ [ 7-] refu 24: Rxb8 Qxf6+ [ 7-] refu 25: Qxh6 Qxf6+ [ 7-] refu 26: Qxg8 Qxf6+ [ 7-] refu 27: Qxc5 Qxe6+ [ 7-] refu 28: Qd4 Qxe6+ [ 7-] refu 29: Qd3 Qxe6+ [ 7-] refu 30: Qd2 Qxe6+ [ 7-] refu 31: Qd1 Qxe6+ [ 7-] refu 32: Qc4 Qxd6+ [ 63-] refu 33: Qb3 Qxd6+ [ 63-] refu 34: Qa2 Qxd6+ [ 63-] refu 35: Qe4 Qxe6+ [ 7-] refu 36: Qf3 Qxe6+ [ 63-] refu 37: Qg2 Qxe6+ [ 7-] refu 38: Qh1 Qxe6+ [ 63-] refu 39: Qxa6 Qxf6+ [ 7-] refu 40: Qxb8 Qxf6+ [ 7-] refu 41: Kxf5 Qxf6+ [ 7-] refu 42: Kf4 Bxd6+ [ 7-] Move counts and EBFs from top down (indexed by depth to go): mvx 8: 37 38 [37.000 1.027] 4 mvx 7: 147 151 [ 3.868 1.027] 15 mvx 6: 685 703 [ 4.536 1.026] 53 mvx 5: 3362 3409 [ 4.782 1.014] 241 mvx 4: 14940 15275 [ 4.383 1.022] 716 3 mvx 3: 69781 71058 [ 4.568 1.018] mvx 2: 254941 22806 [ 3.588 0.089] mvx 1: 24154 0 [ 1.059 ] Black's EBF is only slightly greater than 1, i.e. the selected defense moves were mainly successful. White's EBF is consistently smaller than 5, indicationg that black's defense moves not only are successful, but also restrict white's set of legal moves quite nicely, most probably by checks. Also, blacks EBF inside the mate-in-2 is below 0.1, indicating quite efficient "answer heuristics" especially for that level. Finally, white's EBF for the mate-in-1 is unusually large (1.059). Of these nearly 13% really are mate moves. I'm not sure whether Chest here is doing well or not. Statistics for "normal" move generator calls (not for mate move search): mg 90247 W; inchk: 4616 none 85451 one 180 double mg 259688 B; inchk: 217411 none 41468 one 809 double As already suspected, white is in check most of the time (94.9%), while black is in check only 16.3%. Otherwise I did not note anything unusual in Chest's statistics. Name the missing info and I will try to provide it :-) Cheers, Heiner
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.