syzygy wrote:But it's actually 7 moves for the price of 7 in terms of search work.
Only in this instance, for this specific position, in all the other positions the user analyses (say, the ones analyzed to refute A, E, F and G), it was faster MultiPV 4. In other positions it was only one that failed low, so it was 5 moves for the price of 5, and so on. The engine sets 4 as the minimum number of moves to show scores for, but if they fail low and are replaced by others, the engine would give scores to the other moves "for free" (what I mean by this below.)
Basically, the old behavior allowed the engine to show the score of more moves if the position is complex enough that the main moves from the previous iteration failed low. My example is a extreme case, usually it's just one of the move failing low to never be seen again, so the old behavior would have shows the score of 5 moves.
I didn't mean the user gets the three extra moves's scores for free, I know the search takes longer to figure out those scores, I meant the user gets them for free because they don't need to do anything to know those scores, unlike the case in "current behavior" where the user would need to use "go searchmoves" to ask the engine for the score of the fifth best move.
Now, it has dawned on me to use "always score main move" (sit on fail lows, and resolve them to a score, before checking alternative moves) only in the last iteration the user is interested in, in this case Depth 28.
So in my dream world, Stockfish (and the other engines that now behave like this) would have an "always score main move" tick box, and a depth box where the user would specify, at what point in the search the engine uses old behavior, so that the engine shows the scores of all the interesting moves, those that were best on previous iteration.
In the example, if the user used "Depth 28" for this box, the engine would finish up to depth 27 normally (would do it faster than in old behavior), at depth 28 (and beyond) the engine would be forced to give a score to all the moves of the previous iteration, and then the user gets to know what happened to those moves and was able to add them to their tree.
(Of course the 7th move in your list may not be the 7th best move... it might be the 30th best move. Why is it still interesting? Maybe in rare cases it is, but in general?)
In general the new ("new" as in, it replaced the old one, it's not new as it has been used for several years) behavior would just be like the old behavior but faster, as the top moves from previous iteration would be the same as in the last iteration.
But it causes slowdown to the user then they are not, as the user has to figure out the scores of those moves manually.
The Zappa Mexico II engine went over this, and would even show moves that would temporarily fail high to appear in MultiPV, though it had a check box to hide them. It was the best thing out there to look for interesting moves in a position, so that, often these moves that temporarily failed high but Zappa rejected later (so, with "Hide Fail Highs" on, the user wouldn't have ever known about them) turned out to be the best.
Unfortunately, Zappa is so weak by today's standards that those kind of moves are already found by top engines without interaction, so it is useless now, but moves hard to find that the engine is missing (say, the best move doesn't appear with MuliPV=4) are still common place, and getting a score for them if the engine had them on previous iteration saves time to the user.
The reason I'm not commenting on SinglePV is that SinglePV behavior is fine.
For a given position, that the user that has a tree of variations may do the following:
Extend the moves of the main variation (the one backsolved with the best score, so that this move is the best)
Look for alternative moves in the main variation (the user already has those if the positions were already examined with MultiPV)
Extend the moves of side variations (to check if they can beat the score of the main one, and become the new main variation)
Look for alternative moves in the side variation
Note this is recursive, each node has its own main variation and sidelines.
Extending sidelines is best done in SinglePV, since it's unlikely sidelines become mainlines, and you want to get deeper on them as fast as possible to examine others that might become new mainlines, so MultiPV is too costly on them, and using "go searchmoves" to look for alternatives on them is fine (you'd only do it when the main lines of the side lines fall down.) You don't care about what happened to moves of previous iterations because these lines are likely to not be important.
But whenever there's a side line you're overlooking that would become main line if you extended it, you want it to appear in your radar ASAP, this new behavior of MultiPV difficultes this because it limits the numer of side lines the user is able to add to the tree "for free" (without having to look for alternative moves in the variations, because they're already there for the complex positions where the engine discards and replaces the main moves of previous iterations, perhaps mistakenly.)