MVV/LVA sorting

[hgm]

If you sort by MVV/LVA, wouldn't it make sense to sort captures of unprotected pieces before others of a similar-valued victim, irrespective of attacker? E.g. if an unprotected Rook is attacked by Q, and a protected rook by B, try QxR before BxR?

[Evert]

It may not matter in practice. In that example QxR and BxR, R evade, B retreat both earn you a full rook...

[Daniel Shawul]

But how would you know if the rook is protected ? We use MVV/LVA to delay SEEing, so it will be expensive unless what you mean by protected is something easy to detect like supported by a pawn.

[bob]

If you sort by MVV/LVA, wouldn't it make sense to sort captures of unprotected pieces before others of a similar-valued victim, irrespective of attacker? E.g. if an unprotected Rook is attacked by Q, and a protected rook by B, try QxR before BxR?

I think the point is supposed to be to remove the most valuable piece first, period. Which reduces the material on the board and the size of the sub-tree below that node. So long as that is followed, your idea might be a tiny improvement overall. But from testing when this came up previously, it is better to play QxR where the rook is protected, rather than RxB or RxP where the B or P is hanging... You will still get to capture those after the forced opponent recap...

[hgm]

But how would you know if the rook is protected ? We use MVV/LVA to delay SEEing, so it will be expensive unless what you mean by protected is something easy to detect like supported by a pawn.

OK, that is a good point. Normally one does MVV/LVA in cases where such info is not available. But most strong engines would subject higher-takes-lower to SEE, in order to postpone or even prune those with not-so-good or negative SEE. So when judging the Q x unprotected R you would get SEE = +5. But it might not subject the B x protected R to SEE, as this is an 'obviously winning' capture. And it probably would try these before SEEing QxR due to LVA, as B < Q. The QxR SEE could tell you if the R is protected, for practically free. But the price is that you would have to perform the SEE of it before searching B x R, which wastes time if B x R would already have been the cut move.

The reason I got this idea is that I am working on an engine that generates captures from an attack map. So it will in general be aware if a piece is protected.

You are right that both captures eventually gain a Rook in the example. But the capture of an unprotected Rook would in general see that with a less-deep search. ( Q x R, stand-pat in stead of B x R, P x B, Q x R, stand-pat.) I don't expect miracles of this, but as people nowaays are hunting for 1-Elo improvements, there might be something value in this. OTOH, it could easily backfire, because a capturer that survives the next ply can have many new captures from its new location, which could increase tree size if the opponent starts to play silly replies.

[jdart]

My engine, and I think quite a few others, does MVV/LVA for sorting first, then as the moves are actually tried does SEE on them. The moves that generate a negative SEE go to a "losers" list and will be tried last in the move order.

This reduces the number of calls to SEE over an approach that does SEE on all moves then sorts, before trying any moves, because in many cases the first one or two capture moves will cause cutoff.

--Jon

[hgm]

Indeed, that is the logical way to do it. And on Low x High and Equal x Equal captures you don't even have to run a SEE, as they cannot have a negative outcome.

But you can use this strategy only to postpone moves. To check if moves should be sorted in front you cannot avoid looking ahead. But for what I propose it is only needed to test if a victim is protected, not a full SEE. And you don't have to do it on every move, but just on every victim. So if you encounter two victims of the same value (which is already rare), you would have to check if the 'other' one (which you would not normally try to capture first, e.g. because the lowest attacker is worth more than the lowest attacker of the other). Then, if it turns out to be not protected, you could sort all captures of it before the captures of the protected one, without the need to run SEE on them.

So the investment does not seem terribly large.