Author: Tord Romstad
Date: 08:22:47 01/13/04
Go up one level in this thread
On January 13, 2004 at 10:36:30, martin fierz wrote: >On January 13, 2004 at 10:28:54, Michel Langeveld wrote: > >>The idea of Nullmove is that you let a player have the right to do two moves >>during a game. If he can't win with this right then his position is really bad, >>and we count it as lost. >>-------------------------------------------------------------------------------- >>original >>6 318 343459 -8 b1c3 b8c6 i1h3 d7d6 h3f4 c8f5 >>7 1782 2188112 3 b1c3 d7d5 d2d4 c8f5 i1h3 i8h6 c1f4 >> >>nullmove with: if (!c && !nullmoved && depth - 1 - R > 0) >>6 215 227824 -8 b1c3 b8c6 i1h3 d7d6 h3f4 c8f5 >>7 859 1008458 3 i1h3 d7d5 d2d4 c8f5 b1c3 i8h6 c1f4 >> >>nullmove with :if (!c && !nullmoved) >>6 59 63778 -3 i1h3 d7d6 g1f3 i8h6 b1c3 b8c6 >>7 342 403509 3 i1h3 d7d5 d2d4 c8f5 c1f4 i8h6 b1c3 >> >>My question is do I have to protect that after a nullmove we go immediatly into >>quiesce or can I live without this protection? > >i don't protect against it. as you can see you get a massive speedup without it. >what i (and many others of course, before me) do is to generate checks at the >first ply of qsearch. so if you nullmove, go to qsearch, you probably find out >whether you're being mated or not. if you don't have checks on the first ply of >QS, you will happily cut off in a position where your opponent can mate in one. > >so doing checks in QS is a way of protecting yourself here. There is a refinement of this idea which works well for me, but apparently not for everybody else. Whether you can make use of it depends to a certain extent on how the rest of your program works. I don't use any kind of lazy eval, and I call the full evaluation function at all interior nodes. The return value of the evaluation function, along with its components and various other information it computes, is used to decide upon extensions or reductions, forward pruning, null move reduction factor, and whether or not to search checks in the qsearch. Among many other things, my evaluation function detects the most common mating patterns. For instance, when black's king is on the back rank, the square is defended only by the king and attacked by two white pieces, one of which is a queen, the program knows that white almost certainly threatens a mate in 1. If this situation occurs in a qsearch node with white at the move, the likely mating move is searched in addition to all winning captures and promotions. This is done even at deeper levels in the qsearch, and even if the last move in the main search was not a null move. Even if no likely mate in 1 is detected by the evaluation function, I generate safe checks in the first few plies of the qsearch if the opponent's king safety is sufficiently bad. On the other hand, if I have just entered the qsearch after making a null move, there are no obvious mate threats, and the king looks entirely safe, I *don't* search any checks, even at the first ply of the qsearch. At least for me, this system works very well. The number of qsearch nodes is smaller and the tactical accuracy better than if I always search checks when entering the qsearch after a null move. In my main search, I have a variable null move reduction factor. At most ordinary nodes, I use R=3, but this is sometimes increased or reduced depending on the danger of horizon effects or zugzwang. If the safe mobility (i.e. the number of pseudo-legal moves which do not lose material) for the side to move is low, I disable null moves at this node. If the king safety for the side to move is bad and the remaining depth is low, or if the opponent has dangerous-looking advanced pawns, I sometimes decrease the reduction factor to 2 or 1. 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.