Move Sorting and Checks

[hgm]

Has anyone tried sorting non-capture checks in the back, e.g. after other non-captures, and before bad captures? Because of the check extension, checks are rather expensive moves, and if you could acheive a cutoff by another move that would be highly preferable. Perhaps so much, that it would pay to search all other moves first, ven if the checking move is 90% likely to be a cut move.

Perhaps giving checks should even be penalized core-wise, by subtracting a few score points for each move that checks, when you backup the scoe towards the root. Checks can be considered a resource, and if you have the choice between two paths, which in your multi-PV would eventualy rach the same position, (and thus in pure minimax would get identical score), but one would start wit a check, and the other not, it seems the one that does not start with the check should be preferred. Because then you keep the check "up your sleeve", which makes it more likely that you can do something profiabe with it, on deeper search. Once you have used it, you cannot use it again.

So perhaps giving checks should be penalized more close to the root than deeper in the tree, so that it postpones them as long a possible. Based on the assumption that the likelihood that a sidebranch from a position where you can check will shoot up in score on deeper search is larger than that the sidebranch from a position where you cannot check will do that.

[bob]

Has anyone tried sorting non-capture checks in the back, e.g. after other non-captures, and before bad captures? Because of the check extension, checks are rather expensive moves, and if you could acheive a cutoff by another move that would be highly preferable. Perhaps so much, that it would pay to search all other moves first, ven if the checking move is 90% likely to be a cut move.

Perhaps giving checks should even be penalized core-wise, by subtracting a few score points for each move that checks, when you backup the scoe towards the root. Checks can be considered a resource, and if you have the choice between two paths, which in your multi-PV would eventualy rach the same position, (and thus in pure minimax would get identical score), but one would start wit a check, and the other not, it seems the one that does not start with the check should be preferred. Because then you keep the check "up your sleeve", which makes it more likely that you can do something profiabe with it, on deeper search. Once you have used it, you cannot use it again.

So perhaps giving checks should be penalized more close to the root than deeper in the tree, so that it postpones them as long a possible. Based on the assumption that the likelihood that a sidebranch from a position where you can check will shoot up in score on deeper search is larger than that the sidebranch from a position where you cannot check will do that.

This is yet another incarnation of the idea behind ETC and such algorithms. The fact that to get a cutoff, you don't necessarily want to find the _best_ move. You want to search a move that is good enough to cause a cutoff while requiring the least effort possible. I don't order checks in any way, but could probably move 'em to the bottom to see what happens. It would certainly hurt tactical tests which I don't care about.