SEEN

[Henk]

I don't see any good in using SEE in my engine. It is unreliable, it causes misevaluations and it is slow.

For instance it doesn't see pins for pin detection is too expensive, double checks and sacrifices.

How can it ever work for it focuses mainly on one square. Maybe if you have an hyper fast implementation and it enables you to search deeper which compensates the errors it might have generated.

If you have a slow implementation of SEE you can only use it somewhere above the leaves but there it is useless for SEE does not see enough.

[kbhearn]

I don't think SEE is supposed to be accurate, just a heuristic that is right most of the time. a move with SEE < 0 is probably going to be bad, often ridiculously so (i would guess 99%+ of the time) and a good candidate for reduction (which would be undone with re-search if the line turns promising) or for ignoring in quiescent search or for bumping down the move order if nothing else.

You could probably catch many of the more common exceptions as well if you were really interested but largely it's going to be low depth 'aha' moments, that even the reduced search is likely to catch. Things like a pinned piece not being able to recapture or removal of a defender leading to a net material winning sequence are likely to show up even if all that happens after it is a quiescent search, thus triggering the re-search.

[Henk]

Maybe it is useful for quiescence search if it is fast enough. But I think reducing bad captures is too dangerous for it can be good sacrifices. Or you can use it near the leaves for the engine would not recognize a good sacrifice at these depths anyway

I can use SEE only at depth > 1 otherwise it slows down search. So maybe I can use it only at depth 2 for recognizing bad captures. But then it still will generate errors because it doesn't detect pins and double checks.

[cdani]

But then it still will generate errors because it doesn't detect pins and double checks.

Sure you can live with this. It does not happen very often.
I rewroted SEE a lot of times, and I use many tricks to speed it. Just keep going

[Joost Buijs]

Maybe it is useful for quiescence search if it is fast enough. But I think reducing bad captures is too dangerous for it can be good sacrifices. Or you can use it near the leaves for the engine would not recognize a good sacrifice at these depth.

I use SEE everywhere also in quiescence, it consumes some time but not very much.
It is not difficult or time consuming to take absolute pins into consideration.
Of course SEE will make some mistakes but a mini-max search seems to be very resistant to a few errors here and there.
A search with all kinds of pruning going on is a bag of errors anyway.

Maybe in your case that CLR stuff is the culprit, it kills performance.

[hgm]

My newer engines also do not use SEE. For one, optimal move ordering in QS is mainly MVV/LVA, and SEE is only a second resort in the case of Higher x Lower captures. But in the overwhelming number of cases it only has to distinguish between an unprotected victim and a protected one.

So instead of SEE, I use BLIND, which only tries captures of pieces in MVV/LVA order that are Better (or equal) than the attacker, or Lesser If Not Defended. The other captures are postponed or pruned.

[bob]

My newer engines also do not use SEE. For one, optimal move ordering in QS is mainly MVV/LVA, and SEE is only a second resort in the case of Higher x Lower captures. But in the overwhelming number of cases it only has to distinguish between an unprotected victim and a protected one.

So instead of SEE, I use BLIND, which only tries captures of pieces in MVV/LVA order that are Better (or equal) than the attacker, or Lesser If Not Defended. The other captures are postponed or pruned.

Ever thought of writing a MUTE function that returns nothing at all?

Or perhaps a DEAF function that takes no arguments and uses no global data.

[Sven]

Maybe it is useful for quiescence search if it is fast enough. But I think reducing bad captures is too dangerous for it can be good sacrifices. Or you can use it near the leaves for the engine would not recognize a good sacrifice at these depths anyway

I can use SEE only at depth > 1 otherwise it slows down search. So maybe I can use it only at depth 2 for recognizing bad captures. But then it still will generate errors because it doesn't detect pins and double checks.

When using SEE in quiescence search, do you call the SEE function for all captures, or just for all "higher takes lower" ones? The latter would be a lot faster, of course. You don't need to call SEE for "good captures".

If you already do so but your SEE still performs badly in quiescence search then go and fix it, there are certainly ways to have a very fast SEE implementation. I guess you already checked the chessprogramming wiki on that topic, the recursive algorithm shown there, or an iterative equivalent of it, should be good enough in most cases. The part with the biggest runtime cost is usually the detection of all attackers of the target square.

[Henk]

My newer engines also do not use SEE. For one, optimal move ordering in QS is mainly MVV/LVA, and SEE is only a second resort in the case of Higher x Lower captures. But in the overwhelming number of cases it only has to distinguish between an unprotected victim and a protected one.

So instead of SEE, I use BLIND, which only tries captures of pieces in MVV/LVA order that are Better (or equal) than the attacker, or Lesser If Not Defended. The other captures are postponed or pruned.

Ever thought of writing a MUTE function that returns nothing at all?

Or perhaps a DEAF function that takes no arguments and uses no global data.

Or which bugs make your engine play better.

I remember I fixed a bug in my transposition table one year ago that cost me about 100 elo. So performance dropped severely. I fixed it to keep my code transparent and free from bugs.

But what is the difference with SEE and all these other so called heuristics that generate many misevaluations. If I would be consistent I would leave them out.

[bob]

My newer engines also do not use SEE. For one, optimal move ordering in QS is mainly MVV/LVA, and SEE is only a second resort in the case of Higher x Lower captures. But in the overwhelming number of cases it only has to distinguish between an unprotected victim and a protected one.

So instead of SEE, I use BLIND, which only tries captures of pieces in MVV/LVA order that are Better (or equal) than the attacker, or Lesser If Not Defended. The other captures are postponed or pruned.

Ever thought of writing a MUTE function that returns nothing at all?

Or perhaps a DEAF function that takes no arguments and uses no global data.

Or which bugs make your engine play better.

I remember I fixed a bug in my transposition table one year ago that cost me about 100 elo. So performance dropped severely. I fixed it to keep my code transparent and free from bugs.

But what is the difference with SEE and all these other so called heuristics that generate many misevaluations. If I would be consistent I would leave them out.

Every extension is a potential failure. Every reduction, ditto. Every forward pruning decision, ditto. Qsearch is riddled with errors because it will stand pat or search captures, but in most positions a capture is not the best move. There is so much error scattered throughout a search... See is highly accurate, and as always you have a choice to make, 95% correct, or don't do it and turn it into a guess.