bug?

[flok]

It becomes 110 earlier than Qxa2 Rxa2 b5b4.

Node starts with -160...10000

Code: Select all

START 15f0b8764a43cf81, a -160 b 10000 : 
r3k2r/p1p2p2/2n5/qp1Pp1pp/4P3/1QP1NPPb/P2B3P/R3K2R b KQkq - 0 18, black

First thing it does is a TT look-up:

Code: Select all

15f0b8764a43cf81 got a tt entry c6e7 | 9 | 2 | -160,10000 | -110

depth 9, lowerbound, a/b before the tt, stored score

That 15f0b8764a43cf81 comes from the previous depth 9 where the first move c6-e7 in the first iteration caused the beta cut off. This is then stored:

Code: Select all

oid Brain::updateTT(Tpt *const curtt, const uint64_t hash, const int ttDepth, const int alphaOrig, const int beta, const int bestVal, const Move & m) const
{
        tptEntryFlag newFlags = EXACT;

        if (bestVal <= alphaOrig)
                newFlags = UPPERBOUND;
        else if (bestVal >= beta)
                newFlags = LOWERBOUND;

        curtt -> store(hash, newFlags, ttDepth, bestVal, m);
}

[hgm]

It should never be possible for a move to be used if it did not score above alpha. If you keep a separate "bestVal" for fail-soft purposes, raising bestVal in itself should not be a reason to take the move serious. It only means you now have a less strict upper bound on the score of the current node, but all moves so far searched in that node could still be arbitrary poor. (This would indeed be solved by moving the useMove = true to the if(val > alpha) clause that you proposed.)

It is not clear to me why you search Qxa2 in the d=9 re-search before Ne7. If you have a TT hit on the result of that previous search, which you use to increase alpha to -110, you should have seen that Ne7 was a hash hit, and you should have searched that before Qxa2. It should have been necessary to re-search Ne7, as the TT only contained a lower bound that was not >= beta (which now is 10000).

If indeed the search of Ne7 with window {-110, 10000} would have given you a score above -110 this would have established Ne7 as best move, and set bestVal to above -110, so that Qxa2 could not have usurped the best-move status.

You should always be prepaired that the search ca be unstable, and that the search of Ne7 with enlarged window willnot live up to the promisedlower bound of -110, and thus fail low. In that case -110 for Qxa2 would still be no justification for making it best move, it is still a fail low. After searching of all moves you might have no move at all, and the root would now fail low. So you would have to re-search it again. Note that this could give you root scores that are upper bounds (e.g. -130) that are above alpha of the original window (which was {-160, 10000}),so that you cannot determine the fail low by comparing score with alpha.

[flok]

It is not clear to me why you search Qxa2 in the d=9 re-search before Ne7. If you have a TT hit on the result of that previous search, which you use to increase alpha to -110, you should have seen that Ne7 was a hash hit, and you should have searched that before Qxa2. It should have been necessary to re-search Ne7, as the TT only contained a lower bound that was not >= beta (which now is 10000).

That I think I can explain; I found a problem with the move-sorting.
I have this routine that goes through the list of moves and puts the special ones at the front. Now by a typo or whatever it started searching at offset 1 instead of 0. This offset is returned and given to qsort() so that it does not sort the first n moves. So c6e7 was initially at the first position but because of that offset mistake, that c6e7 was moved to halfway the movelist.

[hgm]

So we already fixed two bugs now!

[flok]

So we already fixed two bugs now!

To be honest I found the move sorting bug earlier during this discussion but now I understand what the consequences are of it being there

nice!

thanks!