Author: Tom Likens
Date: 20:09:08 02/27/06
Go up one level in this thread
On February 27, 2006 at 22:24:58, Robert Hyatt wrote: >On February 27, 2006 at 19:48:49, Tom Likens wrote: > >>On February 27, 2006 at 19:36:10, Tom Likens wrote: >> >>>On February 27, 2006 at 13:41:57, Robert Hyatt wrote: >>> >>>>On February 27, 2006 at 12:46:40, Frank Phillips wrote: >>>> >>>>>So you do this at only (expected) cut nodes? >>>>>Tord seems to imply at anything other than pvNodes. >>>>> >>>>>Frank >>>> >>>> >>>>I do it at _all_ nodes. I think Tord does as well. The problem is it is >>>>impossible to predict with high accuracy whether a node is CUT or ALL (btw, this >>>>is only useful at ALL nodes, since we have to search all moves and reducing the >>>>depth reduces the effort required to accomplish that). >>> >>>Bob/Tord, >>> >>>I just got to my hotel (I'm on a business trip for the next few days) and I >>>see CCT8 has sparked a number of interesting threads. Reductions are >>>especially fertile ground. >>> >>>I'd be careful reducing at PV nodes. I saw a significant drop in djinn's >>>positional strength when I applied this at PV nodes. At the very least >>>you might want to skip it at nodes where alpha/beta == RootAlpha/RootBeta. >>>Ideally, as you mentioned you only want to apply this at ALL nodes. >> >>Actually, thinking a bit more about this--makes me wonder why the history >>table didn't prevent these nodes from being reduced anyway. It may be time >>for an experiment to determine how often a "PV" node doesn't have any history >>table information. I would think intuitively this should not happen very >>often. >> >>>I've also experimented with "flipping" CUT nodes to ALL nodes if we search >>>more than 'x' moves at a CUT node without a fail-high or an improvement >>>in the score. Once the flip occurs all the nodes below are toggled in the >>>normal CUT -> ALL -> CUT etc., and these nodes become eligible for reduction. >>> >>>Also do you allow multiple recursive reductions or do you limit them? I've >>>applied the adaptive reduction idea a while back, with mixed results. It's >>>likely I didn't test this enough because I was in the middle of a major >>>project at work and could only give it a small percentage of my attention :-( >>> >>>regards, >>>--tom > > >actually I believe you are right. I think I actually noticed this in testing >but had forgotten. And one _could_ force this to happen. I stuff the PV into >the hash table at the end of each iteration, just in case some of the entries >got overwritten. I could stuff a significant value (say 2* history threashold) >into the corresponding history values just as easily... Yes, I have tons of new experiments I want to try and instead I'm stuck out here in Silicon Valley, without access to *anything* (friggin' work, if it didn't pay the bills :) Lately, I've been reducing *all* losing captures and losing mundanes unless the node is a PV node or the history table indicates it failed-high in the past, (I also skip the reduction if the node is being extended for any reason). The re-search rate is between 0.5%-2%, which is too high but I believe the idea has potential. BTW, the losing captures/mundanes are determined by SEE. So far the extra cost of running SEE on the extra nodes of the main search has been offset by the nodes reduced. This also has the benefit of improving my move ordering in general. An interesting effect I've noticed, is that the optimal move ordering seems to be different at CUT nodes vs. PV nodes. regards, --tom
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.