Author: Heiner Marxen
Date: 08:45:03 11/16/01
Go up one level in this thread
On November 16, 2001 at 07:55:30, leonid wrote: >On November 15, 2001 at 20:23:02, Heiner Marxen wrote: > >>On November 15, 2001 at 12:05:46, Paul wrote: >> >>>On November 15, 2001 at 11:45:39, leonid wrote: >>> >>>>On November 15, 2001 at 09:44:55, Paul wrote: >>>> >>>>>On November 15, 2001 at 09:09:08, leonid wrote: >>>>> >>>>>>[D]2nkN3/2nqN3/2rrbb2/RBqQQqQQ/RBqNPqPQ/2qpqp2/3B4/3K4 w - - >>>>>> >>>>>>Please indicate your result. >>>>>> >>>>>>Thanks, >>>>>>Leonid. >>>>> >>>>>Hi Leonid, >>>> >>>>Hi! >>>> >>>>>Haha! .. that was a surprise when I saw what Pretz came up with: >>>>> >>>>>1. Nexc6+ Qcxc6 2. Qgxf6+ Qxf6 3. Qexf6+ Qxf6 4. Qxf6+ Qe7 5. Qxe7+ Nxe7 6. >>>>>Nxe6+ Nxe6 7. Ra8+ Nc8 8. Rxc8+ Kxc8 9. Nxd6+ Kd8 10. Ra8+ Qxa8 11. Qxa8+ Qc8 >>>>>12. Qe8+ Kc7 13. Qexc8+ Kb6 14. Qa5# >>>>> >>>>>So a mate in 14! I think I must have a bug ... >>>> >>>>I don't think so. It is mate in 13. Verified it 12 moves deep by brute force to >>>>be sure. Easy branching factor. Found mate in 13 by selective. Your, probably, >>>>went just one move deper to find its mate. Good result. >>> >>>Just after I posted my message mine also found a mate in 13 ... I was just too >>>quick, but I had to laugh out loud because I know you don't post mates over 13 >>>moves deep! I thought maybe you had changed your solver. >>> >>>>I see that you have almost no competition here. Your selective look like to be >>>>very effective. I still hope that somebody will come with Chess Master solution >>>>to see better your and mine position. >>>> >>>>What was your time here? >>> >>>07:28 WM13 13 Nexc6+ Qcxc6 Qgxf6+ Qxf6 Qexf6+ Qxf6 Qxf6+ Ne7 Ra8+ Nxa8 Rxa8+ >>>Qxa8 Qxa8+ Qcc8 Ba5+ Qcc7 Bxc7+ Qxc7 Nxe6+ Rxe6 Qhd5+ Rd6 Qfxd6+ Qxd6 Qxd6# >>> >>>So no bug, mine just took the long way home first ... >> >>Hi, >> >>Chest confirms the above: #13 with a unique key move: >> >>PV: Nexc6+ Qcxc6 Qgxf6+ Qxf6 Qhxf6+ Qxf6 Qxf6+ Qe7 Qxe7+ Nxe7 Nxe6+ Nxe6 Ra8+ >>Nc8 Rxc8+ Kxc8 Nxd6+ Kd8 Nxc4+ Qxd5 Qxd5+ Kc8 Ba6+ Kb8 Qb7# >> >>(K7/600, 30MB hash, 57.2 minutes) >># 1 0.00s 0kN 0.87 1- 0 >># 2 0.00s 0kN 1.00 1- 0 >># 3 0.01s 0kN [ 7.42] 0.92 63- 0 >># 4 0.03s [ 3.00] 2kN [ 3.71] 1.12 190- 0 >># 5 0.09s [ 3.00] 6kN [ 3.29] 1.53 348- 0 >># 6 0.25s [ 2.78] 18kN [ 3.12] 2.03 861- 0 >># 7 0.83s [ 3.32] 63kN [ 3.43] 2.51 2897- 0 >># 8 1.98s [ 2.39] 155kN [ 2.46] 3.12 6827- 0 >># 9 6.11s [ 3.09] 489kN [ 3.17] 3.69 22121- 0 >># 10 23.47s [ 3.84] 1850kN [ 3.78] 3.87 100289- 1 >># 11 112.24s [ 4.78] 8475kN [ 4.58] 4.60 516316- 6868 >># 12 501.96s [ 4.47] 31935kN [ 3.77] 4.53 3036282- 2249851 >># 13 3434.74s [ 6.84] 208426kN [ 6.53] 4.69 20984850- 20198419 >> >>>>Mine by brute force took 1 hour and 50 min for 12 moves to say "No". Selective >>>>in 13, took 9 seconds. >>> >>>That's pretty fast ... :) >> >>... but not yet optimal :-)) > >Hi, Heiner! > >It was very interesting for me in this position see your and mine program do >work without hash on the same computer. Everything went actually in almost twin >brothers indentical way. That is in fact quite interesting! Note also, that completely without hash Chest does some not so clever things. Especially when the EBF is small, the compeletely recursive iterative deepening at all levels can be bad. In this case it may not hurt so much, but last time I tried completely without hash I was somewhat disappointed. But then... hash is in there for a long time now, and even with very low memory a small hash does help a lot. So I decided not to change the program just for the case that we work without hash. That is more of a debugging help than a real feature. > Your had only advantage in branching factor just after >9 move. When mine was already 11.6 between 11 and 12 move, your was still very >stable and around 5. And just after that point your NPS seems to jump up by a factor around 2. Indicating more searching, and less "whatever else the program does". > Time for 12 moves was practially the same considering 12 >move depth. Mine 1 hour and 49 min and your 3h 54 min. Considering that my >program is done on Assembler your went just slightly better that mine. Yeah, sure. Even in C I still could do a lot of micro optimization, e.g. to speed up the execution of moves. Since you are even assembler, a better basic speed at your side is logical and expected. [Since Chest still is "experimental" I do not do much micro-optimization, since that tends to fix the design, and I like it to be flexible.] That Chest even without hash can do better is due to the non-trivial features based on its attack information, where Chest tries to replace search by other arguments. Well, that is a guess, of course. The increased EBF deeper in the tree normally is due to "better chances" to mate, i.e. more check moves around etc. Chest is quite good in detecting when there _really_ are mates around, or, to be exact, when they not really are there, and still avoiding search in the last plies. >My time was: > >Depth in moves Time Branching factor. NPS > >4 moves 0,05 sec > 2 >5 moves 0.10 sec 44k > 2.8 >6 moves 0.27 sec 39k > 2.8 >7 moves 0.769 sec 42k > 2.64 >8 moves 2.03 sec 57k > 4.16 >9 moves 8.46 sec 74k > 6.4 >10 moves 54.78 sec 101k > 10.5 >11 moves 9 min 27 sec 116k > 11.6 >12 moves 1 h 49 min 32 sec 118k Now, if you could say, what makes the EBF deeper in the tree so large, while it is small near the root... you may find an idea how to speed up. Also, according to this data, your program, extended by a hash, may be a real contender to Chest, if not even faster... huh, did I really say that? :-)) CU, 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.