Author: Robert Hyatt
Date: 08:20:59 11/29/02
Go up one level in this thread
On November 29, 2002 at 08:46:06, Omid David Tabibi wrote: >On November 28, 2002 at 20:08:42, Robert Hyatt wrote: > >>On November 27, 2002 at 16:53:29, Tony Werten wrote: >> >>>On November 27, 2002 at 15:15:50, Robert Hyatt wrote: >>> >>>>On November 27, 2002 at 13:48:50, Frank Phillips wrote: >>>> >>>>>On November 26, 2002 at 20:02:06, Robert Hyatt wrote: >>>>> >>>>>>On November 26, 2002 at 16:21:00, Omid David Tabibi wrote: >>>>>> >>>>>>>On November 26, 2002 at 15:58:06, Gian-Carlo Pascutto wrote: >>>>>>> >>>>>>>>On November 26, 2002 at 15:55:56, Omid David Tabibi wrote: >>>>>>>> >>>>>>>>>So it is reasonable that on every program starting from a certain depth >adaptive null-move pruning will always construct a smaller search tree. >>>>>>>> >>>>>>>>Don't you mean the other way around? >>>>>>>> >>>>>>> >>>>>>>Yes :-) >>>>>>> >>>>>>>Starting from a certain depth, verified null-move pruning will always construct >>>>>>>a smaller search tree than the adaptive one. >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-- >>>>>>>>GCP >>>>>> >>>>>> >>>>>> I am doing some testing now. First thing I noticed is that for WAC, the >>>>>>time-squared >>>>>>measurement went down very significantly for your algorithm. And I have not >>>>>>modified >>>>>>anything such as turning null-move off when low material happens, since your >>>>>>idea will >>>>>>catch the zug problems. >>>>> >>>>>Have you tried Fine70? >>>>> >>>>>Frank >>>> >>>>Yes... and I told Omid that this is a strange case as if I allow null-move in >>>>pawn-only >>>>endings, which turns it on for fine 70 of course, things get wrecked inside the >>>>search >>>>somehow. A 45 ply search fails to see that Kb1 wins where normally an 18-19 ply >>>>search is enough... >>> >>>Instead of one verification flag ( I implemented it as a global variable, was >>>easiest ) you need 2. One for black, one for white. >>>It only costs a few extra nodes, but you solve the problems of both sides being >>>in zugzwang somewhere in the search. >>> >>>Tony >> >>That is easy enough to do but I don't think it will solve the problem, >>since there are _many_ null-move searches that don't get verified, and those >>are all subject to zugzwang... >> > >Did you try using a reduction of 2 after fail-high report, and doing verified >search also in the subtree (i.e., never cutting off based on the null-move >search alone)? This will definitely solve any zugzwang correctly. > Not yet, no. It is on my list of things to try however... > >> >>> >>>> >>>> >>>>>> >>>>>>
This page took 0.01 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.