Starting with check extensions.

[Luis Babboni]

Hi people!

I´ll bother you again with some, maybe stupid, questions.

First I´ll try to be sure about what the idea is in check extensions.

Actually Soberango, after ended the full width search at depth p, calls the move generator again but take as valid just the captures and promotions moves at depth p+1, then the same at depth p+2 and so on till there is no more captures or promotions. This si what I understand is quiscence search.

Now I understand that to do check extensions, I need to add to those captures and promotions that the move generator take as valid at depth p+1, checks, i.e. moves that put the opponent side on move king under check. I´m right till here?

But for depth p+2, the moves generator must take as valid not just captures, promotions and moves that put the opponent side on move king in check.... it neeeds to see if the king of the side to move is in check and in this case just take as valid only moves that made this king evade the check the other side made. I´m right?

Note: till now, even in full width search as in QS, Soberango never see if one move put the opponent side in check. Just, in the following depth, try all possible moves the moves generator made and discard those that let the side to move king in check. Could be correct do it this way or it must check it?

Thanks in advance for all comments that you could do trying to help me.

[Daniel Anulliero]

If I understand correctly , you're doing checks extension at p+1 ,p+2 etc ... In other word , in qs ? ok but if you find a check move in it , you can't see the check evasion if you générate only captures and promo.
In my chess engine I check for checks extensions only in alpha beta search , at every depth and before entering in qs : in other word , I do the test :

Code: Select all

If (incheck)
        ++depth;

Before the test :

Code: Select all

if (depth <= 0)
         return qs ( );

You can do checks in qs but I think it's not a true extension , it just décide to run your
gen_all_moves ( ) function instead of running your gen_captures_promos ( ) function.

I have checks in qs again on my to do list

[Sven]

Actually Soberango, after ended the full width search at depth p, calls the move generator again but take as valid just the captures and promotions moves at depth p+1, then the same at depth p+2 and so on till there is no more captures or promotions. This si what I understand is quiscence search.

Now I understand that to do check extensions, I need to add to those captures and promotions that the move generator take as valid at depth p+1, checks, i.e. moves that put the opponent side on move king under check. I´m right till here?

What you describe here is usually called "checks in QS". It adds quiet (non-capturing, non-promoting) checks to the set of moves being searched in QS, if none of the captures or promotions caused a cutoff. You can do that but you should limit this to the first N plies from the QS root (and most people use N=1 so they only add "quiet checks" at horizon nodes). Otherwise it will most probably cause a search explosion.

But for depth p+2, the moves generator must take as valid not just captures, promotions and moves that put the opponent side on move king in check.... it neeeds to see if the king of the side to move is in check and in this case just take as valid only moves that made this king evade the check the other side made. I´m right?

Yes, of course. Additionally considering quiet checks would not make sense without searching all legal replies to check.

But you want to do "check extension" and that is different from "checks in QS". It simply means that you search one ply deeper (in full-width search) if the moving side is in check. One obvious benefit is that you never drop into QS when the moving side is currently in check so that you no longer miss a mate-in-N (or mated-in-N) in iteration N (unless you have a special mate detection method that is applied at horizon nodes, which is unlikely). The more general advantage is that it slightly improves the tactical awareness of the engine by analyzing some "forced" lines (those where giving check is involved) somewhat deeper.

A simple implementation would test for being in check right before testing the "remaining depth == 0" condition that would delegate to QS, and would increment the remaining depth by 1 if the king of the moving side is in check.

Note: till now, even in full width search as in QS, Soberango never see if one move put the opponent side in check. Just, in the following depth, try all possible moves the moves generator made and discard those that let the side to move king in check. Could be correct do it this way or it must check it?

You do not get check extensions for free. The price you pay is to test for being in check at each full-width node. This will usually cause a slowdown but you get back a strength improvement so don't worry too much about it.

Check extensions are also possible in QS. Here you perform a full-width search to depth 1 instead of a regular QS if a move puts the enemy king into check.

[Luis Babboni]

Thanks guys!

As I said:

....
First I´ll try to be sure about what the idea is in check extensions.
...

And seems my idea about it was wrong!
Time to work..... and do sooner or later more questions!

[flok]

What you describe here is usually called "checks in QS". It adds quiet (non-capturing, non-promoting) checks to the set of moves being searched in QS, if none of the captures or promotions caused a cutoff. You can do that but you should limit this to the first N plies from the QS root (and most people use N=1 so they only add "quiet checks" at horizon nodes). Otherwise it will most probably cause a search explosion.

!!!

wow!
I did not have that limit in my code. Did a quick test (8k games) and I see a 23 elo improvement!
Wow!

[MahmoudUthman]

What you describe here is usually called "checks in QS". It adds quiet (non-capturing, non-promoting) checks to the set of moves being searched in QS, if none of the captures or promotions caused a cutoff. You can do that but you should limit this to the first N plies from the QS root (and most people use N=1 so they only add "quiet checks" at horizon nodes). Otherwise it will most probably cause a search explosion.

If I understand this right , then why do they do this instead of checking for and extending checks before descending in QS , isn't this the same or even better ?

[AlvaroBegue]

What you describe here is usually called "checks in QS". It adds quiet (non-capturing, non-promoting) checks to the set of moves being searched in QS, if none of the captures or promotions caused a cutoff. You can do that but you should limit this to the first N plies from the QS root (and most people use N=1 so they only add "quiet checks" at horizon nodes). Otherwise it will most probably cause a search explosion.

If I understand this right , then why do they do this instead of checking for and extending checks before descending in QS , isn't this the same or even better ?

*That* is what people call check extensions. It's certainly not the same, and whether it's better or not depends on many details of your engine. So try it and see, as usual.

[cdani]

What you describe here is usually called "checks in QS". It adds quiet (non-capturing, non-promoting) checks to the set of moves being searched in QS, if none of the captures or promotions caused a cutoff. You can do that but you should limit this to the first N plies from the QS root (and most people use N=1 so they only add "quiet checks" at horizon nodes). Otherwise it will most probably cause a search explosion.

If I understand this right , then why do they do this instead of checking for and extending checks before descending in QS , isn't this the same or even better ?

Because the code that does it in QS is simpler and faster.

[Sven]

What you describe here is usually called "checks in QS". It adds quiet (non-capturing, non-promoting) checks to the set of moves being searched in QS, if none of the captures or promotions caused a cutoff. You can do that but you should limit this to the first N plies from the QS root (and most people use N=1 so they only add "quiet checks" at horizon nodes). Otherwise it will most probably cause a search explosion.

If I understand this right , then why do they do this instead of checking for and extending checks before descending in QS , isn't this the same or even better ?

Because the code that does it in QS is simpler and faster.

No, because he is mixing up "extending a node when being in check" and "giving check". The former is subject of check extension and the latter is part of "checks in QS". What Mahmoud says does not change the set of moves being considered at the root node of QS where the moving side is not in check - due to check extension preventing it - but might be able to give some quiet checks in addition to captures and promotions.

[Luis Babboni]

...
"extending a node when being in check" and "giving check". The former is subject of check extension and the latter is part of "checks in QS"
...

I did not understood if it is refering to me or not, but in any case I do not sure if I understand the meaning of "extending a node when being in check".

Is not the same as "extending a node when giving check" if depth is an even cuantity, i.e. in last ply, an opponent move, the moving side giving check?

Thanks for clarify me.