Losing captures in QS

[matthewlai]

Do you search SEE-losing captures in QS? I have always not searched them, and just did some quick test.

For Giraffe, not searching them is much better -

Code: Select all

Rank Name             Elo    +    - games score oppo. draws 
   1 Giraffe orig      37    6    6  3174   61%   -37   33% 
   2 Giraffe fullqs   -37    6    6  3174   39%    37   33% 

[matthewlai]

And extending all non-SEE-losing checks in QS is an improvement.

If QS gets a position where the moving side is in check, it does a full search with node budget 1 (equivalent to depth 1) search instead.

Code: Select all

Rank Name               Elo    +    - games score oppo. draws 
   1 Giraffe qschecks    16    6    6  3210   55%   -16   32% 
   2 Giraffe orig       -16    6    6  3210   45%    16   32% 

[BubbaTough]

Do you search SEE-losing captures in QS?

Most people do not search SEE-losing captures in QS. It is impressive you managed to build such a strong engine without doing this, as the QS can really explode if you search all captures all the time.

-Sam

[bob]

And extending all non-SEE-losing checks in QS is an improvement.

If QS gets a position where the moving side is in check, it does a full search with node budget 1 (equivalent to depth 1) search instead.

Code: Select all

Rank Name               Elo    +    - games score oppo. draws 
   1 Giraffe qschecks    16    6    6  3210   55%   -16   32% 
   2 Giraffe orig       -16    6    6  3210   45%    16   32% 

I'd bet this is unique to your atypical search approach, rather than being of use to everyone.

[bob]

Do you search SEE-losing captures in QS? I have always not searched them, and just did some quick test.

For Giraffe, not searching them is much better -

Code: Select all

Rank Name             Elo    +    - games score oppo. draws 
   1 Giraffe orig      37    6    6  3174   61%   -37   33% 
   2 Giraffe fullqs   -37    6    6  3174   39%    37   33% 

Same as my other response. When you use an atypical search approach, things change. This likely suggests a flaw in the basic search idea you use with this "node budget" stuff, because not including losing captures (SEE) is a clear win in every test I have done, with each test having about 10x more games than your sample.

[matthewlai]

I'd bet this is unique to your atypical search approach, rather than being of use to everyone.

That is certainly possible.

It could be compensating for the lack of explicit check extension, though my search approach does naturally extend checks somewhat since there are usually much fewer legal moves to divide the node budget between in checks.

Further testing showed that almost all the effect is in extending leaf nodes of normal search, and not nodes deeper into QS.

Basically it's preventing the search from going into QS directly when the last move is a checking move.

[matthewlai]

Same as my other response. When you use an atypical search approach, things change. This likely suggests a flaw in the basic search idea you use with this "node budget" stuff, because not including losing captures (SEE) is a clear win in every test I have done, with each test having about 10x more games than your sample.

My test showed that NOT searching losing captures is a clear win. I think you read the results wrong.

[matthewlai]

Most people do not search SEE-losing captures in QS. It is impressive you managed to build such a strong engine without doing this, as the QS can really explode if you search all captures all the time.

-Sam

Ah no I have always not searched losing captures. I just decided to do some tests to verify that's indeed a good idea (it was).

I made this post because a while ago someone posted something about searching all captures (I can't find that post anymore).

[bob]

Same as my other response. When you use an atypical search approach, things change. This likely suggests a flaw in the basic search idea you use with this "node budget" stuff, because not including losing captures (SEE) is a clear win in every test I have done, with each test having about 10x more games than your sample.

My test showed that NOT searching losing captures is a clear win. I think you read the results wrong.

You are right. I mis-read. This is such an old and well-known idea it looked like you were doing that and had changed...

You can find references (by others) to "delta pruning" in the 90's. Which is a refinement on the idea. If you are a queen down, searching a pawn capture is not good even if it is a safe capture. I used a variable "delta" to indicate what I needed to capture to get the score back to something reasonable, and someone saw this in Crafty and started to call it "delta pruning". I don't currently do the "delta" part but I have it on my list to test again as it once worked quite well for me...

[Henk]

Most people do not search SEE-losing captures in QS. It is impressive you managed to build such a strong engine without doing this, as the QS can really explode if you search all captures all the time.

-Sam

Ah no I have always not searched losing captures. I just decided to do some tests to verify that's indeed a good idea (it was).

I made this post because a while ago someone posted something about searching all captures (I can't find that post anymore).

Perhaps you searched for a way to increase Nodes / second for Giraffe. But just use minimax instead of alphabeta. Argument: it improves move ordering.