Request for thoughts: SEE "Test Set"

[JVMerlino]

Thank you all for this discussion, and mostly for lithander for the test positions. I wasn't even halfway through the list when I discovered two bugs in my SEE implementation:
1) Captures by Kings were not included, and
2) If the first capture was of equal value, the calculation stopped and returned 0.

I wonder how much elo this will give? I'm guessing.....two?

Thank you!

Turns out it appears to have given 6 elo. Huzzah! Thanks again!

[lithander]

Turns out it appears to have given 6 elo. Huzzah! Thanks again!

Wow that's nice!

Since my SEE implementation passed all tests I've been trying to use it to sort captures instead of using MvvLva but it didn't result in a stronger engine. I also tried pruning losing captures (based on the SEE result) in Qsearch or reducing them in normal search. All to no avail. Maybe I need to use longer time controls so that the theoretically thinner tree can start to outweigh the flat cost of computing SEE.

[JVMerlino]

Turns out it appears to have given 6 elo. Huzzah! Thanks again!

Wow that's nice!

Since my SEE implementation passed all tests I've been trying to use it to sort captures instead of using MvvLva but it didn't result in a stronger engine. I also tried pruning losing captures (based on the SEE result) in Qsearch or reducing them in normal search. All to no avail. Maybe I need to use longer time controls so that the theoretically thinner tree can start to outweigh the flat cost of computing SEE.

Yes, MVV-LVA seems just as good as SEE in Myrddin for move ordering. But I do use SEE in QS and now also to determine if a capture is subject to LMR (captures with SEE > 0 are not).

[hgm]

Sorting by SEE can be expected to be worse than sorting MVV/LVA. SEE should only be applied to postpone or prune H x L captures. R x R should always be tried before P x B, even if the R is protected. The Bishop usually won't go away. This is different for moves like Q x R, which you might not want to play at all.

[Joost Buijs]

Sorting by SEE can be expected to be worse than sorting MVV/LVA. SEE should only be applied to postpone or prune H x L captures. R x R should always be tried before P x B, even if the R is protected. The Bishop usually won't go away. This is different for moves like Q x R, which you might not want to play at all.

I don't see any reason why sorting by SEE would be worse than sorting by MVV/LVA. Nightmare uses sorting by SEE in quiescence, I never got better results with MVV/LVA. You might argue that SEE is slower, but with a good implementation the speed penalty is negligible. Especially when you start using neural nets for evaluation the extra time taken by SEE vs MVV/LVA is hardly noticeable.

[hgm]

It is not a matter of speed, but of optimal move ordering. In most positions where you have to choose between R x protected R and P x B the R x R is the move with the best score and the smaller sub-tree. Often P x B will fail low (when you are dealing with unprotected R x R).

And the comparison is not between pure MVV/LVA and SEE, but between pure SEE and MVV/LVA with SEE-reordered H x L.

[Joost Buijs]

It is not a matter of speed, but of optimal move ordering. In most positions where you have to choose between R x protected R and P x B the R x R is the move with the best score and the smaller sub-tree. Often P x B will fail low (when you are dealing with unprotected R x R).

And the comparison is not between pure MVV/LVA and SEE, but between pure SEE and MVV/LVA with SEE-reordered H x L.

I don't know what MVV/LVA with SEE-reordered H x L is, probably you mean High x Low. Usually I do what gives me the highest performance in engine/engine matches. My See uses L x H ordering, of course there are cases that this isn't optimal, but problems with pinned and overloaded pieces are much worse and these are not solved by MVV/LVA either.

In the end the order of captures in quiescence seems not to be very important, the evaluation function is way more important, if you really want to improve your engines strength, you'd better spend your time on improving the evaluation function.

[hgm]

Well, the latter is a bit off-topic here.

Of course SEE uses Lowest-first ordering for everything except the capture to be scored. That is the definition of SEE, right? Low x High or High x Low is not an ordering, but a single (capture) move. So the SEE is used to reorder the captures where a more valuable piece captures a lower one, the SEE value replacing the victim value as the sort key.

[Joost Buijs]

Well, the latter is a bit off-topic here.

Of course SEE uses Lowest-first ordering for everything except the capture to be scored. That is the definition of SEE, right? Low x High or High x Low is not an ordering, but a single (capture) move. So the SEE is used to reorder the captures where a more valuable piece captures a lower one, the SEE value replacing the victim value as the sort key.

This is exactly what I do, I score the moves with the SEE value and sort them high to low and use this move order in quiescence.

B.T.W. I want to end this discussion, the forum software is so bad, each time I'm logged of after 30 seconds or so, and then my message is gone. I have to logon again, and use the back button in my browser to get the message back, this makes it very inconvenient. I hope one day they will fix this.

[hgm]

What you describe is not at all the same as what I described. You order all moves by SEE (key = SEE). Consensus for what is best is key = (value[victim] < value[attacker] ? SEE : value[victim] - value[attacker]/16.).