Author: Christophe Theron
Date: 08:01:48 12/30/01
Go up one level in this thread
On December 30, 2001 at 06:21:00, Severi Salminen wrote:
>>I do not see the point of it.
>>The point is to see the number of nodes that I can save if
>>I have the same order of moves and could use SEE to get the same result as
>>qsearch.
>>
>>The nodes in the beginning of the qsearch are not nodes that I could avoid by
>>using SEE.
>
>Now I'm totally lost. SEE (static exchange evaluator) is used primarly to sort
>captures more accurately. It gives more accurate info than if ordered just by
>MVV/LVA. SEE can also be used to prune seemingly losing captures (or captures
>that are not good enough) in qsearch. I don't understand the second paragraph:
>"The nodes in the beginning of the qsearch are not nodes that I could avoid by
>using SEE.". Of course not because they are the first nodes where you would
>apply the pruning characteristics of SEE. But what comes to definitions: every
>node where you apply eval() is qsearch node. Are you counting this way? What is
>the ratio of qnodes/allnodes if you count them this way in your engine? So
>increment qnodes in the beginning of qsearch and nodes after you call qsearch()
>in search(). I'm just curious and I think you have different definition for node
>than other programmers.
>
>Severi
The first use of SEE (historically) is not to sort capture moves.
The first use of SEE is to replace what we call now QSearch.
You arrive at a horizon node. Now you want an evaluation of this node. There are
two main ways of doing this:
1) you call your SEE, and it tells you how much material the side to move can
win in this position (by doing a Static Evaluation of the possible Exchanges
from this position). You return a score of eval+SEE (or eval-SEE depending on
your conventions).
2) you call the QSearch, which is going to try all the possible captures and
return a minimaxed score.
We are talking in this thread about the advantage of 1 on 2 (or vice-versa). So
we want to compare the difference of the tree size of 1 or 2.
While I understand that you want to count horizon nodes in the QSearch (after
all each horizon node is the root of its QSearch), horizon nodes are also
visited by the first method (SEE).
So in order to compute the difference in visited nodes of the two methods, you
need to count QSearch nodes that would not be visited by the SEE method. So you
don't count horizon nodes (you don't count the root of the QSearches, only the
moves or nodes which are generated BY 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.