Author: Robert Hyatt
Date: 06:37:31 10/05/98
Go up one level in this thread
On October 05, 1998 at 00:15:01, blass uri wrote: > >On October 04, 1998 at 23:29:46, Robert Hyatt wrote: > >>On October 04, 1998 at 21:21:09, Roberto Waldteufel wrote: >> >>> >>>On October 04, 1998 at 20:24:08, Will Singleton wrote: >>> >>>>On October 04, 1998 at 19:06:15, Roberto Waldteufel wrote: >>>> >>>>> >>>>>Hi all, >>>>> >>>>>I wonder what reductions various programs use for the null move. I reduce by two >>>>>plies, but I believe a one-ply reduction may be more usual. However, I have >>>>>found R=2 produces quite good results in my program. I would like to hear of >>>>>others' experiences. >>>>> >>>>>Best wishes, >>>>>Roberto >>>> >>>> >>>>Amateur uses r=2, and gets about a ply deeper on average. But I've noticed that >>>>in positions where there is a clear better move, the node reduction is great, >>>>and in positions where there is no clear cut better move, the reduction is not >>>>that great. Of course, you need it most in the latter situation. I'm probably >>>>doing something wrong. Do you notice anything similar? >>>> >>>>Will >>> >>>Yes, I have noticed more improvement when one move is clearly best than when >>>there are many plausible candidates, but I had put that down to the nature of >>>the null move! If there are many plausible moves, then that leaves fewer >>>terrible moves to cause null-move cutoffs on the next ply. Do you find the same >>>effect with R=1 as with R=2? I suspect that nodes with a clearly best move are >>>just plain easier to handle than the rest. >>> >>>Best wishes, >>>Roberto >> >> >>null move, R=2, works well and has been used in crafty for several years >>now. But it does cause problems, and definitely won't work if your >>machine is slow, because depths of 5-6 will crash and burn when you use >>null-move. The deeper the search, the safer this becomes, and I haven't >>seen null-move related losses in a couple of years now. > >If this is the case maybe it is better to do null move with R=3 for slower time >control and maybe even R=4 if you give the computer a very long time > > But early on,I >>certainly did... particular in "the" positions like black has castled >>kingside, played g6, and white gets in Qh6 and bishop/pawn on f6... the >>null-move can hide the resulting mate... >The null move can hide the resulting mate only if there is no threat >If the evaluation function give bonus for bishop or pawn on f6 or quuen on h6 >when there is a pawn on g6 I do not see how the null move can hide the mate > >Uri does it quite easily.. if we are doing a 6 ply search, at ply=3 we find a way to rip a piece so that the score is +3.00, at ply=4 we try null-move and subtract an extra two plies from the search depth, which takes us right to the q-search, where the opponent recaptures the piece, so that the null- move search fails high. I don't look at checks in the q-search, which means my q-search won't see the mate on g7, so we stop the search at ply=3 thinking that BxN is ok, when our opponent will *really* not play pxB, but will, instead, play Qg7#. Next move you see this, but it could be too late...
This page took 0.08 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.