This should fix following issue:
Suppose the search with MultiPVIteration == 0 returns an exact score
move = Nxf4, score = 100
Now search with MultiPVIteration == 1 and get two scores
move = Qg8, score = 150
move = Ra1, score = 180
If we now reorder all the moves in one step we end up with
pv[0] = Ra1, pv[1] = Qg8
Instead reordering as the current patch we end up in:
pv[0] = Ra1, pv[1] = Nxf4
preserving the first searched move.
No functional change in single PV.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
// because all the values but the first are usually set to
// -VALUE_INFINITE and we want to keep the same order for all
// the moves but the new PV that goes to head.
// because all the values but the first are usually set to
// -VALUE_INFINITE and we want to keep the same order for all
// the moves but the new PV that goes to head.
+ sort<RootMove>(Rml.begin() + MultiPVIteration, Rml.end());
+
+ // In case we have found an exact score reorder the PV moves
+ // before leaving the fail high/low loop, otherwise leave the
+ // last PV move in its position so to be searched again.
if (value > alpha && value < beta)
if (value > alpha && value < beta)
- sort<RootMove>(Rml.begin(), Rml.end());
- else
- // In MultiPV mode, sort only the tail of the list
- // until all fail-highs and fail-lows have been resolved
- sort<RootMove>(Rml.begin() + MultiPVIteration, Rml.end());
+ sort<RootMove>(Rml.begin(), Rml.begin() + MultiPVIteration);
// Write PV back to transposition table in case the relevant entries
// have been overwritten during the search.
// Write PV back to transposition table in case the relevant entries
// have been overwritten during the search.