Author: Vincent Diepeveen
Date: 20:52:59 04/19/04
Go up one level in this thread
On April 19, 2004 at 20:38:47, Mike Siler wrote: >My program tries a null move search if > >1. it's not the endgame drop that condition. just do not do a nullmove when either side is in a pawn endgame. >2. it's not a PV node how do you know this in advance? You mean when beta = infinite ? >3. it didn't just make a null move that's a stupid condition. i consider double nullmove a correct way to search. i would change it in that case to allowing 2 nullmoves in a row is allowed, but the 3d isn't. >4. it's not in check and wasn't in check on the previous ply Though perhaps cool to solve some win at chess tactics 1 ply sooner, so finding it in 1 microsecond instead of 2, i would drop that too in order to search deeper. Do not nullmove when side to move is not in check. >5. the remaining depth isn't so small that the reduced depth would take it into >the qsearch I see no problems with that. In fact this is the biggest profit you get in short term from nullmove! So why not doing a nullmove here? > >In general, only around 65% of the null move searches my program performs result >in a cut-off. Is this normal or do other programs tend to do better (and how)? >According to Ed Schröder's page, Rebel gets around 93-95%. I've tried the >recommendations listed there but they didn't help much. >Michael Rebel is doing also checks in qsearch i assume, so that will make the mainsearch a lot better and improve any % anywhere. I didn't know Rebel nowadays combines dubious forward pruning with nullmove. Is there any mention of that done by Ed?
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.