Author: Chris Whittington
Date: 09:12:13 12/30/97
Go up one level in this thread
On December 30, 1997 at 11:08:34, Robert Hyatt wrote: >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... Yes, but, even this has its weaknesses. ICC is mostly very fast games against low attention span humans who are on ICC for some fun to play fast chess (accepted there are some strong players who take it serious). The way to beat these humans is fast search and tactical trickery (mostly). So, I'ld argue that ICC playing tends to produce programs that go for the fast and deep solution, with a few positional fixes to deal with positional stuff. Frankly, I don't really know what is the way to generate and then quantify the chess program that's an answer for everything. My way has been to try and seriously understand each position at each node, and to be highly speculative - but this has its problems too. Chris Whittington
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.