Answers.Body: <p>The method of magic bitboards basically applies a hash function to the important occupancy, or in other words, all the pieces that could potentially block the currently moving piece.</p>
  <p>For example, let's suppose that we have a rook on e4.</p>
  <pre><code>. . . . . . . .
  . . . . . . . .
  . . . . . . . .
  . . . . . . . .
  . . . . 1 . . .
  . . . . . . . .
  . . . . . . . .
  . . . . . . . .
  </code></pre>
  <p>and that our occupancy looks like this:</p>
  <pre><code>. . . . 1 . . .
  . . . . . . . .
  . . . . 1 . . .
  . . . . . . . .
  . . . . R . . 1
  . . . . 1 . . .
  . . . . . . . .
  . . . . . . . .
  </code></pre>
  <p>After hashing, we get an index into our table, and by accessing that index we should obtain the move-mask.</p>
  <p>Our move mask, i.e. the squares that the rook can move to (without considering squares our pieces currently occupy), should look like this:</p>
  <pre><code>. . . . . . . .
  . . . . . . . .
  . . . . 1 . . .
  . . . . 1 . . .
  1 1 1 1 R 1 1 1
  . . . . 1 . . .
  . . . . . . . .
  . . . . . . . .
  </code></pre>
  <p>The closest occupancies to the rook are registered as legal squares. They have to be AND'd with NOT our pieces. This way, we register captures as legal squares.</p>
  <p>Note that the occupancy on h4 <em>does not affect the movemask at all</em>. Regardless of whether the h4 piece is there, we are still generating the same attackmask. So, the h4 piece isn't really a blocker.</p>
  <p>The reason why removing the edges reduces memory is because to store the bitboards, we have to check through every possible permutation of relevant blockers for a rook or bishop on a given square, generate the attack mask, and apply the <em>magic hashing</em> to it generate an index into our hash table, which contains all of the corresponding attack masks. By removing redundant bits that don't affect the generated move-mask we can significantly reduce the size of our table.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-19T22:54:15.183Z
Answers.LastActivityDate: 2022-07-19T22:54:15.183Z
Answers.UserDisplayName: AAce3
Answers.Body: <p>The move mask is only used to obtain the pieces that will block the Bishop. Edge pieces will never block any diagonal moves.</p>
  <p>Given the blockers and the Bishop's location the algorithm then looks up the set of unblocked moves. Under the assumption that all blockers are foes. So to get actual pseudo-legal moves you would still have to ANDNOT with the friendly pieces. But usually you want to generate captures and non-captures separately, so for the captures you would AND with enemy pieces, and for non-ceptures ANDNOT with the 'occupied' (all pieces) bitboard.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-02T12:30:32.137Z
Answers.LastActivityDate: 2022-07-02T12:30:32.137Z
Answers.UserDisplayName: H.G.Muller
Body: <p>I've been trying to understand magic bitboards, but everywhere I've read failed to explain how edge pieces are handled.</p>
  <p>The pieces at the borders are ignored to save space.</p>
  <p>So for a bishop at <code>D3</code>, the move mask would be:</p>
  <pre><code>00000000
  00000000
  00000010
  01000100
  00101000
  00000000
  00101000
  00000000
  </code></pre>
  <p>instead of:</p>
  <pre><code>00000000
  00000001
  10000010
  01000100
  00101000
  00000000
  00101000
  01000100
  </code></pre>
  <p>checking if a piece at <code>C4</code> can be attacked by the bishop can be easily done by anding the move mask and a bitboard representing <code>C4</code>.</p>
  <p>But, you wouldn't be able to do that for a piece at the border?</p>
  <p>for example, you wouldn't be able to determine if a piece at <code>A6</code> can be attacked by anding since it wasn't included in the move mask in the first place.</p>
  <p>How would you determine attacks at borders that have been ignored?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-06-26T11:01:48.130Z
Comments.Text: That's not how magic bitboards work. The algorithm to obtain bishop attacks doesn't involve just `AND`ing the "move mask" with the occupiers bitboard. The reason the borders are ignored for this "move mask" is because a piece on the border has no effect on whether a bishop/rook can attack other squares.
Comments.UserDisplayName: Nihar Karve
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-06-28T21:27:32.277Z
Comments.Text: Hi Foder, see if my comments here help you at all: https://github.com/algerbrex/blunder/blob/develop/engine/magic.go
Comments.UserDisplayName: Chris
Tags: <engines><bitboard>
Title: Border pieces in Magic Bitboards
ThreadText: # Border pieces in Magic Bitboards
  
  (Asked by: username_0 on 2022-06-25)
  
  I've been trying to understand magic bitboards, but everywhere I've read failed to explain how edge pieces are handled.
  The pieces at the borders are ignored to save space.
  So for a bishop at D3, the move mask would be:
  00000000
  00000000
  00000010
  01000100
  00101000
  00000000
  00101000
  00000000
  
  instead of:
  00000000
  00000001
  10000010
  01000100
  00101000
  00000000
  00101000
  01000100
  
  checking if a piece at C4 can be attacked by the bishop can be easily done by anding the move mask and a bitboard representing C4.
  But, you wouldn't be able to do that for a piece at the border?
  for example, you wouldn't be able to determine if a piece at A6 can be attacked by anding since it wasn't included in the move mask in the first place.
  How would you determine attacks at borders that have been ignored?
  
  **Tags:** engines, bitboard
  
  > **Comments:**
  > **username_1**: That's not how magic bitboards work. The algorithm to obtain bishop attacks doesn't involve just `AND`ing the "move mask" with the occupiers bitboard. The reason the borders are ignored for this "move mask" is because a piece on the border has no effect on whether a bishop/rook can attack other squares.  
  > **username_2**: Hi Foder, see if my comments here help you at all: https://github.com/algerbrex/blunder/blob/develop/engine/magic.go  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2022-07-19. Score: 1 | Accepted answer
  
  The method of magic bitboards basically applies a hash function to the important occupancy, or in other words, all the pieces that could potentially block the currently moving piece.
  For example, let's suppose that we have a rook on e4.
  . . . . . . . .
  . . . . . . . .
  . . . . . . . .
  . . . . . . . .
  . . . . 1 . . .
  . . . . . . . .
  . . . . . . . .
  . . . . . . . .
  
  and that our occupancy looks like this:
  . . . . 1 . . .
  . . . . . . . .
  . . . . 1 . . .
  . . . . . . . .
  . . . . R . . 1
  . . . . 1 . . .
  . . . . . . . .
  . . . . . . . .
  
  After hashing, we get an index into our table, and by accessing that index we should obtain the move-mask.
  Our move mask, i.e. the squares that the rook can move to (without considering squares our pieces currently occupy), should look like this:
  . . . . . . . .
  . . . . . . . .
  . . . . 1 . . .
  . . . . 1 . . .
  1 1 1 1 R 1 1 1
  . . . . 1 . . .
  . . . . . . . .
  . . . . . . . .
  
  The closest occupancies to the rook are registered as legal squares. They have to be AND'd with NOT our pieces. This way, we register captures as legal squares.
  Note that the occupancy on h4 does not affect the movemask at all. Regardless of whether the h4 piece is there, we are still generating the same attackmask. So, the h4 piece isn't really a blocker.
  The reason why removing the edges reduces memory is because to store the bitboards, we have to check through every possible permutation of relevant blockers for a rook or bishop on a given square, generate the attack mask, and apply the magic hashing to it generate an index into our hash table, which contains all of the corresponding attack masks. By removing redundant bits that don't affect the generated move-mask we can significantly reduce the size of our table.
  
  
  ---
  
  ### Answer by username_4 on 2022-07-02. Score: 2
  
  The move mask is only used to obtain the pieces that will block the Bishop. Edge pieces will never block any diagonal moves.
  
  Given the blockers and the Bishop's location the algorithm then looks up the set of unblocked moves. Under the assumption that all blockers are foes. So to get actual pseudo-legal moves you would still have to ANDNOT with the friendly pieces. But usually you want to generate captures and non-captures separately, so for the captures you would AND with enemy pieces, and for non-ceptures ANDNOT with the 'occupied' (all pieces) bitboard.
  
  
  ---
  
  