Author: Ross Boyd
Date: 16:40:30 09/30/04
Go up one level in this thread
On September 30, 2004 at 15:54:57, Stuart Cracraft wrote: >On September 30, 2004 at 11:49:23, Ross Boyd wrote: > >>On September 30, 2004 at 02:54:32, Stuart Cracraft wrote: >> >>>On September 30, 2004 at 00:51:07, Ross Boyd wrote: >>> >>>>On September 29, 2004 at 23:52:15, Stuart Cracraft wrote: >>>> >>>>>[D] 4r1k1/p1qr1p2/2pb1Bp1/1p5p/3P1n1R/1B3P2/PP3PK1/2Q4R w - - bm Qxf4; >>>>> >>>>>In this position I had everything turned on and got the solution >>>>>in a little more than 1 1/2 minutes: >>>>> >>>>> 1/11 g2f1 0.01 -953 945 g2f1 f4d5 >>>>> g2f1 f4d5 >>>>> 2/12 g2f1 0.01 -953 1644 >>>>> g2f1 f4d5 c1g5 >>>>> 3/12 g2f1 0.02 -953 5064 >>>>> g2f1 f4d5 c1g5 d5f6 >>>>> 4/20 g2f1 0.09 -953 20655 >>>>> g2f1 f4d5 b3d5 c6d5 c1c7 d6c7 f1g1 >>>>> 5/22 g2f1 0.65 -953 168943 >>>>> g2f1 b5b4 b3a4 f4d5 f6g5 d5e7 >>>>> 6/26 g2f1 2.59 -953 620310 >>>>> g2f1 b5b4 mtmt >>>>> 7/32> g2f1 60.58 -552 14192153 g2f1 e8c8 c1b1 f4d5 b1e4 d6b4 f6e5 c7b6 >>>>> g2f1 e8c8 c1b1 f4d5 b1e4 d6b4 >>>>> 7/34 c1f4 99.42 5113 24537823 c1f4 e8e6 f4g5 d7e7 b3e6 e7e6 h1d1 d6e7 f6e7 >>>>> c1f4 e8e6 f4g5 d7e7 b3e6 e7e6 h1d1 >>>>> >>>>> >>>>>I turned off null move (R=2) and got the solution in about 11 seconds: >>>>> >>>>>Alpha=-1332 Beta=-531 Maxdepth=9999999 MaxTime=99999999 >>>>> 1/11 g2f1 0.01 -953 908 g2f1 f4d5 >>>>> g2f1 f4d5 >>>>> 2/12 g2f1 0.01 -953 1565 >>>>> g2f1 f4d5 c1g5 >>>>> 3/14 g2f1 0.07 -953 20084 >>>>> g2f1 f4d5 c1g5 d5f6 >>>>> 4/22 g2f1 0.60 -953 131543 >>>>> g2f1 f4d5 b3d5 c6d5 c1c7 d6c7 f1g1 >>>>> 5/26>g2f1 6.80 -552 1607444 >>>>> g2f1 b5b4 b3a4 f4d5 f6g5 d5e7 >>>>> 5/36 c1f4 10.70 2260 2466497 c1f4 d6f4 h4h5 g6h5 h1h5 f4h6 h5h6 c7g3 g2g3 d7d6 >>>>> >>>>> c1f4 d6f4 h4h5 g6h5 h1h5 f4h6 h5h6 c7g3 g2g3 d7d >>>>> >>>>>So now my question is, would it make sense to consider an idea of >>>>>disabling null move under additional circumstances if those >>>>>circumstances can be identified. >>>>> >>>>> endgame >>>>> side to move in check >>>>> inside principal variation >>>>> last move a null move >>>>> >>>>>These are the ones I disable for -- I don't disable null move for >>>>>any material-related or alpha/beta related measures but perhaps >>>>>I should. Are any in common use? >>>>> >>>>>Stuart >>>> >>>>Hi Stuart, >>>>I'll dodge your question and cut to the chase. >>>> >>>>You are seeing in action the weakness of nullmove when paired with a dumb >>>>qsearch. MATE THREAT extensions help to a certain extent, HOWEVER, to solve >>>>WAC141 instantly you can generate 'quiet' checks in first ply of qsearch. (That >>>>is, if your capture search has not produced a beta cut, you then try generating >>>>non-capture checks and search them as well). >>>> >>>>This will extend the false horizons created by recursive nullmove and it >>>>complements the MATE THREAT extension very nicely. Note, the tree doesn't >>>>explode because you only do it when all the captures failed.. and then only at >>>>1st ply of qsearch.... so the overhead is not too bad. >>>> >>>>TRACE now solves WAC141 on a P3-450 in half a second. I can tell you that before >>>>implementing those quiet checks at ply 1 of qsearch it took over 3 minutes to >>>>solve it. >>>> >>>>YMMV... well actually, barring bugs - it's guaranteed to solve your problem. >>>> >>>>Ross >>> >>>What has the above done to your program's other results on test suites >>>and against components, all the same ones you faced before the change. >>> >>>Stuart >> >>Overall, it has improved TRACE's OTB play by ~70 ELO. On test suites it sees >>tactics involving checks/mates much faster. Another WAC problem that benefits >>greatly from qsearch checks is #163... >> >>[D] 5rk1/2p4p/2p4r/3P4/4p1b1/1Q2NqPp/PP3P1K/R4R2 b - - bm Qg2+; >> >>TRACE 1.30 on a PIII-600: >> 3 00:00 4.753 158.433 -0.20 c6d5 >> 3 00:00 5.280 132.000 -0.62 c6d5 b3d5 g4e6 d5e5 >> 3 00:00 5.280 132.000 -0.62 c6d5 b3d5 g4e6 d5e5 >> 3 00:00 7.305 121.750 -0.61 f3g2 >> 3 00:00 8.241 117.728 -0.14 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>c6d5 >> 3 00:00 8.241 117.728 -0.14 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>c6d5 >> 4 00:00 9.822 122.775 -0.34 f3g2 >> 4 00:00 12.015 109.227 -0.40 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>c6d5 a2a4 >> 4 00:00 12.015 109.227 -0.40 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>c6d5 a2a4 >> 5 00:00 17.556 117.040 -0.20 f3g2 >> 5 00:00 23.535 130.750 -0.03 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>c6d5 f1c1 c7c6 >> 6 00:00 41.398 159.223 -0.23 f3g2 >> 6 00:00 58.923 143.714 -0.30 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>c6d5 a2a4 c7c5 a4a5 >> 6 00:00 58.923 143.714 -0.30 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>c6d5 a2a4 c7c5 a4a5 >> 7 00:00 102.455 146.364 -0.10 f3g2 >> 7 00:01 138.531 164.917 +0.07 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>c6d5 f1e1 h6d6 e1e7 c7c5 >> 8 00:01 235.578 169.480 +0.27 f3g2 >> 8 00:01 265.048 173.233 +2.27 f3g2 >> 8 00:02 349.987 176.761 +M10 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>f8f5 f1e1 f5h5 e1e8 g8f7 e8e7 f7e7 a1e1 e7d8 e1e8 >> 9 00:02 484.263 190.654 +M10 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>f8f5 f1e1 f5h5 e1e8 g8f7 e8e7 f7e7 a1e1 e7d8 e1e8 d8e8 d5c6 >> 10 00:04 860.458 192.496 +M10 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>f8f5 f1e1 f5h5 e1e8 g8f7 e8e7 f7e7 a1e1 e7d8 e1e8 d8e8 d5c6 >> 11 00:09 2.060.677 223.258 +M10 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>f8f5 f1e1 f5h5 e1e8 g8f7 e8e7 f7e7 a1e1 e7d8 e1e8 d8e8 d5c6 >> 12 00:22 5.669.700 249.217 +M10 f3g2 e3g2 h3g2 h2g2 g4f3 b3f3 e4f3 g2g1 >>f8f5 f1e1 f5h5 >> >> >>Hope this helps, >> >>Ross > >Very much so -- this is key information -- the key point is to do >the normal capture and check-evasion search first. > >Only after it is all done and without the cut, then generate >non-capture checks and do those. Exactly. You still do your check evasions ad-infinitum but generating/searching non-captures that GIVE check is only attempted at ply 1 of qs. BTW, I'd suggest toning down your recapture extensions somewhat. I don't allow recap extensions unless they occur in the last 3 ply of the main search. The point is there is no point in extending recaps at shallow depths because the tree simply explodes. You may have been using over-aggressive recap extensions to 'compensate' for the lack of other key extensions. > >Great stuff -- can hardly wait to try it. Do I dare implement it >at work during the day? Heh, heh. > >Stuart Or do you dare implementing it at home during the night? Its a double-edged sword isn't it. :-) Chess programmers must have a mortgage on insomnia (as well as insanity). Good luck with it, Ross
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.