QSearch, checks and the lack of progress...

[Mincho Georgiev]

Hello!
I've been struggling with searching checks at qnodes for about 10 days now to determine any gain.
No joy. I've tried it with my programs as well as couple of written by others.
I had tried everything that comes in mind like:
- searching all checks after caps/proms.
- the above, including hashing in nodes that allow check search.
- different restrictive conditions - 1st qply, two qplys, 3, e.t.c., restricting by qnode counts with combination with the previous.
- I don't do it if the current position is in check - evasions search then
instead.
- Also, tried not to generate every checks, but only the discovery ones.
I'm sure I don't have any problem with the generation, because I had used my own debugging framework to determine
if there are any bugs, plus (as I said) I did it with other programs too with their own generators.
My request is if anyone have experience with elo gain related to this, please share.
Thanks!

[zamar]

SF searches only checks in qsearch (depth >= -1) if it looks likely that it can win material that way.

Condition:

SEE(pieceX checks) == 0 && // Checking piece cannot be immediately captured
SEE(pieceX checks, king moves, pieceX captures opponent's piece) >= 0 // Checking piece forks undefended piece

[Mincho Georgiev]

Thanks, Joona! It sounds interesting, I may give it a try. Any chance of remembering for any gain during tests, if you excuse my insolence.

[zamar]

Thanks, Joona! It sounds interesting, I may give it a try. Any chance of remembering for any gain during tests, if you excuse my insolence.

not a big deal. maybe ~5elo

[dchoman]

Hello!
I've been struggling with searching checks at qnodes for about 10 days now to determine any gain.
No joy. I've tried it with my programs as well as couple of written by others.
I had tried everything that comes in mind like:
- searching all checks after caps/proms.
- the above, including hashing in nodes that allow check search.
- different restrictive conditions - 1st qply, two qplys, 3, e.t.c., restricting by qnode counts with combination with the previous.
- I don't do it if the current position is in check - evasions search then
instead.
- Also, tried not to generate every checks, but only the discovery ones.
I'm sure I don't have any problem with the generation, because I had used my own debugging framework to determine
if there are any bugs, plus (as I said) I did it with other programs too with their own generators.
My request is if anyone have experience with elo gain related to this, please share.
Thanks!

I had a similar experience with trying to put checks in to qsearch of EXchess... no elo improvement under a variety of conditions and a clear loss under most of them. Until I had the idea to use the king safety evaluation to set a flag for the qsearch. So if my eval determines the king might be at risk, it allows checks to be generated. That was a clear improvement, don't recall how much.. not large, I think, but measurable, which for my testing setup is ~ 10 elo. This is only done in the first ply of the qsearch.

I later discovered that there was also some benefit to doing checks if the previous move was the single reply to a check, but only in the first 3 ply of qsearch. As I recall, this one was more questionable (probably didn't rise to +10 elo), but I kept it because I liked it.

Should probably re-test both again when I get the time.

- Dan

[lucasart]

Thanks, Joona! It sounds interesting, I may give it a try. Any chance of remembering for any gain during tests, if you excuse my insolence.

Here's what I do, it might be easier to implement, and testing gave my a measurable improvement
* generate quiet checks at depth == 0 (along with captures and queen promotions)
* genrate all captures and queen promotions at any QS depth < 0
* discovered checks are not pruned, because the SEE doesn't mean anything for a move like that (and they too often create complications on the board to be pruned carelessly)
* other checks are pruned just like any other move (capture or promotion) if the SEE < 0. typically those are stupid moves where the queen crashed in front of the king with no defenders etc. (but not always, as usual it misses some strong tactics in rare cases)

Actually the conditions in Stockfish are a little more complicated than what Joona describes. Best thing is to look at the source code.

PS: If you treat differently depth = 0 and depth < 0, make sure in the hash table entries you enter depth = 0 and depth = -1, and not depth when saving an entry. And if you decide to do checks down to depth = -2 for example, same story, use depth = 0, -1, -2, and -3 for all below depths etc.
This is a common mistake to make: for example you didn't have checks before in QS, and now you do it at depth 0 but forget to modify the hash table mechanism. I fell into that trap at the beginning

[lucasart]

Until I had the idea to use the king safety evaluation to set a flag for the qsearch. So if my eval determines the king might be at risk, it allows checks to be generated. That was a clear improvement, don't recall how much.. not large, I think, but measurable, which for my testing setup is ~ 10 elo. This is only done in the first ply of the qsearch.

That's a very interesting idea. I'll put it on my to do list.

[Mincho Georgiev]

Thanks, Joona! It sounds interesting, I may give it a try. Any chance of remembering for any gain during tests, if you excuse my insolence.

Here's what I do, it might be easier to implement, and testing gave my a measurable improvement
* generate quiet checks at depth == 0 (along with captures and queen promotions)
* genrate all captures and queen promotions at any QS depth < 0
* discovered checks are not pruned, because the SEE doesn't mean anything for a move like that (and they too often create complications on the board to be pruned carelessly)
* other checks are pruned just like any other move (capture or promotion) if the SEE < 0. typically those are stupid moves where the queen crashed in front of the king with no defenders etc. (but not always, as usual it misses some strong tactics in rare cases)

Actually the conditions in Stockfish are a little more complicated than what Joona describes. Best thing is to look at the source code.

PS: If you treat differently depth = 0 and depth < 0, make sure in the hash table entries you enter depth = 0 and depth = -1, and not depth when saving an entry. And if you decide to do checks down to depth = -2 for example, same story, use depth = 0, -1, -2, and -3 for all below depths etc.
This is a common mistake to make: for example you didn't have checks before in QS, and now you do it at depth 0 but forget to modify the hash table mechanism. I fell into that trap at the beginning

I'm doing all of the above already, because I'm considering only non-capturing, non-promotive, non-evasive checks. I mean, all of the checks generation gets done after the position might be considered as a "quiet" one, after the possible captures and promotion are searched and still - no cut-off occurs. Here is the logic behind my qsearch code, part of which might be the very reason for this not to work currently:

1. if I'm in check - generate and search the evasions.
2. if I'm not - generate and search captures and promotions.
3. if captures and promotions are searched and no move raises value above beta - this might be a "quiet" position, but to make sure - generate
and search checks to see if there is a danger showed on the next ply /which is often because of a fork, double check, discovery check and so on/. Restrict the last one to avoid a search tree explosions.

Basically that's it. Daniel's idea sounds interesting and I may try it.
I'm considering also to try the attacking influence of the pieces like that:
if one of the moved piece's attacked squares after the move (on TO) is occupied with a piece of higher value than the moved one, only then search the initial move of that piece /regardless of whether is double or disc. check/ - fork. It is like a preliminary SEE - swabbing of the next ply squares. Just an idea...

[Mincho Georgiev]

Forgot to mention, regarding hashing at qnodes. I'm doing it with signed depths - no problem there. The problem is that hashing at qnodes don't work for me and that's it. What's new is now trying to store and probe only on qnodes that allows check searches. Don't work again either, it's still better with doing the same with no hashing.