Author: Christophe Theron
Date: 21:38:05 08/26/03
Go up one level in this thread
On August 26, 2003 at 21:02:37, Tom Kerrigan wrote:
>On August 26, 2003 at 19:34:59, Ricardo Gibert wrote:
>
>>On August 26, 2003 at 19:25:39, Steve Maughan wrote:
>>
>>>Ricardo,
>>>
>>>>"For example I have never used capture searches and rely instead on a static
>>>>swap off routine."
>>>>
>>>>This seems to indicate that CG does not employ a qsearch. I also understand
>>>>that Junior does something similar. I wonder how this is done? I would
>>>>presume some type of accuracy tradeoff must be involved, but I wonder what?
>>>>I'm very curious about how this is all done and why doesn't everybody do it
>>>>this way?
>>>
>>>I guess it's either some sort of SEE or a routine to resolve the effect of
>>>attack tables.
>>>
>>>>How is all the effort that goes into creating a good eval compatible with
>>>>such a handling of non-quiescent positions? It just seems kind of wacky to me.
>>>
>>>It's different - and it clearly did work well in the 80s and 90s.
>>>
>>>Regards,
>>>
>>>Steve
>>
>>It's working pretty well right now in Junior too.
>>
>>I haven't been able to find anything on this using google or citeseer. I guess
>>how to make this work is being kept secret? It would be nice if RL could be
>>persuaded to reveal this.
>
>I don't think this is any secret. I remember reading a BYTE (?) article about
>the exchange evaluator in early versions of Sargon which they said they used
>instead of a quiescence search because micros weren't fast enough for the
>latter. If that was the case for Sargon, I imagine it was also the case for any
>other program from that era, including predecessors of Fritz, WChess, Genius,
>and Rebel.
One of the first thing you come up when you start to think about a chess program
is a way to "terminate" the search for the sake of simplicity, or in other words
you want to "evaluate" the leaf positions and to include in this evaluation the
exchange that can happen from here.
You want to do - for example - a three plies search and do not want to go any
deeper. So you want a SEE to apply to all the positions three plies deep.
When you actually write a chess program and experiment more, you realize - and
this is counter intuitive - that it is possible to search the tree of all the
captures at the point where you normally would like to call your SEE, and that
it is only marginally more expensive while being more reliable. Chess and Sargon
(from version II and on) are exemple of successful programs that have used this
method (full QSearch).
After a number of years thinking about it and experimenting with it, I believe
that it is possible to achieve even better results by sometimes doing a full
QSearch and sometimes just calling the SEE.
That's what I do in Chess Tiger.
>Right now there are programs (e.g., HIARCS) with eval terms for en prise pieces
>which isn't that much of a leap.
>
>Another thing is that Genius was very selective, so it may have run its eval
>function on positions that it considered quiescent through some other means. In
>practice not much different from a Q search.
>
>There may be a trade-off with accracy, but really, the accuracy of Q searches is
>shit anyway. It may be BETTER to evaluate things as they are than figure that a
>brain-dead sequence of captures may occur. I've been working on ways to keep my
>program from returning (inaccurate) evaluations from positions that are very
>active (e.g., hanging pieces all over) but the Q search decides are legitimate
>stopping points. Eliminating the Q search doesn't seem like a bad idea at all.
Maybe using a SEE when you know that doing a full QSearch is going to be
expensive, doing a full QSearch when you know that the SEE is not going to
return a reliable result...?
Christophe
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.