if (score > bestVal)
{
bestVal = score;
// remember move for sibling-node-best-move
selMove = *newCause.causingMove;
if (score > alpha)
{
alpha = score;
// remember PV
newPv.assign(tempPv, false);
if (score >= beta)
break;
}
}
I wonder why is there a if (score > bestval) and also a if (score > alpha)?
Because if > bestval then always also > alpha. I think I can just remove that if > alpha and maybe even rewrite things and get rid of bestVal (using alpha instead).
It would have sense only if you can start with a bestval < alpha (-infinite, for sample) and your search can returns something less than alpha but greater than actual bestval.
flok wrote:I wonder why is there a if (score > bestval) and also a if (score > alpha)?
Because if > bestval then always also > alpha.
Not if you use fail-soft. Then bestVal starts at -INFINITY even if alpha is much larger. At the end you return bestScore, and in case of a fail low this can still be smaller than alpha (which would then still be the original alpha). With fail-hard one usually does not keep a bestValue at all, as one would return alpha.
if (score > alpha) {
if (score >= beta)
return beta
alpha = score;
}
Seems more rational that way. If score is <= alpha, ignore it. Else if it is > beta, return instantly (beta cutoff) otherwise remember it as best since we now know it is > alpha and < beta...
the break in this case does something outside the scope of the quoted code - it removes you from the innermost loop you're currently in perhaps to the final 'return bestVal;' line (which you now have scored as the current score > beta). It may avoid some code duplication if the TT update is similar enough for the fail high and fail low cases to write it in this manner.
