Noob: Problem extending the search for captures

[Ralph Stoesser]

What is BLIND? How does it work?

Unfortunately SEE is rather stupid. Often enough a move with SEE(move)<0 is a good move. I'm refering to standard tactics in case of several hanging pieces, not to diabolic sacrifices.

[hgm]

Well, BLIND iseven more stupid (but faster). It stands for "Better, or Lower If Not Defended". So for high captures lower I check if the victim is (pseudo-legally) defended. If it is, the capture is postponed. A refinement is that when I get to the postponed captures (after all others are done), I then check if the original victim and its defender together are worth more than than the attacker, so that in theory I could still end up ahead ifI have a second attacker. In that case I check if there indeed is such an attacker, and if so, I search it as a "dubious capture". In all other cases it gets postponed even further, untill after the non-captures.

[tpetzke]

Why would you not order the captures ing QS by SEE, if you do the SEE anyway

My SEE is rather heavy as it is aware of PINs, so I don't want to apply it on all moves when I have a good chance to get a cutoff on the first or 2nd move. Usually the MVV/LVA scheme is good enough to get you a reasonable order in QS and much quicker but I don't trust it for the pruning decision. Whenever I'm about to execute a capture of a low value piece with a high value piece in QS, I do a SEE first.

I would include a hash move in QS move ordering when I had one, but I don't read/write to the hash table in QS. I tried several implementations (even a separate QS hash table) but it did not help overall, so at the moment this code is not part of the engine.

Thomas...

[tpetzke]

Unfortunately SEE is rather stupid. Often enough a move with SEE(move)<0 is a good move.

That's not a problem of SEE, it gets you the value for the exchange of pieces on a square. It does not mean that in 100% of a move with SEE > 0 you have a good move or in 100% of moves with SEE<0 you have a bad move.

Consider a position where both sides can make a winning capture of the same quality. Executing both winning captures keeps the material balance and you don't fail high. Performing first a losing capture with the piece that is the victim for the enemy's winning capture gets you that fail high.

Is it worth to look for such patterns or execute all captures to not miss such cases, that's a decision every programmer must make on its own and this what makes engines different at the end. Part of the fun

Thomas...

[Ralph Stoesser]

Unfortunately SEE is rather stupid. Often enough a move with SEE(move)<0 is a good move.

Consider a position where both sides can make a winning capture of the same quality. Executing both winning captures keeps the material balance and you don't fail high. Performing first a losing capture with the piece that is the victim for the enemy's winning capture gets you that fail high.

Is it worth to look for such patterns or execute all captures to not miss such cases, that's a decision every programmer must make on its own and this what makes engines different at the end. Part of the fun

Thomas...

Yes, this is one of the tactics I had in mind. I think that happens quite often, but I doubt it is worth to look for such patterns, otherwise all the best engines would do it. But I will try it out myself to be sure...