SEE problem

[CThinker]

Since everyone agrees that SEE is not suited for this, perhaps a simple counting of attackers/defenders is just as good.

[mjlef]

This morning, I stumbled upon a symmetry bug in my evaluation function, in the following position:
[d]4r2k/pp4p1/2p1P3/2Q5/3p4/P2Br3/1PP4q/1K2R3 b - -
The reason turned out to be that the passed pawn on e6 is evaluated differently in the mirrored position. One of the factors considered by my passed pawn evaluation is whether the pawn can safely advance. I use the static exchange evaluator to test this. I discovered that in the above position, the pawn push e6-e7 is incorrectly classified as a non-losing move (SEE value 0), while in the mirrored position, the pawn push e3-e2 is correctly classified as losing (SEE value -1).

It's easy to see why this happens. My SEE function begins by finding the least valuable attacker. In the above position, there are only two attackers, and they are both of equal value (the rooks on e8 and e3). My SEE picks the rook on e3 first. Unfortunately, this means that the X-ray attack from white's rook on e1 gets uncovered, which causes in an incorrect SEE value. In other words, the SEE analyses the sequence e6-e7 Re3xe7 Re1xe7, and concludes that white is winning, and that e6-e7 is therefore a safe move.

Now, consider the mirrored position:
[d]1k2r3/1pp4Q/p2bR3/3P4/2q5/2P1p3/PP4P1/4R2K w - -
Here, my SEE picks the other rook first. The SEE analyses the sequence e3-e2 Re1xe2 Qc4xe2 Re6xe2 Re8xe2, and concludes that e3-e2 loses a pawn.

This is of course a highly annoying problem, and I see no elegant and efficient way to fix it. How do you make sure the correct attacker gets picked first in positions with X-ray-attacks?

Tord

Lately for passed pawn, I am giving scoring like this, mostly because it is fast:

rank based bonuses for:
pawn rank
penalty for own king distance
bonus for opponent king distance
*bonus for no opponent piece in front of pawn
*bonus for no own pieces in front of pawn (very small)
* very fast with bitboards

I think a bonus for squares in front of the pawn not being attacked, or at least defended has tested well, but I have that off now since it is a bit expensive to compute.

In the past, I had a pretty big penalty for an same side rook or queen being in front of the pawn, and a bonus for an opponent rook. I should put that back in and test it

It is not hard to test these (just assume it is free to compute and do fixed depth testing). I think a lot of ELO can be gained from some pretty simple passed pawn scoring additions.

[hgm]

Since everyone agrees that SEE is not suited for this, perhaps a simple counting of attackers/defenders is just as good.

Has anyone ever tested if a simple counting of attackers and defenders isn't just as good for other common applicaations of SEE as well? (With the addition that if the lowest attacker is lower than the victim, the capture is good irrespective of the number of defenders, which doesn't play a role here, as the victim is a Pawn.)

[Tord Romstad]

Thanks for all replies!

Of course I agree with all those who said that an SEE can't be expected to give a reliable result in complex positions like this. The point is not that the SEE is wrong or too imprecise, but that it is asymmetric, and that this causes an evaluation asymmetry, which is a very serious problem.

I'll probably just write a simplified SEE which does not consider X-ray attacks (except X-ray attacks through the passed pawn), and use this rather than the normal SEE in my passed pawn eval.

Tord

[bob]

Since everyone agrees that SEE is not suited for this, perhaps a simple counting of attackers/defenders is just as good.

Has anyone ever tested if a simple counting of attackers and defenders isn't just as good for other common applicaations of SEE as well? (With the addition that if the lowest attacker is lower than the victim, the capture is good irrespective of the number of defenders, which doesn't play a role here, as the victim is a Pawn.)

We do this _before_ we do see. If you can play pxr, why bother with SEE, and I don't. I only use SEE if the value of the attacker is greater than the value of the victim, because then the number of attackers/defenders, their order, and their values becomes critical... And even then there is plenty of room for error due to overloaded pieces, discovered checks, etc...

[hgm]

The question was more if playing strength would suffer if you didn't do SEE at all, and only tried (in QS) captures where victim >= attacker, or the victim is undefended.

[CThinker]

Since everyone agrees that SEE is not suited for this, perhaps a simple counting of attackers/defenders is just as good.

Has anyone ever tested if a simple counting of attackers and defenders isn't just as good for other common applicaations of SEE as well? (With the addition that if the lowest attacker is lower than the victim, the capture is good irrespective of the number of defenders, which doesn't play a role here, as the victim is a Pawn.)

For move ordering in QS, I have actually tested that doing SEE early, with all its flaws, is still better.

What I did was to not to entirely eliminate SEE, but instead "delay" it, if there are good enough captures. I was speculating that the good-enough captures would produce cut-offs anyway, and I would avoid the more expensive SEE operations.

Normally, ordering for captures is:

Code: Select all

Generate captures
For all captures
    if victim value is >= attacker value
        value is (victim value) - (attacker value)
    else
        value is SEE
Sort captures
Try all captures

I replaced this with:

Code: Select all

Generate captures
For all captures
    if victim value is >= attacker value
        value is (victim value) - (attacker value)
    else
        add move to list of delayed captures
Sort non-delayed captures
Try all non-delayed captures

For all delayed captures
    value is SEE
Sort all delayed captures
Try all delayed captures

The result from test games is that the 'former' is still better.

[bob]

The question was more if playing strength would suffer if you didn't do SEE at all, and only tried (in QS) captures where victim >= attacker, or the victim is undefended.

I was responding to this, in the post immediately preceeding mine:

Has anyone ever tested if a simple counting of attackers and defenders isn't just as good for other common applicaations of SEE as well?

[hgm]

OK, sorry. In flat mode that isn't always obvious.

[Uri Blass]

The question was more if playing strength would suffer if you didn't do SEE at all, and only tried (in QS) captures where victim >= attacker, or the victim is undefended.

It seems to me not a good idea because you miss a lot of good captures
when 2 pieces threat the same square.
SEE is also missing a lot of good captures based on indirect threats.
I suspect that it may be better not to use SEE for pruning in the qsearch
and to have some special pruning function that is usually correct to decide if a capture is bad and you should not try it.

The special function can consider also indirect threat and find that there is no indirect threat.

Uri