Author: Vincent Diepeveen
Date: 20:54:16 04/19/04
Go up one level in this thread
On April 19, 2004 at 23:52:59, Vincent Diepeveen wrote: >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. remove the last 'not' there. > >>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.