Author: Tord Romstad
Date: 04:00:46 04/20/04
Go up one level in this thread
On April 20, 2004 at 05:06:17, José Carlos wrote: >On April 20, 2004 at 04:50:19, Tord Romstad 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 >> >>This is far too restrictive. Be careful about allowing null move pruning in >>pawn endgames and endgames where one side has only the king left, but in more >>complicated endgames the speed gain more than outweighs the risk of >>occasionally overlooking a zugzwang. >> >>>2. it's not a PV node >> >>Have you tried removing this condition? > > I had this condition in Averno for a long time. Once, I was thinking about >some search instability and I came to the conclusion that it was a mistake, >because I was doing threat extensions (when null move returns a mate score >against me I extend), so I failed high in a non PV variation, then I tried an >open window and failed low because I was missing that necessary extension to >justify the fail high. > So definetely, yes: try null move in the PV. > >>>3. it didn't just make a null move >> >>This just complicates the search for no good reason, I think. Many people >>avoid more than one null move in a row, but I don't unerstand why. I've >>never seen any bad effect of allowing successive null moves. > > Do you mean recursive null move (which is fine) or actually doing several null >moves in a row without a 'real' move in between. If the later, I don't >understand it, because you would be dropping to qsearch at any search depth. (?) I mean doing several null moves in a row without any 'real' moves between. In a certain sense you are right that the search will drop to qsearch immediately, but half of all the successive null moves will fail low. It is easy to see that it is logically impossible for two successive null moves to both fail high. >>>4. it's not in check and wasn't in check on the previous ply >> >>The "check on the previous ply" condition should almost certainly be >>dropped. >> >>>5. the remaining depth isn't so small that the reduced depth would take it into >>>the qsearch >> >>This is also a bad idea, I'm afraid. It would render you null move search >>much less effective. I know that some people (Bob, for instance) uses a >>lower null move reduction factor when the remaining depth is small, but >>I don't know any nullmovers who disable null moves entirely in this case. >> >>But you do not mention the most important condition of all: Only do null >>move in nodes where you have a good reason to believe that you will fail >>high! If the static eval is far below beta, doing a null move search is >>almost certainly a waste of time. >> >>As a start, I think the following two conditions should be sufficient: >> >>1. Don't make a null move if the side to move is in check (or is threatened >> by a mate in 1, if you have an easy way to detect this). >> >>2. Don't make a null move if the static eval is far below beta. >> >>Tord > > I tried this and the tree went bigger. The reason is that, many times, you >have a threat against the opponet so that, even if you're below in material and >he moves twice, he fails low. I changed it to "if opponent king safety is ok, >and no opponent pieces are attacked by my pieces and my eval is clearly below >beta then don't try null move". Interesting. Intuitively I would expect this to happen so rarely that it didn't have any importance, but perhaps I should try something like this myself. Tord
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.