Author: martin fierz
Date: 01:52:12 09/30/04
Go up one level in this thread
On September 30, 2004 at 00:46:26, Uri Blass 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 > >It is better to disable your recapture extensions. >The problem here is not null move pruning and null move pruning willnot change >the depth that you solve the problem when you will implement correctly checks in >the qsearch. > >The target of chess programs is not to solve 141 faster but to play better. >I am almost sure that if only the recapture extension save you many plies in 141 >then you implement it in a way that is counter productive for games. > > >I wonder how do you get depth 5 without null move pruning > >Can you post the remaining depth after every move in the line >1.Qxf4 Bxf4 2.Rxh5 gxh5 3.Rxh5 Bh6 4.Rxh6 Rd6 Rh8# > >There are no checks in this line except the mate and you do checks in the >qsearch so without recapture extensions you need at least 9 plies for it(after 8 >plies you enter qsearch after Rd6 and do not find the move Rh8 mate. > >If recapture extensions lead to 4 plies extension then it seems clear that your >new program will be clearly weaker in games. > >I suspect that you extend 4 plies in this line because you extend 1 ply every >time that the last 2 moves are captures. > >It is clearly a bad idea to do it and it is clear that even with more reasonable >restriction of the recapture extension it is not productive for a lot of >programs. > >I suggest that you test the version with the recapture extension in games >against the version without the recapture extension if you do not believe me >that your recapture extension is a bad idea. > > >Uri hi uri, where do you see recapture extensions influencing WAC.141? the main line has no single "recapture" if you define it as "capture of a piece of the same value, on the same square, on two successive plies". i think that is the normal definition of recapture. what am i missing? cheers martin
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.