Sven Schüle wrote:In my probably poor understanding of English, asking "why would you do that" as in the given context seems to imply saying "that makes no sense". Since you even confirmed that with your first sentence above I see that my understanding was not too bad ... And no, we don't agree on that, of course
Yes, it means it does not make sense
to me. And I even specified exactly why. So it asks you to explain what I am overlooking. And so far I haven't heard any of that. "everyone else does it" is not really an argument that counters my objection...
Aspiration window has not become obsolete, you can easily see that when following some chess programming threads. Also take a look at Stockfish, I already mentioned it.
Well, that others use it, doesn't prove it is not obsolete. Some would say mailbox boards became obsolete since the advent of 64-bit computers, and there still are top engines that use that too.
And yes, indeed I know a reason why people are using the "traditional" approach: it is simple, while solutions like the one you are proposing tend to create new trouble. And believe it or not: most probably you can't judge about that unless you have implemented aspiration windows in your own engine.
What solution am I proposing? Using plain PVS without aspiration? How is that "creating new trouble"???
Yes, the hash hit will reduce the subtree node count to 1, but only for the re-search of nodes that have already been searched with a lower beta in the same iteration. So there will be nothing detrimental, and no need to take any special provisions.
So that is
all moves searched so far, right? Including moves that increased alpha, including the move that could be second best, and having the lowest move count would be sorted as very last in the next iteration. And you say that is not a problem???
You need to keep track of the second-best move in order to do so. And furthermore, you need to think about the semantics of the whole search at the root node. The way you see it means that you increase "beta" locally just for one move (and possibly all subsequent root moves), and you do this within the body of the root move loop. But at the root node level the search was started with a different (tighter) alpha-beta window, so you get into unnecessary trouble on semantical level: what does it mean to get back a value at root that is >= the original beta but < the new beta?
This seems all nonsense. The archetypal root search is
Code: Select all
RootSearch()
{
GenerateMoves();
firstMove = TRUE;
for(depth = 1; depth < maxDepth; depth++) {
SetAspirationWindow();
for(ALL_MOVES) {
MakeMove();
score = -Search((firstMove ? -alpha-1 : -beta), -alpha);
if(score > alpha) {
if(!firstMove && score < beta) score = -Search(-beta, -alpha); // PVS
if(score >= beta) { // aspiration fail high
score = -Search(-INF, -alpha);
}
}
UnMake();
if(score > alpha) {
alpha = score;
bestMove = move;
if(score>beta) beta = score+1;
}
firstMove = FALSE;
TakeNodeStats(move);
}
SortMoves();
}
}
There is no second-best move or anything, no confusion on what beta is... It is all straightforward and simple.
Code: Select all
The normal thing at [u]each[/u] node is that you leave the node prematurely (cut off all remaining subtrees) whenever the best score is >= beta,
Of course not. The normal thing is you go to the next iteration (ID or IID).
and return to the calling context, which is usually the parent node but for the root is the iterative deepening context. What you want to do is actually not leaving the root node. I agree that "jumping in the middle" is not the appropriate term but it is similar to that if you think of your approach as if you would re-search the root node but skip the first root moves.
Well, if I really wanted to argue, I would not even want to return
to the root node. Letting Search in the above code return only to be called immediately again for the same position (so it destroyed everything it might have learned about that position, in terms of ordering of its move list), just to change its alpha. It would have been far more efficient to have that node chenge its own alpha when it failed low, also in the PVS implementation in Search (as opposed to SearchRoot).
But that is not what we are discussing here. The implementation of PVS as written above is absolutely standard. The only difference is that with aspiration you might have to re-search twice, because aftr the PVS re-search, it could now also be outside the aspiration window.
No, that was exactly what I wanted to point out it was not. It is only in your theory that re-search does not involve the whole root node.
No, my "theory" was that it was pointless to re-search moves that failed low with a larger beta, because the will fail low in the same way, as their fail low is controlled by alpha, and not by beta. And so far this has not been contradicted in any way.