Bit Board Orientation

[MOBMAT]

Which board orientation do you use for your engines?
That is, is the 0th bit the A8 square, H8 is 7th, and so on, or do you as I usually do, make the 0th bit A1, and H1 is the 7th bit.

I've done both and it didn't seem to make a difference as long as the "shift" and move mask values are correct for move generation but I think (correct me if I'm wrong), Magic bitboards are set up to only work one way. Which way is it?

Are there any other reasons why one way is preferred over the other, besides the fact that a majority might do it one way more than the other?

[jwilson82]

My engines have always had

Code: Select all

A1 = 0

, which would make it the least-significant bit. While annecdotally I feel like that's the most popular choice, I know I've seen engines where

Code: Select all

H8 = 0

There isn't anytihng in the magic bitboard math that necessitates doing it one way or the other. If you were going to copy magics that somebody else had generated you'd need to know which scheme they used and reverse the order of the values in the array if you used the opposite scheme

[mvanthoor]

As far as I know, it doesn't matter, but obviously you have to adjust all your calculations to this.
You could make the lowest bit H8, and then go backward, with the next bit being G8, F8...
Or you could make it H1, and then go upward, with the next being H2, H3...
Or you could make the highest bit A1, then the next highest B1... and so on.

In my engine, the lowest bit (LSB) is A1. It feels the most logical to me. In an array such as the piece list, the first element (at index 0) is A1.

The only exception I make is with the PSQT's: there, A1 is element 56, so A1 is at the lower left after I print a PSQT in an 8x8 representation, just like a chess board. Makes the PSQT's much easier to handle. I have a FLIP table that transforms this representation back into what it should be for the engine.

Like so: https://github.com/mvanthoor/rustic/blo ... on/psqt.rs

[Harald]

I have
A8 as bit 63, H8 as bit 56
A1 as bit 07, H1 as bit 00

Then I can read a 64 bit hex number and see the bits easily on the whole board
in my imagination since I know the bit representation from 0 to f by heart.

For tables I use flipping macros. Then I write them down in a human readable way
with A8...H8 on top and A1...H1 at the bottom and the compiler sees them as it needs it.

[Dann Corbit]

I like Harald's way, but mirrored.
Bit 1 is a8, bit8 is h8.
The reaons I like it that way is that it corresponds directly to EPD or FEN.

[Tord]

I use a8=0, a7=1, ..., h1=7, b8=8, ..., h1=63. It's convenient to use "file-major" rather than "rank-major" indexing, because it makes generating pawn captures a little easier (you don't have to worry about wraparounds from the a to the h file when shifting the pawn bitboards).

[mvanthoor]

I use a8=0, a7=1, ..., h1=7, b8=8, ..., h1=63. It's convenient to use "file-major" rather than "rank-major" indexing, because it makes generating pawn captures a little easier (you don't have to worry about wraparounds from the a to the h file when shifting the pawn bitboards).

Shouldn't that be:
a8 = 0,
a7 = 1,
....
b8 = 8
...
h8=56,
...
h1=63 ?

I assume you have a typo at h1=7, and switched it around with b8 in the list.

That feels hard to visualize... I always look at chess from white's point of view, be it position setup, evaluation, or when analyzing on the computer.

Even when I'm analyzing a game on the computer I played with black myself, I'm still analyzing from white's point of view. I really dislike the black viewpoint when looking at a chessboard in 2D and NOT playing black myself at that time. (Diagrams, computer screen, or even when represented in code with anything else but A1 = 0) . I can -do- it, but it costs mental effort to turn everything 'right side up' all the time. The only time I'll use the black point of view (and have no problems with it) is when -playing- black myself.

[Dann Corbit]

For me, it is worse than that.
All these years of computer chess make it uncomfortable for me to play with a chessboard and chessmen.
I would MUCH rather have a 2-d display like Winboard produces

[Tord]

I use a8=0, a7=1, ..., h1=7, b8=8, ..., h1=63. It's convenient to use "file-major" rather than "rank-major" indexing, because it makes generating pawn captures a little easier (you don't have to worry about wraparounds from the a to the h file when shifting the pawn bitboards).

Shouldn't that be:
a8 = 0,
a7 = 1,
....
b8 = 8
...
h8=56,
...
h1=63 ?

I assume you have a typo at h1=7, and switched it around with b8 in the list.

You are right. I meant a1=7, of course.

That feels hard to visualize...

Not a problem at all. I visualize the board pretty much exactly the same way you and everybody else do, I believe. The square indexing scheme is a low-level implementation detail that isn't visible anywhere in the high-level parts of the code. In those parts of the code where visualization matters at all, the square indices are invisible.

[Aleks Peshkov]

My coordinates are relative to each side. A8 = 0 for White, A1 = 0 for Black.
It seems complex but it simplifies many calculations to make them true color independent.