After finding the pinners and potentially pinned pieces, we could OR these together as board occupation since pinners are always further from the king than potentially pinned, and use "magic" to lookup the pre-calculated pinned pieces bitboard.
Not having tested this, I am assuming that magic numbers exist. My first guess at the table size would be around 600K which is a bit of a downer but may be less depending on the magics. At least it saves looping through all the pinners.
where attks is an array of bitboards of all squares attacked by sliders for each direction, and kattks is an array of bitboards of all squares that would be attacked by the king if it were a queen for each direction (0, 45, 90, 135).
My first impression is that it's a waste. The vast majority of the time there are no pinned pieces, so you do a big magic lookup for nothing. Usually the loop over pinners is 0 or 1 cycles, which can be predicted pretty easily. I doubt you could improve on that.
where attks is an array of bitboards of all squares attacked by sliders for each direction, and kattks is an array of bitboards of all squares that would be attacked by the king if it were a queen for each direction (0, 45, 90, 135).
I use similar as well. For pinned pieces you need to intersect with all pieces of the king color, otherwise you'll also collect potential discovered checkers. In distant check (or even double check), the set may even contain some empty squares though.
After finding the pinners and potentially pinned pieces, we could OR these together as board occupation since pinners are always further from the king than potentially pinned, and use "magic" to lookup the pre-calculated pinned pieces bitboard.
Not having tested this, I am assuming that magic numbers exist. My first guess at the table size would be around 600K which is a bit of a downer but may be less depending on the magics. At least it saves looping through all the pinners.
Grant
This is one of those cases where intuition should be ignored and testing should be done. It is like the comments I get about "jeez, a bubble sort in your q-search or to SEE sort captures? Why use something so slow? Because often I am sorting 1-2-3 moves and bubble sort is as fast as anything and faster than most.
In this case, if you think about playing actual games of chess, pins are pretty rare if you are only talking about 'absolute pins" (which is a piece pinned to the king so that it can't move at all, rook/knight pinned by a bishop, rook pinned by a bishop, queen pinned by a bishop/rook. Those are _very_ rare and having more than one absolute pin in a position is beyond rare. More normal pins, such as knight pinned on a rook by a bishop might be more interesting in this light, but I doubt anyone tries to evaluate those except as part of piece scoring anyway where this "set" would not make much sense.
So, the bottom line is that you are trying to do something efficient for what is void operation for the most part, or a set of one at best...
Testing will show that the magic computation will _way_ outweigh the speed gained in those rare positions where there are multiple pins...
Symbolic keeps track of pinned pieces against the kings. Each color has a bitboard of frozen pieces (no moves) and of restricted pieces (e.g., a bishop pinning a queen). These are used to good effect in move generation where only legal moves are output by the routines. They are also used in positional scoring.
During move execution, the old pin bitboards are saved for a later restoration and new values are computed from scratch.
In my case, I'm calling pinned pieces before I start looping through the move loop as I used it for move legality detection. So its like I'm calling it as much as I'm generating moves. Making it faster for me results to noticeable increase in speed.
Edsel Apostol wrote:In my case, I'm calling pinned pieces before I start looping through the move loop as I used it for move legality detection. So its like I'm calling it as much as I'm generating moves. Making it faster for me results to noticeable increase in speed.
In the case being discussed, it really doesn't matter how many times you call it, what matters is how often is more than one piece pinned on the king. If it is, as most of us believe, usually zero, then the magic multiplication is going to hurt performance. If it could reach 3-4-5 then yes it would be a good approach. But to detect zero pins most of the time, and one on very infrequent occasions, I don't think the extra work of reading from a really big table is necessary.
And there are easier ways to either (a) check for legality or (b) just generate legal moves. I do both in Crafty in fact, depending on whether I start off at a given node in check or not...
Well I think you are right. The infrequent occasion is not worth the extra work and big table.
By the way, I'm using Matt Taylor's folded bitscan approach.
Can you elaborate further on this?
And there are easier ways to either (a) check for legality or (b) just generate legal moves. I do both in Crafty in fact, depending on whether I start off at a given node in check or not...
In my engine I used the return value from the pinnedPieces in determining move legality. I passed it to my sorting routine that does a lazy move generation in the move loop.