Author: Christophe Theron
Date: 21:36:18 04/16/98
Go up one level in this thread
On April 15, 1998 at 13:26:54, Peter Fendrich wrote:
>On April 15, 1998 at 13:12:57, Christophe Theron wrote:
>
>>On April 15, 1998 at 13:01:42, Peter Fendrich wrote:
>>
>>>I am trying a swapoff algorithm (sometimes called SEE) instead of the
>>> more classic quiescence search.
>>>The extra time saved by this can be used for more agressive extensions
>>>or better evaluation.
>>>The drawback is of cource the increased risk for tactical mistakes.
>>>
>>>In short depths the swapoff makes too many mistakes to be useful but
>>>when the depth increases I see less of the mistakes but still have
>>>that extra time it saves for me.
>>>
>>>In my opinion it should be a break even, at some depth limit, between
>>>these two alg's and beyond that limit the swapoff is the best choice.
>>>
>>>Comments?
>>>
>>>/Peter
>>
>>The swapoff idea is the first thing that comes in mind when someone
>>begins to write a chess program. That's how I begun, at least.
>>
>When I wrote my first chess program about 1980 SEE wasn't a known
>concept, at least not for me!
>
>>IMO it is not as fast as a simple QSearch. This is counterintuitive, but
>>as depth increase, QSearch has less and less job to do, because there
>>are more and more alphabeta cutoffs before or on entering in the
>>QSearch.
>
>The SEE code itself should be faster than Qsearch, shouldn't it?
I don't think so.
If your QSearch has only one, two or three positions to examine to get a
cutoff, I bet it is faster than your SEE.
That's why I said this is counterintuitive. If you try to imagine what a
QSearch does, you can easily convince yourself that it is a very long
process. Think: it has to try every capture in the position, then every
capture in response, then... with no depth limit. If you assume there is
always 2, 3 or 4 captures available in any position, you come very
quickly to the conclusion that the QSearch has to be avoided by any
mean.
That's what I thought in 1981 when I was writting my first chess
program. That's why I said that building a SEE was my very first idea
(at that time, I didn't know if anybody else had already tried this
idea).
But QSearch is far more efficicient that it seems at first glance. For
example, take Crafty and let it think on a position. At the end of the
search, take a look at the number of total nodes visited, and the number
of nodes visited in QSearch.
I tried this with an old Crafty version, and it seems that QSearch
visits only between 3 and 5 nodes for every node visited in the "full
width" search. Maybe it is even less, due to the way Bob counts the
nodes.
For my program, Chess Tiger, the ratio is less than that.
So depending on how your program is designed, a simple QSearch can be
faster than the best SEE you'll ever design, and far more reliable.
It may or may not be the case. Try it out.
>>On the other hand, a SEE has always the same amount of job to do,
>>whatever the depth is. In any case, more job than QSearch.
>>
>I dont't follow you here. If QSearch has less job to do, then the SEE
>has as well. The QSearch is just replaed by the SEE.
Maybe, if your SEE is aware of the values of alpha and beta and other
parameters.
If you don't use alpha and beta in your SEE, it will examine more
captures than QSearch would.
>>And I don't even mention the huge blunders you will never get rid off
>>with your SEE, even if you make it very clever.
>>
>>Just my opinion, based on experience.
>>
>>Anyway, writting a good SEE is useful, because you can use it for
>>selection purposes.
>
>I have two versions of SEE, a fast one used to order generated captures
>and one more accurate and slower to replace the QSearch.
>
>>
>>
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.