Author: Tony Werten
Date: 05:36:34 04/20/04
Go up one level in this thread
On April 20, 2004 at 06:47:34, Tord Romstad wrote: >On April 20, 2004 at 06:40:34, Tony Werten wrote: > >>On April 20, 2004 at 06:36:35, Tony Werten 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? >>>> >>>>>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. >>>> >>>>>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. >>> >>>Actually, you can drop 2 as well :) >>> >>>Move ordering is much better if you just nullmove everywhere. That way, you can >>>also throw out IID. > >That's not my experience. Nullmoving everywhere doesn't noticably improve >my move ordering, and it increases the size of the game tree (by around >15-20%, if I recall correctly). Throwing out IID doesn't help. > >Perhaps this depends on how your move ordering works. > >>In addition, throw out the 2nd half of 1 as well. If my opponent is going to >>checkmate me, I want to know so I can extend. > >I don't understand what you say here. In the 2nd half of 1, I suggested to >avoid null move search if you already know (without search) that mate in >1 is threatened. What extra information do you expect to get from a null >move search? The move that will checkmate you. If it's not easily refuted then you want to extend. If it's the same move as 2 plies ago, extend. There are other ways to get this information, but nullmove is an easy one. Tony > >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.