Author: Stuart Cracraft
Date: 23:54:32 09/29/04
Go up one level in this thread
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
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.