qsearch SEE pruning

[Desperado]

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

Hi Lucas,

the distinction i currently use is...

Quiescense PV:

* dont prun SEE < 0
* checks (non captures) are pruned if SEE < 0
* no prunings on evasions

Quiescense:

* prun SEE < 0
* checks (non captures) are pruned if SEE < 0
* no prunings on evasions

A while i played around to set an additional depth condition, let us say
from depth -2 on, which can be another idea. (not only for negative SEE but also
for delta pruning as example or other pruning techniques in qsearch).

So far, for me the most valuable distinction was the pv/evasion/nullwindow one.

Side note:
============

Making a differentiation seems logical to me because captures (also in normal search)
are most often part of forced lines. Having a closer look on my lmr code which pruns
more aggressively on the really late moves (negative SEE captures are mainly at the end of
my movelists) turned out to be a matter of correction. So reducing/pruning negative SEE
captures should be more softend than quite moves, which is my current impression.
And the "forced nature" of this move category needs more distinction within this move class.


regards,

Michael

[bob]

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

Are you doing checks and discovered checks in the q-search? One layer of checks to deal with null-move oversights is a good thing. Doing more is questionable. Particularly as on any ply where there is no check, either side can "stand pat" making it impossible to find forced mates and such...

[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

Hi Lucas,

the distinction i currently use is...

Quiescense PV:

* dont prun SEE < 0
* checks (non captures) are pruned if SEE < 0
* no prunings on evasions

Quiescense:

* prun SEE < 0
* checks (non captures) are pruned if SEE < 0
* no prunings on evasions

A while i played around to set an additional depth condition, let us say
from depth -2 on, which can be another idea. (not only for negative SEE but also
for delta pruning as example or other pruning techniques in qsearch).

So far, for me the most valuable distinction was the pv/evasion/nullwindow one.

Side note:
============

Making a differentiation seems logical to me because captures (also in normal search)
are most often part of forced lines. Having a closer look on my lmr code which pruns
more aggressively on the really late moves (negative SEE captures are mainly at the end of
my movelists) turned out to be a matter of correction. So reducing/pruning negative SEE
captures should be more softend than quite moves, which is my current impression.
And the "forced nature" of this move category needs more distinction within this move class.


regards,

Michael

Have you tried removing the PV / non PV distinction ? In my program, I removed thie PV condition on SEE pruning and got equal results.

Generally, I've never been a great believer of treating PV and non PV nodes differently.

[Desperado]

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

Hi Lucas,

the distinction i currently use is...

Quiescense PV:

* dont prun SEE < 0
* checks (non captures) are pruned if SEE < 0
* no prunings on evasions

Quiescense:

* prun SEE < 0
* checks (non captures) are pruned if SEE < 0
* no prunings on evasions

A while i played around to set an additional depth condition, let us say
from depth -2 on, which can be another idea. (not only for negative SEE but also
for delta pruning as example or other pruning techniques in qsearch).

So far, for me the most valuable distinction was the pv/evasion/nullwindow one.

Side note:
============

Making a differentiation seems logical to me because captures (also in normal search)
are most often part of forced lines. Having a closer look on my lmr code which pruns
more aggressively on the really late moves (negative SEE captures are mainly at the end of
my movelists) turned out to be a matter of correction. So reducing/pruning negative SEE
captures should be more softend than quite moves, which is my current impression.
And the "forced nature" of this move category needs more distinction within this move class.


regards,

Michael

Have you tried removing the PV / non PV distinction ? In my program, I removed thie PV condition on SEE pruning and got equal results.

Generally, I've never been a great believer of treating PV and non PV nodes differently.

Yes, i tried to handle pv/nonPv the same way, which did hurt in my case _clearly_. But it is a while back, and my engine changed a lot. So i may
test it again at some point.

[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

Are you doing checks and discovered checks in the q-search? One layer of checks to deal with null-move oversights is a good thing. Doing more is questionable. Particularly as on any ply where there is no check, either side can "stand pat" making it impossible to find forced mates and such...

Perhaps there's a misunderstanding about the terminology. When I talk about "checks", those can be the result of the capture/promotion, as well as from a quiet move. The moves that I generate are as follows:

depth = 0: direct quiet checks by pieces(*) + captures/promotions (that can also deliver check)
depth < 0: captures/promotions only

(*) I was too lazy to generate all the checks, especially by pawns, with discovered checks, let alone the en passant and caslting

[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

My test is finished, and concluded positively. Nothing earth shattering, but the improvement is statistically significant.

[Ferdy]

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.

I still have recapture and mate killer extensions, since the last 7 years, I have not tried to revisit and re-tune those. What I am interested now is something that is not yet implemented in mine, and there are a lot to be tried.

BTW I am testing the bad see prunning except if move generates discovered check. It looks pretty good after 200 games so far at TC 40moves/30sec. If this will hold at this TC, next I will use TC 40moves/3min. Well even if this would lose an elo of 5 at short TC I still try to test this in longer TC since this technique improves accuracy to already inaccurate SEE.

[bob]

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

Are you doing checks and discovered checks in the q-search? One layer of checks to deal with null-move oversights is a good thing. Doing more is questionable. Particularly as on any ply where there is no check, either side can "stand pat" making it impossible to find forced mates and such...

Perhaps there's a misunderstanding about the terminology. When I talk about "checks", those can be the result of the capture/promotion, as well as from a quiet move. The moves that I generate are as follows:

depth = 0: direct quiet checks by pieces(*) + captures/promotions (that can also deliver check)
depth < 0: captures/promotions only

(*) I was too lazy to generate all the checks, especially by pawns, with discovered checks, let alone the en passant and caslting

If you don't do anything special about checks (in the q-search), why the SEE restriction at all???

[Ferdy]

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.

I still have recapture and mate killer extensions, since the last 7 years, I have not tried to revisit and re-tune those. What I am interested now is something that is not yet implemented in mine, and there are a lot to be tried.

BTW I am testing the bad see prunning except if move generates discovered check. It looks pretty good after 200 games so far at TC 40moves/30sec. If this will hold at this TC, next I will use TC 40moves/3min. Well even if this would lose an elo of 5 at short TC I still try to test this in longer TC since this technique improves accuracy to already inaccurate SEE.

After 500+ games of test I aborted and concluded that it does not add up elo. There could be a possibility that I need some conditions for this to work, I don't have time to dig deeper and study in details at this time, but I will come back to it. I will go ahead and test other techniques instead.

[Evert]

- mate killer: again, it may help in particular positions, but overall it was proven to be perfectly useless

In terms of playing strength, I presume. That's not really surprising because it only helps in positions where you have mate-threats, which probably occur most often if you are in a better (winning) position anyway: it doesn't change the outcome of the game, it just gets you there faster. Testing for playing strength is not going to reveal that.
As a feature, it'll probably more useful as an analysis feature, and that could be an argument to keep it (in fact, might be an argument to add it).