Poor man's SEE

[hgm]

The engine I am building for the Gigatron will be aware of the attacks by both sides on every piece. I was planning to use this information to decide in QS whether a HxL capture is worth searching, based on counting the number of attackers vs the number of protectors. These could be obtained from the attack map by popcnt (implemented through a table lookup).

I realize now this can be refined, however. In counting the number of attackers and protectors, I don't have to give equal weight to all the pieces. E.g. if I would count every Pawn for 25, and all other pieces for 1, protection by a Pawn could never be overcome by a collection of non-Pawn attackers, no matter how many of those you have. Which is correct, because the HxL, PxH capture + recapture will always lose you 2 or more, and the only thing to be gotten after that is a Pawn. If I do have as many Pawn attackers as there are Pawn protectors, I can continue trading until both our Pawns are used up, and his is on the square, ot protected by any Pawns anymore. So then I can likely gain it if my non-Pawn attackers outnumbered his non-Pawn protectors. If I had more Pawns, then, after trading Pawns, my Pawn will end up on the square, and at best he can recapture it even if the number of non-Pawn protectors outnumbered mine. So it will never be SEE < 0 if 25*PawnAttackes + nonPawnAttackers > 25*PawnProtectors + nonPawnProtectors.

I wonder how far one can push this. I could also weight minors heavier than Pawns, in the attacks/protections count. Unlike Pawns, a minor could provide enough compensation for the initial HxL capture + recapture, though. So a single Knight protector should not discourage two Rook attackers of a Bishop. It should discourage two Rook attackers of a Pawn, though, or a Queen attacker of anything lower. But the attack count would not be kept incrementally, but calculated on the fly from the attack map, through a table lookup. So I suppose the table used for that lookup could be made to depend on how large the initial loss (the H-L difference) is, just by using another lookup table for RxP as for RxB. It also doesn't need to weight all pieces of the same type the same, but can be detailed to represent the specific combination of attackers and protectors.

Perhaps counting a minor for 3 and and KQR for 2 would work on R x minor and minor x P (which both 'inverst' 2). Then an RB protection would not discorage a QRR attack on a Knight, but a BN protection would. Unfortunately the attack map in my engine doesn't provide easy distinguishing of B and Q attacks, as slider attacks are recorder by direction, not by piece, and it would be cumbersome to figure out which piece is responsible for a certain diagonal attack. Pawn attacks are recognizable, though. So I guess I should just stick to the heavy weighting of Pawns, to at least exclude HxL captures on pieces protected by Pawns.

[Michael Sherwin]

Since I read somewhere else that the qsearch move generator will generate captures by iterating thru the enemy pieces MV to LV I think no extra work is needed as only the moves that have a chance to increase alpha will even be looked at and if none do the stand pat score will terminate that line. It seems automatic with nothing else needed. The biggest advantage doing it this way is that sorting the captures is not needed. I was thinking for some time to do this in RomiChess as well but have never gotten around to it..

[hgm]

Well, there still is the problem of HxL captures. If I am 3 points below alpha then QxR has the potential to increase the score to alpha+2. But if the Rook is protected, searching it would be a waste of time, as the score will not remain alpha+2, but sink to alpha-7.5 on the recapture. In most cases I would have wasted my time by adding two nodes. But this could still end well if the only protector was a Queen, and I had a King (or a Rook X-raying Q) as a second attacker. So pruning every H x protected L is too risky.

Running a full SEE would of course solve this, but would also be quite expensive. Using attacker/protector count would be very cheap in comparison, and might be able to weed out a large fraction of the bad captures. Having fewer attackers than protectors (or an equal number) would make it very unlikely a LxH capture could do any good. So pruning all captures that do not have more attackers than protectors, or have more Pawn protectors than Pawn attackers, would seem a good improvement. The only downside is that you might miss captures that have extra X-ray attackers.

[Michael Sherwin]

Yes, the SEE would be expensive. And the very next call to qsearch will find the refutation anyway. Beyond that though if the HxL uncovers a separate LxH that would also be found quickly by the next call to qsearch. So the SEE might return that the first HxL is okay but would be blind to the uncovered LxH resulting in wasted effort. I believe in Bob's axiom, 'don't do anything that you do not have to do and don't do anything you do have to do before you have to do it'. BTW, where is Bob (his last post was in August), do we have to send out a search party?