Does SEE any good in FSF?

[HGMuller]

In search.cpp there are several comments that say some of the SEE-based prunigs gain 20, resp. 25 Elo points. But the see_ge routine they call to do their thing appears to only consider the orthodox piece types P, N, B, R, Q, plus the royal piece. All fairy pieces attacking the square are ignored. I would expect this to do more harm than good in variants where unorthodox pieces are present. Some code seems to have been added for removing a Janggi Cannon from the bitboard of attackers if the intended victim is also such a Cannon, but this seems pretty pointless, as being an unorthodox piece it would be ignored anyway.

What seems to be needed to have see_ge make any sense is to replace the hard-coded if cascade over attackers P, N, B, R, Q, K (basically an unrolled loop over piece types in ascending order) by a real loop over actually participating piece types. To avoid sorting, a table in the variant description could be used to specify the order in which the piecesmust be used in the exchange.

There are some other routines (e.g. slider_blockers) that go through some effort to prepare information used in see_ge, (e.g. which pieces are pinned, and where the pinners are.) so if we decide that SEE is not worth it, these could be simplified. It also seems that even though see_ge uses some approximate method for not using pieces that are pinned in the exchange, it seems to ignore pieces of the opposit color in the same situation, which would discover a check when used to capture. (Both types of pieces are indicated by slider_blockers.) While such a check would immediately terminate the exchange, because the opponent has to first evade the check, rather than recapture.

[ianfab]

It is not true that fairy pieces are ignored in SEE, the only problem is that ordering of captures does not consider the value of fairy pieces, so if the result of SEE depends on capture order it can be off. Since that still seemed like a big issue to me though, I at some point tested for a few variants how much fixing the ordering would gain and was surprised how low the gain was, so I did not further investigate a generic solution since there were other priorities. Long term of course should be addressed, but it might not be as bad as how stupid it looks. However, I am happy to be proven wrong if there is an easy big Elo gainer.

[HGMuller]

OK, sorry, my mistake. The fairy-pieces section contains the constant KING where the previous if-clause says QUEEN, so I unjustly assumed that it was treating the captures by King without looking carefully at the code.

I was asking this because I tried to establish how important the various kinds of info are that the slider_blockers routine determines; see_ge seems to be the only routine that uses the 'pinners'. It even takes the trouble to detect pinning by batteries, and also marks the sliders in the back of the battery as pinners (by removing all other slidingSnipers when counting occupancy of the path). But it doesn't something similar for hoppers, and pieces in the back of a hopper battery would not be recognized as pinners. (And it doesn't seem to account for the peculiarity of grasshoppers.) Some of the new piece types I implemented require an overhaul of this code to work well.

BTW, I can understand why the order doesn't matter very much: by far the most important function of SEE is to establish whether a piece is protected or hanging. Exchanges with multiple protectors and attackers are rare. So as long as all piece types are considered sub-optimal order is just a minor problem.