Problems when implementing checks in qsearch

[michiguel]

It can be used to do a slightly safer type of pruning. If the evalution of a position is far below alpha, then instead of pruning the subtree completely, it is possible to just prune the quiet moves.
In this case only generate captures and checks. So in essence only try moves that potentially influence the evaluation of the position in a major way. Since these are the moves most likely to get the score above alpha.

Can you please explain how this differs from reducing more low scored nodes ?


Just to be more clear, if you reduce depth more you reach qsearch earlier and you have the same result but in an uniform and coherent way without adding yet another (redundant) trick.

If understood correctly, in your case, following plies are only captures/checks (qsearch) but in his case it is not since it is still in search.

Miguel

[mcostalba]

It can be used to do a slightly safer type of pruning. If the evalution of a position is far below alpha, then instead of pruning the subtree completely, it is possible to just prune the quiet moves.
In this case only generate captures and checks. So in essence only try moves that potentially influence the evaluation of the position in a major way. Since these are the moves most likely to get the score above alpha.

Can you please explain how this differs from reducing more low scored nodes ?


Just to be more clear, if you reduce depth more you reach qsearch earlier and you have the same result but in an uniform and coherent way without adding yet another (redundant) trick.

If understood correctly, in your case, following plies are only captures/checks (qsearch) but in his case it is not since it is still in search.

Miguel

What Jesper says, if I have understood correctly, it is just to fall in qsearch earlier for low scored nodes. This is something already done by many other ways, another example is razoring as is implemented in SF, where you fall in qsearch if score is very low.

If instead Jesper says that, say at depth 8 ply, if you are very low, you just try checks then at depth 7 and below you restart again with full non-captures generation, this is IMHO even more wrong. In this latter case LMR is the correct way to go because at such high depths static evaluation alone is not enough to understand what's going on after many plies.

[jesper_nielsen]

It can be used to do a slightly safer type of pruning. If the evalution of a position is far below alpha, then instead of pruning the subtree completely, it is possible to just prune the quiet moves.
In this case only generate captures and checks. So in essence only try moves that potentially influence the evaluation of the position in a major way. Since these are the moves most likely to get the score above alpha.

Can you please explain how this differs from reducing more low scored nodes ?


Just to be more clear, if you reduce depth more you reach qsearch earlier and you have the same result but in an uniform and coherent way without adding yet another (redundant) trick.

If understood correctly, in your case, following plies are only captures/checks (qsearch) but in his case it is not since it is still in search.

Miguel

What Jesper says, if I have understood correctly, it is just to fall in qsearch earlier for low scored nodes. This is something already done by many other ways, another example is razoring as is implemented in SF, where you fall in qsearch if score is very low.

If instead Jesper says that, say at depth 8 ply, if you are very low, you just try checks then at depth 7 and below you restart again with full non-captures generation, this is IMHO even more wrong. In this latter case LMR is the correct way to go because at such high depths static evaluation alone is not enough to understand what's going on after many plies.

What I am trying to say is that for positions that you would normally prune, then instead of pruning, you continue the search, but only generate "tactical" moves, where tactical moves are moves that are likely to have a significant impact on the evaluation. In my case, captures and checks.

Specifically in Pupsi:
In my implementation of "Futility pruning", "Extended futility pruning" and "Limited razoring" (as described by Heinz way back when), instead of returning alpha, when

Code: Select all

eval + margin < alpha

then continue the search with only "tactical" moves.

So it is kinda like having an extended q-search before the actual q-search, in cases where the position is unlikely to change the PV.

Searching these moves takes time, of course, so for engines that reach deep depths, the tactical security comes from the bigger depth reached. But for "surface" engines like mine it could help the tactical abilities.

It seems to help Pupsi ... YMMW!

Kind regards,
Jesper

This reminds me, that I could add another margin. One for complete pruning, and another for "pruning quiet moves".

[metax]

What I am trying to say is that for positions that you would normally prune, then instead of pruning, you continue the search, but only generate "tactical" moves, where tactical moves are moves that are likely to have a significant impact on the evaluation. In my case, captures and checks.

Specifically in Pupsi:
In my implementation of "Futility pruning", "Extended futility pruning" and "Limited razoring" (as described by Heinz way back when), instead of returning alpha, when

Code: Select all

eval + margin < alpha

then continue the search with only "tactical" moves.

So it is kinda like having an extended q-search before the actual q-search, in cases where the position is unlikely to change the PV.

Searching these moves takes time, of course, so for engines that reach deep depths, the tactical security comes from the bigger depth reached. But for "surface" engines like mine it could help the tactical abilities.

It seems to help Pupsi ... YMMW!

Kind regards,
Jesper

This reminds me, that I could add another margin. One for complete pruning, and another for "pruning quiet moves".

Isn't the standard form of Futility Pruning to search only tactical moves but not prune them? ChessMind does this...

[mjlef]

Another trick is that knights and bishops can only give check if they happen to be on squares of the same color as the king. So this trick tosses out half of the minor pieces from check move generation.