Author: scott farrell
Date: 17:51:57 01/10/04
Go up one level in this thread
On January 10, 2004 at 11:44:01, Robert Hyatt wrote:
>On January 10, 2004 at 01:58:21, scott farrell wrote:
>
>>One thing I realised when working on all the qnodes vs SEE vs even captures etc
>>etc. Is that anything you put in the qsearch, is less likely to be horizoned
>>obviously. It also has an effect of not having to appear in the full width
>>search PV, and therefore leaves more room for other moves in the PV, allowing
>>for better play (is the assumption anyway).
>>
>>Obviously getting to the next ply faster with less qnodes also gets a better PV
>>and better play.
>>
>>Take the example of an even capture, SEE says even , so it is pruned in the
>>qsearch ( fairly common, and is what happens in crafty).
>
>Crafty doesn't prune "equal" captures. It prunes only _losing_ captures
>(losing according to SEE). If the expected material gain/loss is zero,
>the capture is included in the q-search. That is why the lines
>
>tmp=Swap();
>if (tmp >= 0) {
>
>are used.
>
yes, thanx Robert, I saw that code. And I read that as "prunes equals captures"
... clearly it includes equal captures, I wonder why I didnt see the = first
time around (I have quiese.c open in another window for reference), and its
amazing how the brain will then continue to overlook such things, even with you
quoting it I saw "tmp>0" in my head and almost argued with you.
no wonder I came to the conclusion its too unsafe to prune "SEE even" captures.
Scott
>
>
>>
>>If it is actually winning either material or position, then the main full width
>>will have to find it , and use 2 slots in the PV, if you recapExtend it, it only
>>takes one. So I think this has the effect of extending those PVs that dont have
>>the capture in it, but horizining it to the qsearch.
>>
>>With ideas from Tord, Sune, Robert, Uri, I think I'll modify the SEE for so that
>>it returns a complexity level more than a score, or it can return a score or say
>>_invalid_ if its over complex. But this is a whole nother thread below. So I
>>will probably make it different again for even captures.
>>
>>Anyway, I am after comments/ideas on just qsearching all even captures. Lets
>>leave alone the strict performance consideration for the minute. I am more
>>intersted in people's opinion on changes to the PV/strength/play, etc etc. Given
>>you work out code that does real fast on these even captures in the qsearch, you
>>can minimize the performance loss somewhat.
>>
>>Scott
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.