Describe the issue
Careful analysis of our code around
|
if (mainThread |
|
&& (threads.stop || pvIdx + 1 == multiPV || nodes > 10000000) |
|
// A thread that aborted search can have a mated-in/TB-loss score and |
|
// PV that cannot be trusted, i.e. it can be delayed or refuted if we |
|
// would have had time to fully search other root-moves. Thus here we |
|
// suppress any exact mated-in/TB loss output and, if we do, below pick |
|
// the score/PV from the previously completed iteration with the most |
|
// recent bestmove change. |
|
&& !(threads.stop && is_loss(rootMoves[0].uciScore) |
|
&& rootMoves[0].score == rootMoves[0].uciScore)) |
|
main_manager()->pv(*this, threads, tt, rootDepth); |
reveals two issues:
1.If a search for a side move (pvIdx > 0) is interrupted, we may output an unproven mated-in score for that move. That is in fact not an issue, as we do not claim perfect ranking of multiPV lines. So if a sideline leads to a mated-in X, we may as well output that for that move.
2. If a search for a side move (pvIdx > 0) is interrupted, we may suppress a valid exact mated-in score for the bestmove.
Moreover, the current fall-back mechanism for interrupted searches with mated-in score in standard analysis selects a previous PV with an exact score. That PV is chosen from the most recent bestmove change. Hence in very rare cases, the final PV output may differ from rootMoves[0].pv in all but the first move (the first move is guaranteed to still be bestmove). In particular, the final PV output may not match the stated ponder move in rare cases.
Expected behavior
Do not show unproved mated-in scores for side-moves in aborted multiPV analysis. See above.- Do not suppress proven mated-in score for bestmove in aborted multiPV analysis.
- Do not output ponder moves that do not match the second move of the final exact PV line output in standard analysis.
Steps to reproduce
Extremely hard to reproduce. Fastchess at present does not check for ponder moves yet. And matetrack does not support multiPV yet.
Anything else?
I plan to rework the mated-in treatment logic in master, which should fix the three issues.
Operating system
All
Stockfish version
master
Describe the issue
Careful analysis of our code around
Stockfish/src/search.cpp
Lines 424 to 434 in 702d4b8
reveals two issues:
1.
If a search for a side move (pvIdx > 0) is interrupted, we may output an unproven mated-in score for that move.That is in fact not an issue, as we do not claim perfect ranking of multiPV lines. So if a sideline leads to a mated-in X, we may as well output that for that move.2. If a search for a side move (pvIdx > 0) is interrupted, we may suppress a valid exact mated-in score for the bestmove.
Moreover, the current fall-back mechanism for interrupted searches with mated-in score in standard analysis selects a previous PV with an exact score. That PV is chosen from the most recent bestmove change. Hence in very rare cases, the final PV output may differ from
rootMoves[0].pvin all but the first move (the first move is guaranteed to still be bestmove). In particular, the final PV output may not match the stated ponder move in rare cases.Expected behavior
Do not show unproved mated-in scores for side-moves in aborted multiPV analysis.See above.Steps to reproduce
Extremely hard to reproduce. Fastchess at present does not check for ponder moves yet. And matetrack does not support multiPV yet.
Anything else?
I plan to rework the mated-in treatment logic in master, which should fix the three issues.
Operating system
All
Stockfish version
master