Computer Chess Club Archives


Search

Terms

Messages

Subject: more on qSearch and the like

Author: scott farrell

Date: 22:58:21 01/09/04


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).

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.