Author: Don Dailey
Date: 17:45:32 12/17/97
Go up one level in this thread
On December 17, 1997 at 20:14:55, Dan Homan wrote: > >Hi Don, > > I do is just what was suggested by Bob and Bruce. I always >use R = 2 and call the next level of search from my null move code >in the following way.... > > if (depth > R) > best = -pvs(-beta, -alpha, depth-1-R); > else best = -qsearch(ply+1, -beta, -alpha); > > If I understand you right, you do something like... > > if(depth > R) > best = -pvs(-beta, -alpha, depth-1-R); > else best = static_eval_function(); > > Where static_eval_function() does something like what you >described in your post. I don't see why this would be slower, >although the static_eval_function() might be less accurate than >carrying out the qsearch. My code looks pretty much like you show it here except static_eval_function() is really a simplified swapoff routine. It's not slower, it's faster than the code you seem to be running (at least on my program.) Is it less accurate? I don't know because it picks up things null quies misses but also misses things null quies gets. Some versions seem to be more accurate because I usually have king safety analysis too, usually major pieces attacking squares around the king with support. But the current versions doesn't have this yet. I make conservative assumptions that pick up tactics that null quies misses sometimes. But the bottom line is that when I test it, it scores better consistantly. I'm trying to figure out if I'm missing something in my null quies implementation. But I know every program responds differently to various algorthims. I am still curious about others who may combine swap off analysis with null move or simply avoid null move altogether. Is anyone else out there that does this kind of thing? -- Don > >On move ordering.... > > Bob's point about using killers after captures because they are faster >than generating the rest of the moves (for use with the history >heuristic) >is an interesting one. That must be bit-board thing, because I don't >see a good way of doing that in my current framework... I can see >how it would be quite a bit faster if I didn't have to generate all the >moves at each ply. > > I see your point about testing on more than a few positions. So far >I've been using the WAC positions. I usually test the first 20 >whenever I make even a minor change. (For some reason I still >can't get #2, much to my frustration.) If I make a larger change, >I will usually look at the first 50. I think you are right that looking >at the positions individually rather than some average is important, >but it is harder if I try to do the full set of 300. > > - Dan
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.