Author: Peter McKenzie
Date: 01:40:59 02/25/99
Go up one level in this thread
On February 25, 1999 at 01:44:25, Will Singleton wrote: >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. There was a *huge* debate about this a few years back on r.g.c.c. Bob Hyatt was involved, can't remember who else. I personally don't allow two nulls in a row, mainly because I don't want to hurt my brain thinking about it :-) Peter > >Will
This page took 0.01 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.