Hello and my engine plans!

[catugocatugocatugo]

Oh, I meant a 16x20 board!

[hgm]

And then the full 0x88 board which is 20x16 for piece attacks and other 0x88 trick friendly things (I'm not really sure what I am talking about here yet).

To give an example:

With 20x16, and numbering such that a1=0, j1 would be 9, and a2 would be 20. The difference is 11. If you would have had a 14x16 board, a2 would have been 14, and the difference with j1 would be 5. But that would be the same as the difference between, say, a1 and f1, which is a normal Rook move, while j1 and a2 were not on the same rank. So it would not be possible to make a table that you could use as dist[sqr1-sqr2] to tabulate the distance between sqr1 and sqr2 (e.g. as the number of King steps you need to go from one to the other). You could of course make a table dist[sqr1][sqr2], but that would be a far larger table.

With the 20x16 board you can tabulate lots of useful things indexed by sqr1-sqr2 (or, to avoid negative indexes, sqr1-sqr2+OFFSET). Like which piece types can move from sqr1 to sqr2 on an empty board (e.g. each bit of an element in the table representing a different piece type), what the direction is a slider would have to move in to make a move from sqr1 to sqr2 (e.g. as the basic step, or just as a number that is an index in a table of basic steps), or which pair of directions would do that (for bent sliders).

[catugocatugocatugo]

Ok, HGM, thanks.
One final question.
Do you think the Sargon style representation of pieces on the board strikes a good balance between speed and my ability of understanding the concepts behind an fairy chess engine?

[hgm]

Double-width mailbox boards with guard bands are amongst the fastest board representations. (In combination with a piece list, which stores the location of each piece. So the board contains piece numbers, rather than codes for the piece type: each piece would have a unique number, which can be used as index in the piece list.)

But when you use an AlphaZero-style neural net, you would not care much whether updating the board and generating moves takes 0.3% or 1% of the time.

[dangi12012]

But when you use an AlphaZero-style neural net, you would not care much whether updating the board and generating moves takes 0.3% or 1% of the time.

Intuition question: You make the neural net ~23x smaller (23x faster) and push it down one more ply and give it each position there. So in total the same speed.
Will it gain elo compared to the bigger net? Or are many smaller nets advantageous?

[catugocatugocatugo]

Double-width mailbox boards with guard bands are amongst the fastest board representations. (In combination with a piece list, which stores the location of each piece. So the board contains piece numbers, rather than codes for the piece type: each piece would have a unique number, which can be used as index in the piece list.)

How do I deal with captures then?

[catugocatugocatugo]

Oh, actually is very easy. I had figured it out on my own. The code represented becomes the code of the capturing piece. And it lefts is source square empty. Then you jsut delete the piece from the piece list array. That is not expensive.

[hgm]

Indeed, you store piece numbers so that you immediately know which element of the piece list to remove. If you would only know the type of the capture victim, there could be multiple pieces of that type, and you would have to figure out which of those got captured. What I usually do to 'remove' a piece from the piece list, is give it an invalid square number (like -1 or 255) as location.

The piece list is very helpful to know where the pieces of a given player (or of a given type) are located. If you don't have that, you would have to scan the entire board to find those. Which makes a large difference when very few pieces are left. You still would to have to scan through the relevant part of the piece list, though, and skip all pieces that were marked as captured. There are methods to avoid that (e.g. organize the piece list as a doubly linked list, where the info stored for each piece specifies the next and the previous piece that is not yet captured, or keep an additional 'presence mask', that indicates which pieces are present by setting the corresponding bit in the mask). But if you have neural nets dominating the calculation, this would not give a significant speedup, so it is probably better to keep things simple.

[catugocatugocatugo]

I'll go for the double liked least as it seems to me it is easier to handle promotions. I just remove the pawn, and insert a node near the place where the pieces of the same type as the promoted pawn is.

[hgm]

That is true. But a presence mask would allow you to do that too.With a 64-bit mask for each player you could reserve 2x64 entries in the piece list, and already initialize a lot of those for pieces that might result from promotion. (Such that would extract their bit in the presence mask would extract them in some useful order.) When you then want to loop through all pieces of a given color, you can extract the next 1 bit from the mask. And just clear the Pawn bit and set one for a spare piece of the chosen type on promotion.

But if your final goal is to make an AlphaZero-type engine, you should avoid getting lost in optimization details for code that in the end will only consume 1% of the execution time, even when done in the most inefficient and sloppy way...