Author: Don Dailey
Date: 12:53:49 02/24/99
Go up one level in this thread
On February 24, 1999 at 13:49:49, Will Singleton wrote: > >On February 24, 1999 at 07:44:06, Vincent Diepeveen wrote: > >>On February 24, 1999 at 02:30:21, Will Singleton wrote: >> >>>On February 24, 1999 at 01:16:56, Sylvain Lacombe wrote: >>> >>>> >>>>I just finished implementing the null move. At first, i thought it wasn't saving >>>>much time. Then, i reallize that it does save alot, but only at deeper plys. On >>>>the first few plys, i think, it evens slow me down. Is that normal? Am i doing >>>>something wrong? >>>> >>>>I don't use the null move at the first ply, only at the second. It save about >>>>40% reaching deep 6. But it takes about 10% more for reaching deep 3 and 4. >>>> >>>>Hope, you can help. >>>> >>>>Thanks. >>>> >>>>Sylvain. >>> >>>You're probably doing something wrong. But get a second opinion. :) >>> >>>My prog will use about half as many nodes early on, like up to ply 5, then the >>>effect becomes more pronounced, and in plys above 7 or 8 can show 2-3x >>>reductions. But it depends on the position. If there's a single best move, >>>there's more reduction than if the position is pretty quiet. So try it on a >>>couple of different test suites, like wac vs Bratko-Kopec. Or, use the >>>positional BK positions measured against the tactical ones (12 each). >>> >>>Of course you wouldn't use null on the first ply, that would make it kind of >>>hard. Are you using a reduction factor of 2? That's the most popular, it >>>seems. I'm testing R=3 now, seems to work OK. But stick with 2 to start. >>> >>>Also, make sure you don't do 2 nulls in a row. And, for testing purposes, you >>>should probably limit a null move to one per search (I mean, once the null has >>>been done, don't do it again below that node). Then when it's working better, >>>test out multiple nulls. >>> >>>Null moves are susceptible to zug positions, so just disable them in the >>>endgame. You can try out better things later. >>> >>>Don't do null when in check! >>> >>>There's an open question about allowing nulls in the pv, so look at that. And >>>make sure to clear the ep flag after a null. >> >>This is no open question. Of course always do nullmove. >>If it doesn't give cutoff then you still can see whether you need a >>mating extension. >> >>It saves for me a lot anyway. ALWAYS do nullmove, just take care you >>don't improve your alfa with it if it fails. Some do that, but i'm >>not a big fan of that. > >Yes, just recently I took the alpha update out, since it seemed to be causing >problems on occasion. I don't know that for certain, but in my case, it's >working better. > >Will My null move is a "test" search, it always has a zero width window. All I care about is whether you get a beta cutoff and seems to be a slight improvement. I also had occasional trouble with the alpha updates when I used to use them, but the zero width window solves this problem and is seems to be slightly faster too! 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
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.