en.wikipedia.org/wiki/Bitboard
2 corrections found
Magic bitboards typically do not store attack vectors.
This is backwards: standard magic-bitboard implementations store precomputed attack bitboards in lookup tables and use the hash only to index those stored tables.
Full reasoning
Pradyumna Kannan’s 2007 paper on magic move-bitboard generation explicitly describes indexing a move-bitboard database. In Listing 5, he declares U64 moveDB[64][1<<s] and says to compute the move-bitboard and place it at the indexed location in the move database. That means the attack vectors are stored.
Modern engine code does the same thing. In Stockfish, RookTable and BishopTable are declared specifically to store rook attacks and to store bishop attacks, and the initialization code fills m.attacks[idx] = reference[i] for each occupancy pattern. So while magic bitboards avoid storing a gigantic naive 2^64 table, they still store precomputed attack bitboards in smaller lookup tables.
2 sources
- Magic Move-Bitboard Generation in Computer Chess
Kannan writes that the relevant occupancy bits are used to "index a move-bitboard database" and shows `U64 moveDB[64][1 << s]`, with code comments saying to compute the move-bitboard and place it in the move database.
- Stockfish/src/bitboard.cpp at master
Stockfish declares `Bitboard RookTable[0x19000]; // To store rook attacks` and `Bitboard BishopTable[0x1480]; // To store bishop attacks`, then fills `m.attacks[idx] = reference[i]` during initialization.
This reduces the maximum amount of relevant occupancy bits per square from 64 to 12 for central rooks, and to 5 for corner bishops.
Corner bishops have 6 relevant occupancy bits before optimization, not 5.
Full reasoning
This sentence appears to confuse relevant occupancy bits with an optimized index width.
When magic-bitboard masks omit outer edge squares, a bishop on a1 still has six relevant blocker squares on its diagonal: b2, c3, d4, e5, f6, g7. In other words, the raw relevant occupancy mask for a corner bishop has 6 bits.
A concrete implementation source reflects this directly: Caissa’s bishop magic table labels square a1 as 6 bits -> 5 bits optimized (and likewise h1, a8, h8). So 5 bits can be an optimized index size after exploiting constructive collisions, but the number of relevant occupancy bits for a corner bishop is 6, not 5.
2 sources
- Caissa/src/backend/Bitboard.cpp at master
Caissa’s bishop magic table marks the corner bishops as `a1, 6 bits -> 5 bits optimized`, `h1, 6 bits -> 5 bits optimized`, `a8, 6 bits -> 5 bits optimized`, and `h8, 6 bits -> 5 bits optimized`.
- Stockfish/src/bitboard.cpp at master
Stockfish’s magic initialization says board edges are excluded from relevant occupancies (`m.mask = sliding_attack(directions, s, 0) & ~edges`), which leaves a corner bishop’s non-edge diagonal squares b2 through g7 as the relevant blockers.