Author: Uri Blass
Date: 12:43:01 09/29/01
Go up one level in this thread
On September 29, 2001 at 14:51:03, Robert Hyatt wrote: >On September 29, 2001 at 11:11:33, Uri Blass wrote: > >> >>In most cases when the moves is 0.01 worse there is a threat so you cannot prune >>it by null move. > > > >That is simply wrong. Even if the second best move is only .01 worse >than the first, there are zillions of branches in that sub-tree that the >null-move will _still_ prune away quite nicely. > Most captures, for example, >are totally hopeless. Yet the search tries them all. And null-move dismisses >them far faster than a normal search would. There are always cases when null move help but the point is that there are usually more cases when it helps when the move is 0.01 worse. bad captures are pruned by null move later in the tree when there is a problem to prune good moves later in the tree. > > > >> >>if you have an obvious blunder you may prune a lot by null move(maybe not in the >>first ply but later) > > > >The tree is _full_ of horrendous blunders. Because _every_ move is searched >at every other ply. At every other ply you will _definitely_ search a bunch >of blunders, and null-move will dismiss 'em... > > > >>if the opponent capture the queen in the first ply after the blunder you can >>reject a lot of moves later because they have no threat. >> >> Because a full-width search still looks at lots of >>>very stupid moves that null-move dismisses more quickly than a normal search >>>would. >>> >>>Null-move works just fine on the _PV_ search in fact, for this very reason. >>> >>> >>>>Another reason: when the move is 0.01 worse the order of the moves is often >>>>worse than the order of the moves after a blunder. >>>> >>> >>> >>>I don't follow. On a move scored at .01, there are _still_ zillions of blunders >>>in the tree for that move. >> >>Yes, but these lines are often pruned quickly by the null move pruning and there >>are more important lines when you do not reject them for the right reason. >> > > > >The only reason you don't reject them quickly is your move ordering is broken >and is not producing the right move first. As I said before, I can >mathematically _prove_ that if you search the best move first, it doesn't >matter whatsoever about the second-best move scores... they don't add to the >size of the tree at all... Even if you search the best move first it is important. In the diagram that I gave if your order of move is perfect you are going to prune Qh4 by null move faster than you are going to prune Nc6(assuming that Nc6 is the best move). you are not going to prune the ply 2...Qh4 by null move pruning because Qh4 has a threat Qxe4+ but after Qh4 Nxh4 you are going to prune every legal move of black by null move pruning. A similiar thing is not going to happen after 2...Nc6 because 2...Nc6 is not only a move that threats something(positional threat) but you also cannot reject a big part of the black moves as no threat after a move like 3.Bb5 > > > >>example:the position after 1.e4 e5 2.Nf3 >>[D]rnbqkbnr/pppp1ppp/8/4p3/4P3/5N2/PPPP1PPP/RNBQKB1R b KQkq - 0 1 >> >>suppose 2...Nf6 is best with a difference of 0.01 pawn relative to 2...Nc6 >> >>I believe that there is a good probability that the killer move for 2...Nc6 does >>not work in the next ply and you need to look for another killer move. >> >>You can be more sure that the killer move for Qh4(Nxh4) or Qg5(Nxg5) >>or even a6(Nxe5) is the right move. >> >>Uri > >That's the point. But in that case, it is very likely that the same killer >will work. Nxh4 isn't a killer. It is found as a winning capture and won't >disturb the good killer. If Nxh4 is the first move that is searched by the computer after Qh4 then I call it a killer move and I assume that Nxh4 is the first move that is searched by good programs because it is better to start to search from a good capture of the queen and not from a capture of a pawn. Maybe my definition is not correct. I am not sure about definitions. Uri
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.