Author: Ed Schröder
Date: 10:45:05 04/28/04
Go up one level in this thread
On April 28, 2004 at 01:29:30, Gerd Isenberg wrote: >On April 28, 2004 at 01:11:23, Gerd Isenberg wrote: > >>On April 27, 2004 at 21:54:49, Uri Blass wrote: >> >>>On April 27, 2004 at 21:00:22, Vincent Diepeveen wrote: >>> >>>>On April 27, 2004 at 11:43:36, José Carlos wrote: >>>> >>>>>On April 27, 2004 at 08:37:34, Tony Werten wrote: >>>>> >>>>>>On April 27, 2004 at 03:33:26, Bas Hamstra wrote: >>>>>> >>>>>>>About double nullmove: I tested this in some pawnendgames to see if it could >>>>>>>handle zuzwang problems, but I don't see it perform any better than normal >>>>>>>nullmove. Can Vincent or you post a position where double null outperforms >>>>>>>normal null? I agree the idea is elegant, but I just don't see it work. >>>>>> >>>>>>I switch it off in pawns only endgames. Couldn't figure out why it wasn't doing >>>>>>as well as it sounded. >>>>> >>>>> I can't think about it now, but I recall this thread where an interesting >>>>>discussion about double null move came up: >>>>> >>>>>http://chessprogramming.org/cccsearch/ccc.php?art_id=241476 >>>>> >>>>> José C. >>>> >>>>Christophe wrote that down just to let you guys believe you should search >>>>fullwidth. >>>> >>>>Practical chances of it happening is small, not zero but very close to it. >>>>Additionally you can add a single 'if then else' condition in transposition >>>>table cutoff to avoid the theoretical scenario that christophe describes. >>>> >>>>Look the alternative to double nullmove is doing something dead slow like what >>>>Gerd is doing, or what i used to do in my draughtsprogram; a verification >>>>search, which is just a fullwidth search of n-R ply. So not the later posted in >>>>ICGA verification search. Verification search already was excisting in other >>>>publications than in the ICGA. So Omid just stole the name kind of for something >>>>working crappy :) >>> >>>No >>> >>>Omid did not steal the idea. >>> >>>You simply did not understand Omid's ideas. >>>Omid's idea is not mainly to detect zugzwangs but to detect tactics earlier. >>> >>>Null move pruning means that there are tactics that you need more plies to see >>>because of the horizon effect when you cannot detect the threat. >>> >>>With verified null move pruning you can see it 1 or 2 plies earlier. >>> >>>Doing checks in the qsearch cannot solve the problem because there is tactics >>>that is not based on checks. >>> >>>> >>>>Basically all those approaches eat shitload of nodes to say it *very* polite. >>> >>>Basically I see no reason that verification search to detect zugzwangs needs to >>>eat many nodes(Omid's idea is not verification search) and common sense tells me >>>that if the depth is reduced enough it does not eat many nodes. >>> >>>Uri > >oups, sorry for the empty reply... > >I tried double nullmove suggested by Vincent too, without any precondition like >eval - margin >= beta. Vincent is probably right - it seems to work great, and >solves a lot of test positions a few percent faster. But with some positions, >specially with fail-high or -low behaviour the solution needs more than the >double time than single nullmove in a row with verification search in my >program. Two examples from BT-test: What is double nullmove? I only know recursive nullmove allowing multiple nullmoves. I also read about "allowing 2 nullmoves in a row". What are the differences? I use recursive nullmove, not allowing the next ply after the nullmove to nullmove. So: e2-e4 e7-e5 **-** // nullmove d7-d5 // do no allow nullmove When I remove that check I get a few percent speedup, results look okay. Ed
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.