Author: Robert Hyatt
Date: 08:08:34 12/30/97
Go up one level in this thread
On December 30, 1997 at 07:08:32, Chris Whittington wrote: > >On December 29, 1997 at 17:31:25, Robert Hyatt wrote: > >>On December 29, 1997 at 17:18:05, Chris Whittington wrote: >> >>> >>>On December 29, 1997 at 15:07:36, Robert Hyatt wrote: >>> >>>>On December 29, 1997 at 14:37:53, Stuart Cracraft wrote: >>>> >>>>>On December 28, 1997 at 13:30:31, Robert Hyatt wrote: >>>>> >>>>>>On December 28, 1997 at 11:47:20, Stuart Cracraft wrote: >>>>>> >>>>>>>What is SEE? Some canned knowledge routine? >>>>>> >>>>>>Static Exchange Evaluator... a procedure that looks at all possible >>>>>>captures on a specific square and returns a score based on the expected >>>>>>gain (or loss) of initiating the first move of the exchange sequence... >>>>>> >>>>>>used to order captures for one thing... and to cull outrageously >>>>>>losing captures for another... >>>>> >>>>>How much increase in quiescence-search (and overall search) efficiency >>>>>does this provide? Or speedup for that matter. >>>>> >>>>>Is your SEE routine written in a way that it would be simple to >>>>>rewrite/convert >>>>>for another program? >>>>> >>>>>Which of the Crafty modules is it actually in? >>>>> >>>>>Thanks, >>>>>Stuart >>>> >>>> >>>>It is in swap.c... >>>> >>>>It can speed up the search by a factor of 2 or 3, assuming you aren't >>>>doing anything "good" about ordering your capture search yet. If you >>>>apply SEE to each capture, sort based on the score returned, the tree >>>>will shrink. If you toss out captures (in the q-search) where SEE >>>>returns a score < 0, you will get another big reduction... and if you >>>>use the SEE score to defer losing captures until after winning captures, >>>>hash move, even exchanges, history and killer moves, you will save even >>>>more time... >>> >>>Just a thought: suppose *all* programs perform the capture search >>>according to the theory: try all 'winning or equal' captures and cull >>>the rest. >>> >>>Then you play all these programs against each other to produce an SSDF >>>list. >>> >>>Would it be any surprise if the list measured this sub-game of chess >>>performance? >>> >>>Multiply it up by all the other 'kludgey' things that chess programs all >>>do, and what have we got ? >>> >>>Chris Whittington >> >>No idea. I do this because, as I have written many times, I *don't* >>want >>the quiescence search to find tactics. Because it is not qualified to >>do >>so. I only want it to evaluate the most elementary of tactics, the >>capture >>moves. I don't want it to consider checks, or find overloaded pieces, >>or >>anything like that, because I don't trust it to do so. IE if you >>include >>PxR, QxB, because the P was overloaded defending two pieces. But >>suppose >>you try that and follow it because it appears to win two pieces for a >>rook, but after RxN, you discover your opponent casually plays Bb2 >>pinning >>that rook on your king and winning it outright. You won a knight, >>dropped >>a rook, and could end up losing. I don't know how to pick up that Bb2 >>pinning >>move in the q-search. And since I don't, I really would like to see my >>q-search almost non-existant, because it is so inaccurate. But this >>lets >>the normal search depth reach a level that is quite good. Remember that >>what you do at the tips is expensive, while what you do well inside the >>tips is almost free... I'm trying to control "the work at the tips..." >> >>losing captures, you occasionally will pick up on an overloaded piece >>(RxN, > >Er, > >this wasn't quite the point I was trying to make, sorry. > >Try again: if all programs do the same thing (ie cull bad captures in >the q-search); and we then construct rating lists of these programs >performance against each other; isn't it a bit like a rating list of >fighting octupii with seven legs against each otherf ? > >Or, does it actually measure chess ? > >And, since many programs perform many other kludges of such type, isn't >the result like octopii fighting with well less than their full >complement of legs ? > >So, I seek to warn of the dangers of everybody operating to the same >paradigm and then incestuously comparing their 'strengths'. > >Chris Whittington Sorry... wasn't trying to "put words in your mouth." :) I understood your point. I wanted to explain why I am a "lean and mean" q-search practitioner rather than trying to find deep mates and tactical things in the q-search. I agree with your comment, which is why I don't do much "crafty vs crafty" testing. It is too easy to skew results in one direction, while actually moving the "performance level overall" in the opposite direction. I am a firm believer in "variety is the spice of life", one of the main reasons I play on ICC all the time. That doesn't tend to expose just one weakness, it tends to expose *all* weaknesses...
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.