Author: Severi Salminen
Date: 08:14:19 12/30/01
Go up one level in this thread
>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. Ok. >You arrive at a horizon node. Now you want an evaluation of this node. There are >two main ways of doing this: Ok, I didn't remember what horizon node means. >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). And when you (or was it Ed) said you spend 15% of nodes in QS you exclude horizon nodes? I think my search will look a lot better with this new counting method :) If I count the way I used to do, I have 65% of all nodes are qnodes. I'll test what the number is if I include horizon nodes to actual nodes and not to qnodes. I think we should set some standards for these bloody nodes and qnodes... Severi
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.