qsearch SEE pruning

[lucasart]

My qsearch prunes any SEE < 0, which on second thought can be dangerous. The point is that a capture may be losing, if you look only at the exchanges on the target squares, forget everything else on the board, and even the eventuality of checks, especially discovered ones.
Has anyone tried the following:
1/ prune if SEE < 0
2/ prune if SEE < 0, and the move is not a check
3/ prune if SEE < 0, and the move is not a discovered check
I'm currently testing 2/. Of course, it reduces the pruning, but my hope is that it's worth it by making the search more accurate

[lucasart]

my intuition of it is that:
* the qsearch chooses either the current eval (do not initiate captures), or a capture.
* but a capture will only beat the stand pat score when it gains something.
* most often it gains something only when its SEE > 0
* but sometimes, even with an SEE < 0 you can gain something in the context of the qsearch. and that's typically when the move is a check verifying one of two criterions:
(1) the move is a discovered check. in this case, even if the SEE < 0, it doesn't matter because the opponent cannot play the SEE sequence anyway. and in general he cannot even capture the piece (that would be hanging from an SEE point of view)
(2) the move is a check, and the piece is at least defended once. the point is that the SEE sequence can often contain other checks, so we don't want to trust it. also we don't want to not prune idiotic checks, ie just deliver check with a hanging undefended piece, as this is always a waste of time (when the check is not a discovered check)

I haven't tried it yet, but i wonder if anyone has, and with what success

[Ferdy]

My qsearch prunes any SEE < 0, which on second thought can be dangerous. The point is that a capture may be losing, if you look only at the exchanges on the target squares, forget everything else on the board, and even the eventuality of checks, especially discovered ones.
Has anyone tried the following:
1/ prune if SEE < 0
2/ prune if SEE < 0, and the move is not a check
3/ prune if SEE < 0, and the move is not a discovered check
I'm currently testing 2/. Of course, it reduces the pruning, but my hope is that it's worth it by making the search more accurate

I use (1) but with additional condition like the move should not be a hash_move. I have not tried (2) and (3), I will if I have the time.

I also generate non-capture-check moves if I can't improve original alpha. There could be relations to this.

[lucasart]

My qsearch prunes any SEE < 0, which on second thought can be dangerous. The point is that a capture may be losing, if you look only at the exchanges on the target squares, forget everything else on the board, and even the eventuality of checks, especially discovered ones.
Has anyone tried the following:
1/ prune if SEE < 0
2/ prune if SEE < 0, and the move is not a check
3/ prune if SEE < 0, and the move is not a discovered check
I'm currently testing 2/. Of course, it reduces the pruning, but my hope is that it's worth it by making the search more accurate

I use (1) but with additional condition like the move should not be a hash_move. I have not tried (2) and (3), I will if I have the time.

I also generate non-capture-check moves if I can't improve original alpha. There could be relations to this.

I also removed the hash_condition, because I think it doesn't make sense. I saw it in StockFish, so I put it there, but come to think of it, I'm not convinced at all. The point is that if you prune all SEE < 0, how would you ever get a hash move with SEE < 0 in your qsearch ? In fact you probably would, but it would mean the hash entry has been generated in the search not in the qsearch, so you'd be mixing apples and pears.

Anyway, I'm currently running a test with the following conditions:
1/ prune if SEE < 0 and the move is not a discovered check
2/ apply 1/ to the hash_move like any other, because if it has an SEE < 0 and is not a discovered check then it can't be have been generated by the qsearch, because of 1/

Fingers crossed, I hope it's at least as good as a careless SEE < 0 pruning.

[kbhearn]

perhaps a threshold lower than 0? an exchange 'sacrifice' in SEE removing a defender resulting in a win of two pieces for a rook in qsearch should be fairly common or even a beneficial exchange sacrifice for a pawn that alters king safety/pawn structure/etc evals enough to be an overall improvement.

[Ferdy]

My qsearch prunes any SEE < 0, which on second thought can be dangerous. The point is that a capture may be losing, if you look only at the exchanges on the target squares, forget everything else on the board, and even the eventuality of checks, especially discovered ones.
Has anyone tried the following:
1/ prune if SEE < 0
2/ prune if SEE < 0, and the move is not a check
3/ prune if SEE < 0, and the move is not a discovered check
I'm currently testing 2/. Of course, it reduces the pruning, but my hope is that it's worth it by making the search more accurate

I use (1) but with additional condition like the move should not be a hash_move. I have not tried (2) and (3), I will if I have the time.

I also generate non-capture-check moves if I can't improve original alpha. There could be relations to this.

I also removed the hash_condition, because I think it doesn't make sense. I saw it in StockFish, so I put it there, but come to think of it, I'm not convinced at all. The point is that if you prune all SEE < 0, how would you ever get a hash move with SEE < 0 in your qsearch ? In fact you probably would, but it would mean the hash entry has been generated in the search not in the qsearch, so you'd be mixing apples and pears.

Anyway, I'm currently running a test with the following conditions:
1/ prune if SEE < 0 and the move is not a discovered check
2/ apply 1/ to the hash_move like any other, because if it has an SEE < 0 and is not a discovered check then it can't be have been generated by the qsearch, because of 1/

Fingers crossed, I hope it's at least as good as a careless SEE < 0 pruning.

What I think, and what I feel I try to verify thru testing, you will never know how the engines behaves with so many different prunning, reduction, extensions implemented each with different conditions.

[lucasart]

perhaps a threshold lower than 0? an exchange 'sacrifice' in SEE removing a defender resulting in a win of two pieces for a rook in qsearch should be fairly common or even a beneficial exchange sacrifice for a pawn that alters king safety/pawn structure/etc evals enough to be an overall improvement.

That cound make sense. ALthough it may hurt, as in most cases, you don't get the positional compensation. The only way to find out is to implement and test it

[lucasart]

What I think, and what I feel, I try to verify through testing: you will never know how the engines behaves with so many different pruning, reduction, extensions implemented each with different conditions.

I completely agree, and do the same. One of the most striking examples I came across:
- recapture extensions. I tried implementing this feature in many different ways, and did a lot of testing, only to realise that it's either useless or harmful, no matter how you go about it (even if at PV nodes only, and using half ply extension and any such hocus-pocus heuristic nonsense)
- mate killer: again, it may help in particular positions, but overall it was proven to be perfectly useless

However, ideas first emerge by means of "intuition". And only *then* do you submit your intuition to empirical testing.

[Sven]

My qsearch prunes any SEE < 0, which on second thought can be dangerous. The point is that a capture may be losing, if you look only at the exchanges on the target squares, forget everything else on the board, and even the eventuality of checks, especially discovered ones.
Has anyone tried the following:
1/ prune if SEE < 0
2/ prune if SEE < 0, and the move is not a check
3/ prune if SEE < 0, and the move is not a discovered check
I'm currently testing 2/. Of course, it reduces the pruning, but my hope is that it's worth it by making the search more accurate

How can you know in advance whether a checking move with SEE < 0 will actually be good or "idiotic"? It would require some more intelligence to sort that out in advance, otherwise you end up in a couple of search explosions due to expanding a few silly "losing captures giving check". Whether the accuracy gain compensates the additional search effort (resp. additional intelligence to avoid it) or not is of course subject of testing, but intuitively I expect an overall loss in playing strength of your variant "2/".

Sven

[lucasart]

My qsearch prunes any SEE < 0, which on second thought can be dangerous. The point is that a capture may be losing, if you look only at the exchanges on the target squares, forget everything else on the board, and even the eventuality of checks, especially discovered ones.
Has anyone tried the following:
1/ prune if SEE < 0
2/ prune if SEE < 0, and the move is not a check
3/ prune if SEE < 0, and the move is not a discovered check
I'm currently testing 2/. Of course, it reduces the pruning, but my hope is that it's worth it by making the search more accurate

How can you know in advance whether a checking move with SEE < 0 will actually be good or "idiotic"? It would require some more intelligence to sort that out in advance, otherwise you end up in a couple of search explosions due to expanding a few silly "losing captures giving check". Whether the accuracy gain compensates the additional search effort (resp. additional intelligence to avoid it) or not is of course subject of testing, but intuitively I expect an overall loss in playing strength of your variant "2/".

Sven

I'm testing condition 3/
=> prune if SEE < 0, and move is not a discovered check.

* The overall cost is negligible (discovered checks are rare)
* In a position where there is indeed a discovered check, looking at the SEE is almost always stupid. So when you're looking at a discovered check, my heuristic is perfectly sound
* However, given how rare the nodes where the best move would be a SEE < 0 discovered check, I expect the improvement to be positive but quite negligible anyway.

The test is still running, and I have the following score: 153-139-131. So the gain is not yet statistically significant, but at least experience shows that it is not worse.

Another quick test I did: running an EPD file, and counting the total number of nodes. In the end, with the combined:
* pruning the hash move like any other (bug fix)
* do not prune SEE < 0 if discovered check (improvement?)
result in an slightly lower number of nodes. Again it's only 20 positions, and 20 other may give a different result, but at least it shows that I'm not exploding the search tree by doing this