Author: jonathon smith
Date: 13:53:50 09/10/99
Go up one level in this thread
On September 10, 1999 at 16:36:44, Robert Hyatt wrote: >On September 10, 1999 at 15:58:45, Ed Schröder wrote: > >> >>For one moment forget about alpha and beta, you are on the wrong track as >>alpha and beta are not a part at all of the code. You need an extra stack >>that is set to -INF at each ply. Then before you do A/B you do the bestmove >>calculation for that ply. Involved variables: SCORE and STACK, no alpha beta. >> >>Ed > >I understood that... but alpha and beta play a roll in this.. because each >time you call Search() and then do your test with "best" when the score comes >back, you get a bound... and nothing says that you get the _best_ bound on the >score for each move you search, you only get a bound that is <= alpha. And they >aren't directly comparable with each other, because the search stops as soon as >any move at the next ply returns a score >= beta (which is <= alpha at the >current ply). Even though there could be even _better_ moves were the search >at the next ply to be completed. IE, we learn this: > >value for move1 <= 200 >value for move2 <= 150 > >no way to say that the first is better than the second. We simply don't know >that. Oh God. It's so pitiful. Immersed in bean-counter quiescent paradigm and unable to see the bleeding obvious. Non-understanding of thread concept = no semi-accurate static evaluation function. Understanding of thread concept = evaluation function with which able to make some sensible decisions. Hint: with semi-accurate evaluation, able to order all moves on basis of evaluation function carried out on each (remember, you already searched them all - non-bean-counter programs also evaluate them at each node). Large space left here for reams of bluster and goal-post shifting .... Above space deliberately left blank. >It might be. Or it might not be, because the alpha/beta search done >below this node doesn't supply that information. > >in any case, trying this was certainly slower for me, as the tree always got >bigger, because I try the hash table move before _all_ other moves. And with >this approach, for me, it was wrong far more than it was right, and the tree >grew as a result.
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.