What're advantages of board 16x12?

[phhnguyen]

This is the first time I work with the board 16x12 and I am not clear about its advantages.

After reading I understood:
- the trick 0x88 cannot apply to this board even someone thinks it is modified from 0x88
- it uses the same technique with 12x10 to check off board (based on border squares)
- compare with 12x10, this board is a bit quicker to compute rows, columns, convert indices to / from standard 64-square board (not very impressed me if that's all)

Am I correct or missing something? Any missing advantages of this board?
Thanks

[hgm]

The advantage of 16x12 over 10x12 (for embedding 8x8 boards) is that with 16x10 the difference of two square numbers is a unique indicator for the move. So it can be used as an index in lookup tables to easily test if two squares are (for example) on the same file, rank or diagonal. With a 10x12 board the difference between e8 and f1 would be 3, the same as that between f1 and f4. So the fact that the difference is 3 cannot be used to conclude the squares are on the same rank.

[phhnguyen]

The advantage of 16x12 over 10x12 (for embedding 8x8 boards) is that with 16x10 the difference of two square numbers is a unique indicator for the move. So it can be used as an index in lookup tables to easily test if two squares are (for example) on the same file, rank or diagonal. With a 10x12 board the difference between e8 and f1 would be 3, the same as that between f1 and f4. So the fact that the difference is 3 cannot be used to conclude the squares are on the same rank.

Got the idea, thanks.

So 16x12 has an advantage over 10x12 about checking the same line of two squares. However, I did not see it is better than the standard 0x88 (board size 16x8, without off-squares for top, left and bottom) since 0x88 can do the same.

Now I am clear how 16x12 is better 10x12 but why it is better than 0x88 is still a question. Idea?

[kbhearn]

it saves you a test - instead of a pretest of the 0x88 condition to make sure it hasn't wrapped and then a test of what's on the square to determine whether to continue and/or generate a move you can combine the two by having off board squares have a constant value that always shows up similar to an own piece to both white and black and thus both stops the slider progression and doesn't generate any move.

[hgm]

To elaborate on Kevin's answer: boards with guard bands usually combine with piece encodings that make it easy to test for the entire set of desired occupants at once. E.g. 16-31 for white pieces, 32-47 for black pieces, 48 for guards. With board[toSqr]&stm (stm = 16 or 32) you can then test if the square is an own piece or off board, and reject the move in that case.

This saves you an explicit test on the square number. Which is not really a big deal, but can become one if no easy test for this exists. E.g. if the board size is not a power of two.

An additional (minor) advantage of using a board width that is exactly double that of the real board is that you can interleave board-size tables (such as piece-square tables or Zobrist keys), so that they do not waste any space. With 10x12 boards the guard band between ranks is too small to be used for anything, and waste 20% of (L1-cache) memory. With 16x8 you can (f.e.) store a PST for white in the left 8x8 part, and for black in the guard-band area, using 100% of the memory.

[phhnguyen]

To elaborate on Kevin's answer: boards with guard bands usually combine with piece encodings that make it easy to test for the entire set of desired occupants at once. E.g. 16-31 for white pieces, 32-47 for black pieces, 48 for guards. With board[toSqr]&stm (stm = 16 or 32) you can then test if the square is an own piece or off board, and reject the move in that case.

I think differently on this point: check off-board by using an AND between for-loop-index and 0x88 (e.g, i & 0x88) should be faster than accessing the board data then check its content (e.g., if board == offvalue).

This saves you an explicit test on the square number. Which is not really a big deal, but can become one if no easy test for this exists. E.g. if the board size is not a power of two.

An additional (minor) advantage of using a board width that is exactly double that of the real board is that you can interleave board-size tables (such as piece-square tables or Zobrist keys), so that they do not waste any space. With 10x12 boards the guard band between ranks is too small to be used for anything, and waste 20% of (L1-cache) memory. With 16x8 you can (f.e.) store a PST for white in the left 8x8 part, and for black in the guard-band area, using 100% of the memory.

Zobrist is not a large table thus a bit waste is not a big problem. Otherwise I can do a trick by converting (so cheap) their indices into 0-63.

[hgm]

I think differently on this point: check off-board by using an AND between for-loop-index and 0x88 (e.g, i & 0x88) should be faster than accessing the board data then check its content (e.g., if board == offvalue).

The point is that when the 0x88 test says you are on board (as is usually the case), you will have to access that board square anyway to determine what is on it. The 0x88 test might seem cheap, but the expesive part is that it contains an extra conditional branch. The more branches you have, the harder it gets for the CPU to predict them correctly.

Zobrist is not a large table thus a bit waste is not a big problem. Otherwise I can do a trick by converting (so cheap) their indices into 0-63.

That can depend.When you have 2x31 piece types, and a board of 121 squares, it starts to add up (60KB, for an L1 of 32KB). For a non-challenging application like orthodox Chess you probably can get away with it, though.

[phhnguyen]

The point is that when the 0x88 test says you are on board (as is usually the case), you will have to access that board square anyway to determine what is on it. The 0x88 test might seem cheap, but the expesive part is that it contains an extra conditional branch. The more branches you have, the harder it gets for the CPU to predict them correctly.

Very good point!

I have been implementing some board representations just for comparing. Will check which one is faster even I am a bit doubt if I can measure correctly their difference (I guess it is not large)