Author: Robert Hyatt
Date: 14:35:02 09/10/99
Go up one level in this thread
On September 10, 1999 at 16:53:50, jonathon smith wrote: >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. > Hi Chris. :) I understand a _lot_ more than you give me credit for. IE I absolutely understand how alpha/beta works... >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). > what has that to do with which move is best? We searched them all. All produced a score <= alpha. All I really know about those moves is that each is worse than the worst thing I am expecting. I don't know which is the best of this 'worse' bunch of things. And alpha/beta won't tell me. To do so requires minimax.. > >Large space left here for reams of bluster and goal-post shifting .... > > > > No goal post shifting. I implemented the idea, posted the results. Which support the position that if all moves are <= alpha, you can't tell them apart within the alpha/beta framework. This is in _any_ AI text that covers alpha/beta, it was also explained in the original alpha/beta paper, and the analysis of that algorithm published by Knuth and Moore. And it isn't about bean-counting vs something "higher". It is about pure mathematics and nothing else. > > > > > > > > > > > > > >Above space deliberately left blank. > Actually that was the best part of your post. :) > > > >>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.