Author: Uri Blass
Date: 04:12:29 08/30/02
Go up one level in this thread
On August 30, 2002 at 06:46:52, Sune Fischer wrote: >On August 30, 2002 at 06:29:37, Uri Blass wrote: > >>On August 30, 2002 at 05:51:37, Sune >>I don't know what a 'verification search' is, but I bet it isn't free to do, so >>>in some positions they surely must be weaker because they 'waste' time on this >>>verification. >> >>It is better to be 0.1% slower in order to avoid stupid mistakes even if the >>mistakes happens only one time out of 500 games and there was one engine-engine >>game when I saw a stupid mistake. >> >>I believe that they can do it. >> >>Here is a simple idea(this idea can be improved but the point is that even this >>idea can do their program better) >> >>Before searching if there is a threat to depth x>12 do a small search to depth >>((x-10)/2) and get an exact score of the position when it is white to move and >>when it is black to move. >> >>If you see that the exact scores suggest a big zugzwang do not use null move >>pruning. > >But is a 1-2 ply search usually enough to detect zugzwangs? > >And what if this verification is wrong? >Often the initial plies return very different scores from the deeper ones, so >you may turn off nullmove when you shouldn't have. I said only when there is a big difference. I do not expect a big difference against the side to move at small plies when there is no zugzwang. I already found the relevant position that Fritz blundered because of the fact that they used super aggresive null move pruning You can see that the right move is in the pv but Fritz did not anlayze it because it threats nothing. The move failed low every iteration until Fritz found another move that does not win. I avoid null move in pv lines and every other program that I know does it but Fritz does not care about it. Deep Fritz default: Luba kristol - Uri blass 1n6/1P6/8/2P5/p3kp1p/6p1/1P4K1/4N3 b - - 0 1 Analysis by Deep Fritz: 54...a3-- ³ (-0.31) Depth: 1/3 00:00:00 54...a3-- ³ (-0.31) Depth: 1/3 00:00:00 54...f3+! ³ (-0.38) Depth: 1/3 00:00:00 54...h3+! ³ (-0.50) Depth: 1/3 00:00:00 54...h3+! 55.Kxh3 µ (-0.91) Depth: 1/3 00:00:00 54...Nc6! -+ (-1.69) Depth: 1/3 00:00:00 54...Nc6! -+ (-2.13) Depth: 1/3 00:00:00 54...Nc6-- -+ (-1.81) Depth: 2/4 00:00:00 54...Nc6-- -+ (-1.81) Depth: 2/4 00:00:00 54...Kd4! -+ (-2.09) Depth: 2/6 00:00:00 54...Kd4! 55.Nf3+ -+ (-2.22) Depth: 2/6 00:00:00 54...Kd4 55.Nf3+ Kxc5 56.Nxh4 -+ (-2.22) Depth: 3/8 00:00:00 54...Kd4 55.Nf3+ Kxc5 56.Nxh4 Kd5 -+ (-2.22) Depth: 4/10 00:00:00 54...Kd4 55.Nf3+ Kxc5 56.Nxh4 Kc6 57.Ng6 -+ (-1.97) Depth: 5/11 00:00:00 54...Kd4-- -+ (-1.66) Depth: 6/12 00:00:00 2kN 54...Kd4-- 55.Nf3+ Kxc5 56.Nxh4 Kc6 57.Ng6 Kxb7 -+ (-1.47) Depth: 6/13 00:00:00 2kN 54...Kd5! -+ (-1.50) Depth: 6/13 00:00:00 2kN 54...Kd5! 55.Nd3 Kd4 56.Nxf4 Kxc5 57.Ne6+ Kd6 -+ (-1.75) Depth: 6/13 00:00:00 3kN 54...Nc6! -+ (-1.78) Depth: 6/13 00:00:00 4kN 54...Nc6! 55.Kh3 f3 56.Nxf3 -+ (-2.13) Depth: 6/13 00:00:00 6kN 54...Nc6 55.Kh3 f3 56.Nxf3 Kxf3 57.Kxh4 g2 -+ (-2.41) Depth: 7/15 00:00:00 8kN 54...Nc6-- -+ (-2.09) Depth: 8/10 00:00:00 10kN 54...Nc6-- -+ (-2.09) Depth: 8/18 00:00:00 12kN 54...Nc6! -+ (-2.41) Depth: 9/17 00:00:00 28kN 54...Nc6-- -+ (-2.09) Depth: 10/14 00:00:00 37kN 54...Nc6-- -+ (-2.09) Depth: 10/19 00:00:00 45kN 54...Nc6! -+ (-2.41) Depth: 11/20 00:00:00 87kN 54...Nc6-- -+ (-2.09) Depth: 12/21 00:00:00 128kN 54...Nc6-- -+ (-2.09) Depth: 12/24 00:00:00 173kN 54...Nc6-- -+ (-1.78) Depth: 13/21 00:00:00 261kN 54...Nc6-- -+ (-1.78) Depth: 13/26 00:00:00 378kN 54...Nc6-- -+ (-1.47) Depth: 14/24 00:00:01 660kN 54...Nc6-- -+ (-1.47) Depth: 14/28 00:00:01 922kN 54...Nc6-- µ (-1.16) Depth: 15/27 00:00:02 1600kN 54...Nc6-- µ (-1.16) Depth: 15/30 00:00:03 2191kN 54...Nc6-- µ (-0.84) Depth: 16/29 00:00:05 3412kN 54...Nc6-- µ (-0.84) Depth: 16/30 00:00:06 4682kN 54...Ke3! µ (-0.88) Depth: 16/35 00:00:11 8378kN 54...Ke3! 55.Nc2+ Kd3 56.c6 Nxc6 57.Nb4+ Ke2 58.Nxc6 f3+ 59.Kh3 f2 60.b8Q µ (-0.97) Depth: 16/39 00:00:14 9888kN, tb=1 54...Ke3 55.Nc2+ Kd3 56.c6 Nxc6 57.Nb4+ Ke2 58.Nxc6 f3+ 59.Kh3 f2 60.b8Q µ (-0.88) Depth: 17/37 00:00:24 17729kN, tb=7 54...Ke3 55.Nc2+ Kd3 56.c6 Nxc6 57.Nb4+ Ke2 58.Nxc6 f3+ 59.Kh3 f2 60.b8Q µ (-1.13) Depth: 18/40 00:01:14 55000kN, tb=72 (blass, tel-aviv 30.08.2002) > >You may end up being over cautious, I think that can be just as bad as being >careless. It is a question of tuning of course. > >>The only reason that I did not use that kind of idea(with smaller number than >>10) in movei is that I found that it cause movei to search more nodes in other >>branches of the tree so I guess that I should be careful to define a special >>search function that does not change history tables,killer moves or hash tables >>in order to use that idea in a productive way. > >That sounds a bit odd, nodes searched should help in the history matrix, and the >hash tables (if you have the right replacement strategy) shouldn't be affected >either I think, on the contrary. I do not know. The possible problem is if I search for an exact score and the exact score is clearly different than the score of the root position. It is possible that in that case the killer moves are different so I get misleading information. I do not know if this was the problem but I know that I searched more nodes then I expected inspite of finding no zugzwang. I expected to search more nodes but I did not expect to search more nodes after including the nodes that I search to find if there is a zugzwang. I decided that it is not important enough to investigate it today and I left movei with null move pruning without verification search. 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.