Author: Heiner Marxen
Date: 19:43:24 10/05/01
Go up one level in this thread
On October 05, 2001 at 15:40:17, Paul wrote: >On October 05, 2001 at 05:52:47, Tim Foden wrote: > >>On October 04, 2001 at 10:46:10, leonid wrote: >> >>>On October 04, 2001 at 08:58:20, Paul wrote: >>> >>>>On October 04, 2001 at 06:31:46, leonid wrote: >>>> >>>>>[D]k2rQN2/b2bP1R1/r2pQ2K/qqqqQ2B/n2nQ2Q/q2qP1R1/p2pNB2/8 w - - >>>>> >>>>>Please indicate your result. >>>>> >>>>>Thanks, >>>>>Leonid. >>>> >>>>Hi Leonid! >>> >>>Hi, Paul! >>> >>>>I guess this problem was composed especially for Heiner's harddisk, but this is >>>>what Pretz found on my p3/1000: >>>> >>>>00:24 WM11 08 exd8=Q+ Qxd8 Qhxd8+ Bb8 Q6xd5+ Rc6 Qxb8+ Qxb8 Qxb8+ Kxb8 Nxd7+ Kc7 >>>>Nxc5+ Kb6 Nd7+ Kc7 Nb6+ Kb8 Qe8+ Rc8 Qxc8# >>>> >>>>So a mate in 11 in 24 seconds. >>> >>>We found with you mate at same depth, 11 moves. Had no chance to expect to reach >>>solution by brute force, since 7 moves took already 1 hours and 3 min. I >>>actually expected that you will use Heiner solver to find shorter solution for >>>this position. >>> >>>Your program give all the time great result. We are almost identical. Mine took >>>in 18 seconds. >> >>Hi. I thought I'd give GLC a go at this. It confirms a mate in 11 after 60 >>seconds. I left it running though, and it has now found a mate in 10 (3 mins 10 >>secs). >> >> 7 36.96 +30.911 21919k exd8=R+ Qxd8 2. Qhxd8+ Bb8 3. Qxb8+ Qxb8 4. Q4xd5+ >> Rc6 5. Qxb8+ Kxb8 6. Nxd7+ Ka7 7. Nxc5+ Kb6 8. >> Rb7+ Ka5 9. Nxd3+ Rc5 10. Ra7+ Kb6 >> 8 37.69 ++ 22262k exd8=R+ (a=30.51 b=31.31 e=31.31) >> 8 59.70 +Mate11 39767k exd8=R+ Qxd8 2. Qhxd8+ Bb8 3. Qxb8+ Qxb8 4. Q4xd5+ >> Rc6 5. Qxb8+ Kxb8 6. Nxd7+ Ka7 7. Nxc5+ Kb6 8. >> Nd7+ Kb7 9. Nb6+ Kb8 10. Qc8+ Rxc8 11. Qb7# >> 8 1:23 +Mate11 59298k exd8=R+ Qxd8 2. Qhxd8+ Bb8 3. Qxb8+ Qxb8 4. Q4xd5+ >> Rc6 5. Qxb8+ Kxb8 6. Nxd7+ Ka7 7. Nxc5+ Kb6 8. >> Nd7+ Kb7 9. Nb6+ Kb8 10. Qc8+ Rxc8 11. Qb7# >> 9 3:06 +Mate10 147706k exd8=R+ Qxd8 2. Qhxd8+ Bb8 3. Qxb8+ Qxb8 4. Q5xd5+ >> Qc6 5. Qxb8+ Kxb8 6. Qe8+ Bc8 7. Qxc8+ Kxc8 8. >> Qe8+ Qxe8 9. Qb7+ Kd8 10. Qc7# >> 9 4:51 +Mate10 243875k exd8=R+ Qxd8 2. Qhxd8+ Bb8 3. Qxb8+ Qxb8 4. Q5xd5+ >> Qc6 5. Qxb8+ Kxb8 6. Qe8+ Bc8 7. Qxc8+ Kxc8 8. >> Qe8+ Qxe8 9. Qb7+ Kd8 10. Qc7# >> >>Cheers, Tim. > >Great find, Tim! Haven't tried it with Pretz yet, because I've been pretty busy >analysing with Chest, this is what it said when I tried to find a mate in 9: > >"chestimmx -Z9 -M350 -b -s t.txt" Hi Paul, Since you mentioned in another post, that you do not know how to read the Chest statistics output below, I will explain most of it... ># 9 22318.51 2.29 213018597-203843560 That is a 1-line statistics summary per depth. After the depth we see the time in seconds, the speed factor from the hash table, the number of hash table entries filled with data, and how many hash table entries were overwritten (hash in and out). The next release will also show EBF data here. >mvx 9: 74 80 [74.000 1.081] mvskip lvskip >mvx 8: 1032 1045 [12.900 1.013] 31 >mvx 7: 15336 14930 [14.676 0.974] 256 1 >mvx 6: 226455 228271 [15.168 1.008] 4195 27 >mvx 5: 2771823 2799132 [12.143 1.010] 171609 509 >mvx 4: 26848870 27963199 [ 9.592 1.042]1020996 6525 >mvx 3: 244880583 232945419 [ 8.757 0.951] >mvx 2: 965864389 246715967 [ 4.146 0.255] >mvx 1: 84923066 0 [ 0.344 ] Move execution statistics for the depth to go, for attacker and defender. In [] are shown the quotients, which are also some kind of EBF. You can see that the attacker does multiple moves, while the depender mostly does just one move. mvskip & lvskip tell skipped attacker moves and complete levels of the iterative deepening due to subjobs returning more depth than asked for. This tells about the size of the search tree. We see that the attacker is in check most of the time (numbers much smaller than 74), and shrinking down the tree due to captures. In mate-in-2 the number is cut in half due to "m2" (see below), and the defender does only 25%, due to FAC (below). Mate-in-1 moves are rare, since the special move generator for them is so effective. >mate2: 207561148, 2164389487 cand [10.4], 965864389 mvx [44.6%] How many mate-in-2 were asked for, how many attacker moves showed up, [avg. #moves per call] and how many attacker moves were really executed. >anti: 82071915, lists 8335439 [10.16%], moves 16765434 [20.43%], succ 3055275 >[3.72%] How often the defender tried to mate (!) the attacker in 1 move, how many move lists for this showed up non-empty, how many moves were in there, and how often the defender really mated the attacker [success rate]. >subdep lists steps lsum lists+ steps+ lsum+ > 8 74 4871 4871 0 0 0 > 7 1031 70343 70596 7 35 288 > 6 15296 1021338 1091986 1018 4246 74894 > 5 223197 11000790 16516864 30963 102542 2237638 > 4 2711485 28379145 204120661 353419 618568 26005401 > 3 24764509 89912061 1853701209 3196879 3798017 231311892 > 2 137842499 253700275 1221676339 23182162 24379601 1659270408 > 1 359866 0 14092077 0 0 0 > tot 165917957 384088823 3311274603 26764448 28903009 1918900521 This tells about "snooping" (ETC, enhanced transposition cutoffs). Basically, for some of the defender moves Chest tries to find the resulting position in the hash table (TT, transposition table), without actually executing the move. If found with enough depth, we can stop searching a tree for the presumed best defender move, since we know a good enough defender move. >m1: 246715967, 10270756 succ [ 4.2%] Mates in one to be done, and success rate. Since the success rate is so low, this must be one of Leonid's creatures. :-) Normally most of the mate-in-1 candidates really are mates. The following data is about the "m2" heuristic, which tries to recognize attacker moves (candidates) for a mate-in-2 as hopeless, by estimating the attacks around the defender king which is expected to do a fixed move after the candidate. This is really complicated. >m2 fail: 0 prom, 0 castle, 17803358 noesc >m2e: avg 4.02, cnt = 204853227 > 0+ 17803358 8.7%: 17803358 - - - = 8.7 - - - > 1+ 14479360 7.1%: 4216945 1443868 - 8818547 = 2.1 0.7 - 4.3 > 2+ 23791550 11.6%: 5616255 1149716 9481824 7543755 = 2.7 0.6 4.6 3.7 > 3+ 21047016 10.3%: 3836252 5963704 6763058 4484002 = 1.9 2.9 3.3 2.2 > 4+ 43653119 21.3%: 10436708 11949029 9001214 12266168 = 5.1 5.8 4.4 6.0 > 5+ 56573787 27.6%: 17395895 10784602 13150754 15242536 = 8.5 5.3 6.4 7.4 > 6+ 23804858 11.6%: 8760620 5776422 5528548 3739268 = 4.3 2.8 2.7 1.8 > 7+ 3425729 1.7%: 2281302 493867 378319 272241 = 1.1 0.2 0.2 0.1 > 8+ 271479 0.1%: 252337 6893 10175 2074 = 0.1 0.0 0.0 0.0 > 9+ 2971 0.0%: 2971 - - - = 0.0 - - - m2e = escapes fo the defender K in "m2" analysis. The central field of the 3x3 area is also counted. >m2c: 17803358 dunno, 0 ep, 37427074 illf, 86478086 illt [ 6.2%] >m2c: 146128 from, 1815871 beat, 61131112 move, 227391 frst >m2c: 12924178 othr, 11325580 thru, 114363573 rest, 1056890495 succ [75.5%] Several reasons why "m2" cannot recognize a candidate to be hopeless, and the rate of the hopeless ones. It is a bit too optimistic (some cases not accounted for correctly). >m2ll 0 t/m: 335675799 460747419 [ 16.2% 22.2%] >m2ll 1 t/m: 163018057 492623168 [ 7.8% 23.7%] >m2ll 2 t/m: 56574220 254910899 [ 2.7% 12.3%] >m2ll 3 t/m: 21789528 86250517 [ 1.0% 4.2%] >m2ll 4 t/m: 7575709 81082491 [ 0.4% 3.9%] >m2ll 5 t/m: 3186808 46813632 [ 0.2% 2.3%] >m2ll 6 t/m: 998163 28110296 [ 0.0% 1.4%] >m2ll 7 t/m: 279220 18840450 [ 0.0% 0.9%] >m2ll 8 t/m: 74356 10406346 [ 0.0% 0.5%] >m2ll 9 t/m: 18249 4605594 [ 0.0% 0.2%] >m2ll 10 t/m: 3168 1971909 [ 0.0% 0.1%] >m2ll 11 t/m: 1005 1007432 [ 0.0% 0.0%] >m2ll 12 t/m: 54 286969 [ 0.0% 0.0%] >m2ll 13 t/m: 5 111037 [ 0.0% 0.0%] >m2ll 14 t/m: - 34603 [ 0.0% 0.0%] >m2ll 15 t/m: - 8933 [ 0.0% 0.0%] >m2ll 16 t/m: - 2996 [ 0.0% 0.0%] >m2ll 17 t/m: - 917 [ 0.0% 0.0%] >m2ll 18 t/m: - 244 [ 0.0% 0.0%] >m2ll 19 t/m: - 100 [ 0.0% 0.0%] >m2ll 20 t/m: - 37 [ 0.0% 0.0%] >m2ll 21 t/m: - 1 [ 0.0% 0.0%] >acm statistics: ACM = adaptive chess memory = TT, the hash table >247186644/384088823 searched Normal hash table searches, and "snooping" searches. >34168047/48752815 found (13.8/12.7), 86904680 compared [1.048/found] Search success rate (regardless of found depth), and how often a complete 32 byte large compact board was compared since the hash code matched. >213018597/203843560 in/out 9175037 alive, 0 free Hash table entries filled, overwritten, currently valid, still unused. >apx costs: done 4406380032, saved 5680208896 (1.289), ovhd 16777216, speed 2.29 Chest estimates the computation time by counting move executions, move generator calls and some other functions. That number is called approximate "cost". Here we have the really executed cost, how much is estimated that the TT did save, the quotient saved/done, the overhead cost needed for maintaining the TT, and how much faster we were with TT over no TT (estimated). >cost done per sec = 197431.6 That one is easy :-) The info in a hash table entry contains a success bit and a depth (e.g. mate-in-5 is not possible = 5 and FALSE). Below we see what kind of info has been invented, used (after search hit), upgraded (replaced by even stronger info), and forgot (overwritten). >info made- used- upgr- forg- made+ used+ forg+ > 1 211931212 0 211931212 0 1087385 128353 1080983 > 2 206502848 54214700 23220792 177736430 1058300 177774 1029956 > 3 22827330 5911112 2410112 18681488 128942 29042 119065 > 4 2395911 641195 194868 1854100 18200 3513 15874 > 5 195673 46762 14562 146131 1611 297 1418 > 6 14570 2203 1111 10667 135 20 125 > 7 1104 16 80 796 13 3 13 > 8 76 0 1 54 4 0 4 > 9 1 0 0 0 0 0 0 > 63 4628020 0 0 3166456 0 0 0 Below we also see total and average cost for the various info types. >info cnt- cost- avg- cnt+ cost+ avg+ > 1 211931212 107078016 0.5 1087385 6167337 5.7 > 2 206502848 2834296320 13.7 1058300 22694652 21.4 > 3 22827330 4064055552 178.0 128942 48874104 379.0 > 4 2395911 4281031424 1786.8 18200 62553824 3437.0 > 5 195673 4333862912 22148.5 1611 54809952 34022.3 > 6 14570 4350008832 298559.3 135 51647520 382574.2 > 7 1104 4351575552 3941644.5 13 53287584 4099045.0 > 8 76 4357762048 57338976.0 4 48471648 12117912.0 > 9 1 4406348800 4406348800.0 0 0 0.0 > 63 4628020 20441408 4.4 0 0 0.0 >end of acm statistics. >mg 245675240 W; inchk: 22722249 none 222607192 one 345799 double >mg 988733411 B; inchk: 805157858 none 182548907 one 1026646 double Move generator calls for white to move and black to move. How often the side to move is in check: not at all / once / twice. >m1gW 459734307, empty 1933619, expl 710406034/6355439, impl 729497731/40390333 >m1gB 82072172, empty 1078685, expl 255275834/2789003, impl 203546099/10212381 Above are calls to the special mate move generator (moves that cannot possibly be mate moves are left out). How often the move list came out empty, how often a piece had a precomputed (explicit) list of candidates / how many moves were generated that way. >fac : 632467110 calls, 632451664 scans, 825126652 ck, 394963599 success (62.4%) FAC = fatal anti check, the defender heuristic which tries to find a checking move as answer to a 2-mate candidate, which in turn cannot be followed by a mate move. >fact : 455329525 calls, 423177552 candidates, 333397279 success (73.2%) There is a one element cache for FAC moves (kind of killer move), which is tested (FACT = FAC test) before searching for FAC. >fackm: 207561148 calls, 186009290 inchk, 168594470 scans, 75163135 dirs > 62459875 used [0.30] This is a special version of FAC for king moves of the attacker. Hopefully you can now enjoy these statistics much better :-) There are some more statistics which did not show up this time. If you see something you want to know about, just ask me. Cheers, Heiner >That means that it didn't find one in more than 6 hours of analysis, and >considering the branching factor, time went something like 12-120-1200-22318, I >won't go hunting for a mate in 10 with Chest. :) > >Groetjes, >Paul
This page took 0 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.