How do engines normally catch this situation?

[MattieShoes]

Lets ignore extensions and tablebases for a moment. This is just a simple example
Qxg2 is obviously bad since Bc6 pins the queen and black has an easily won game from there, yes?

In a 2 ply search, Qxg2 Bc6, enter q-search which finds QxB bad and returns +5, which is very wrong.
In a 3 ply search, q-search would catch the pin and it would select Kxg2 instead, securing a draw at the least.

I was trying to figure out how to detect Qxg2 is bad in a 2 ply search.
Ideas? Is it worth it to try and detect this?

I had some crazy idea about doing a null move for verification when eval() fails high in a q-search, but then I figured I'm probably walking down well travelled roads and people have already examined this issue.

[bob]

Lets ignore extensions and tablebases for a moment. This is just a simple example
Qxg2 is obviously bad since Bc6 pins the queen and black has an easily won game from there, yes?

In a 2 ply search, Qxg2 Bc6, enter q-search which finds QxB bad and returns +5, which is very wrong.
In a 3 ply search, q-search would catch the pin and it would select Kxg2 instead, securing a draw at the least.

I was trying to figure out how to detect Qxg2 is bad in a 2 ply search.
Ideas? Is it worth it to try and detect this?

I had some crazy idea about doing a null move for verification when eval() fails high in a q-search, but then I figured I'm probably walking down well travelled roads and people have already examined this issue.

The answer is a 3 ply search. That what search does, deal with the tactics, so your evaluation doesn't have to deal with positions that are not "quiet"...

[MattieShoes]

I was afraid of that. Of course, the position could be 18 ply into a 20 ply search and it'd get the wrong answer until 21 ply, and it runs out of time and starts heading down the wrong path based on an eval that's off by 5 pawns.... It just bugs me that a q-search comes up with such a terribly wrong answer.

I suppose one could attempt to do some non-recursive checking of pinned pieces in eval, but that wouldn't catch forks, etc. Oi!

[bob]

I was afraid of that. Of course, the position could be 18 ply into a 20 ply search and it'd get the wrong answer until 21 ply, and it runs out of time and starts heading down the wrong path based on an eval that's off by 5 pawns.... It just bugs me that a q-search comes up with such a terribly wrong answer.

I suppose one could attempt to do some non-recursive checking of pinned pieces in eval, but that wouldn't catch forks, etc. Oi!

Here's what you hope: That such positions occur so far out in the search, that when they are evaluated wrong because of a shallow search, you are not committing to following that path thru to the bitter end. That gives you several points to vary to give you an "out". It is possible that this doesn't happen, such as where you give up a rook at the root, with the idea of getting the rook back in the position you gave. There you are simply screwed...

[hgm]

I had some crazy idea about doing a null move for verification when eval() fails high in a q-search, but then I figured I'm probably walking down well travelled roads and people have already examined this issue.

I tried this (not allowing stand-pat when null move failed low in QS, but allow recognized threat evasions), but it was counter-productive. Most threats that make the null move fail low are trivially solved, so you would have wasted a lot of time searching null moves and threat evasions, where a simple stand pat would have given practically the same score. In that time you could have easily searched one ply deeper, with better results.

If you have an evaluation that scores pinned pieces, though, you would have recognozed the pin statically anyway, and you might as well declare an alert condition that triggers an extension, just as most people would trigger an extension for evading a check in QS. It does not pay to trigger an extension just because your Queen is attacked, because, unlike the King, a Queen is very mobile and can almost always escape. But it certainly pays to trigger an extension when your Queen is attacked and pinned. Similarly, if you are updating an attack map already, you might trigger an extension on multiple LxH threats or attacks on undefended pieces against you. If you can detect these (rare) conditions without spendig too much time on them, I think it could help.

[MattieShoes]

Ooh, I hadn't even considered that aspect...

Hmm, have you (or anybody else) experimented with search extensions only at the leaf nodes to detect if the last move is a Q/R fork or pin against the king/queen? Not worth it?

[MattieShoes]

Hah, you answered my question as I was asking it. thanks

[bob]

Ooh, I hadn't even considered that aspect...

Hmm, have you (or anybody else) experimented with search extensions only at the leaf nodes to detect if the last move is a Q/R fork or pin against the king/queen? Not worth it?

I've tried this, but had no luck. Remember, things you do near the tips are done very frequently, so even though they appear to be cheap, they add up quickly...