Author: Will Singleton
Date: 22:44:25 02/24/99
Go up one level in this thread
On February 25, 1999 at 01:17:35, Don Dailey wrote: >On February 24, 1999 at 21:52:21, Will Singleton wrote: > >>On February 24, 1999 at 15:53:49, Don Dailey wrote: >> >>>Your statement about not using two null moves in row shouldn't matter. >>>I had this rule in my program and Don Beal asked me, "why?" I took >>>it out and the program worked fine. I think a few years ago >>>my implementation of null move needed this rule to prevent infinite >>>recursion, but I cannot remember for the life of me why this was so. >>>The worst that can happen is that you do more depth reduced >>>searches which is such a tiny fraction of the whole you will not be >>>able to measure the difference in time. But even this won't happen >>>if you do not do a null move search when the "stand pat" score is >>>already below beta. Some programs do the null move selectivity anyway, >>>or they do it if the score is CLOSE to beta. However I decided to >>>ignore any minor speedups this gave because it also introduces >>>some risk. I really doubt you can prove one is better than the >>>other and my current program doesn't even register a speedup for >>>this. >>> >>>- Don >> >> >>Two nulls in a row?? I don't understand that. How could either side move at >>all if you have consecutive null moves? Or maybe you mean multiple nulls along >>the same branch? >> >>Will > >I mean consecutive null moves. Player A makes a null move and the first >thing Player B tries is also a null move. If player A thinks he is winning, >then player B's null move search will fail and he will be forced to resort >to the full width search. This full width search is what will be returned >to player A, NOT the result of a series of consecutive null moves. > >Remember, a null move result will only be returned for one side and >only if that side is happy (happy means >=beta) It is true that if you >are doing a very deep search you will get some, even several consecutive >null moves, but at least one side (and possibly both) will reject this. > >Perhaps another way to think about it is this: Pretend that your >move generator returns all the legal moves plus a NULL or PASS move. >Your search may generate lots of lines where players make several >consecutive null moves. But unless these actually produce a beta >cutoff (or zugzwang) they will get ignored. > >This clearly will not break the chess program and in fact you have >just implemented a null move search, although a bad one since there >is no depth reduction. So just add depth reduction and you have >a real null move implementation! > >- Don What a wild idea. Thanks for posting this. I've never read about this in the literature, but I probably just missed it. Will
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.