A question on rotated bitboard

Code, algorithms, languages, construction...
hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: A question on rotated bitboard

Post by hyatt » Thu May 05, 2011 4:52 pm

n_ven wrote:Hi Hyatt,
I don't quite follow your "they will be the same for..." If you put a sliding piece on any one of the 64 square, you have 64 different attack patterns, one for each square. But since the pieces slide, you need that [256] for rooks (actually you can reduce this to 64 since the endpoint on a rank/file/diagonal can be empty or occupied without changing the attacks.)
I agree that there would be 64 different attack patterns. But, I would keep only the first 8 of them in a 8*256 table (instead of 64*256) and derive the rest by shifting i.e I would keep the 256 state attack table for each of the 8 rook positions in a file for a base rank i.e rank_attack[8][256] and derive the attack set for the rest of the ranks from the table by bit shifting by 8*(rank - 1).

For e.g, If the rook is on square d1(file 4, rank 1) and if there are 2 pieces on a1 and h1, The attack set(rank_attack[3][129]) would be,

00000000
00000000
00000000
00000000
00000000
00000000
00000000
01101110
That's wrong. The rook attacks a1 _and_ h1. And if an enemy piece is on either, the rook can move to that square and capture it.

For any single square, there are 32 different possible sets of squares that are attacked. The square the piece sits on is not attacked. The two adjacent squares are always attacked. Beyond that, the piece attacks each square, up to and including the first occupied square in either direction. In the simple case, with the rook on the a-file, there are 7 possible 1 bits in the attack. But they have to be looked up based on the occupied squares on that rank. Since there are 7 bits we might attack, there are 2^7 possible combinations of occupied and empty squares. You have to account for all of them. You can eliminate the last square since it is attacked whether it is occupied or not, if all the intervening squares are empty. Leaving 2^6 or 64 possible attack bitmaps to look up.

If you want to do more shifting around, you can have just one rank-attacks vector of 64 values, but now you have to shift the occupied squares for the correct rank, then do the lookup, then shift the attack bits back up to the right square. It is cheaper to just look up the correct value.


And if we want to calculate the attack set for square d2(file 4, rank 2), I would left shift the above state by 8*(rank-1) which is,

(i.e rank_state[3][129]<<8*1)

00000000
00000000
00000000
00000000
00000000
00000000
01101110
00000000
I do not see how you can get away with rank_attacks[64]. You have 64 squares on the board. Each group of 8 of those squares is on a different rank, which means a different set of bits will be 1's. And for each rank, different squares can be occupied, blocking sliding attacks.

How can you reduce that to just 64?
See above? you don't have to have entries for the two end squares on a rank or file. They are attacked whether they are empty or occupied. As long as intervening squares are empty.

Initially I was confused. Now I understood and agree that we just cant have a 1d rank_attack[64] and we would need the table for each of the rook position in a file i.e rank_attack[8][64].

Thanks,
Venkatesh N

n_ven
Posts: 6
Joined: Wed May 04, 2011 7:37 am

Re: A question on rotated bitboard

Post by n_ven » Fri May 06, 2011 6:13 pm

That's wrong. The rook attacks a1 _and_ h1. And if an enemy piece is on either, the rook can move to that square and capture it.

For any single square, there are 32 different possible sets of squares that are attacked. The square the piece sits on is not attacked. The two adjacent squares are always attacked. Beyond that, the piece attacks each square, up to and including the first occupied square in either direction. In the simple case, with the rook on the a-file, there are 7 possible 1 bits in the attack. But they have to be looked up based on the occupied squares on that rank. Since there are 7 bits we might attack, there are 2^7 possible combinations of occupied and empty squares. You have to account for all of them. You can eliminate the last square since it is attacked whether it is occupied or not, if all the intervening squares are empty. Leaving 2^6 or 64 possible attack bitmaps to look up.

If you want to do more shifting around, you can have just one rank-attacks vector of 64 values, but now you have to shift the occupied squares for the correct rank, then do the lookup, then shift the attack bits back up to the right square. It is cheaper to just look up the correct value.
Hi Hyatt, Thanks for pointing the mistake. I think I understand more clearly now. I will try to implement it.

Post Reply