design choices

[hgm]

Well, a mailbox representation is no good without a piece list telling where the pieces are. And a bitboard stack is basically a fancy kind of piece list, which does indicate locations not per individual piece, but per piece type.

[tcusr]

Well, a mailbox representation is no good without a piece list telling where the pieces are. And a bitboard stack is basically a fancy kind of piece list, which does indicate locations not per individual piece, but per piece type.

of course. you win some, you lose some.

[Mike Sherwin]

Well, a mailbox representation is no good without a piece list telling where the pieces are. And a bitboard stack is basically a fancy kind of piece list, which does indicate locations not per individual piece, but per piece type.

My latest attempts use a u64 piece[2] to hold the piece locations for each sides pieces. Its advantage over a doubly linked list is its speed. The disadvantage would be in easy piece ordering scenarios especially for staged move generation. I'm not sure which is better.

[hgm]

Organizing the piece list as a doubly linked list is one way to speed up the loop over pieces over having a simple array, when the board population thins. In Joker I just compacted the list in the root, but in the tree pieces get captured, and it is a pain having to test whether a piece is still there. But for the linked list the update on capture is more involved. And the problem with linked lists is that you get very long dependency chains of instructions, which CPUs often do not like.

An alternative is to maintain a 'presence mask' next to a piece-list array, so that you can use bit extraction to loop through the array skipping the already captured pieces. Such a mask is even easier to update as white/black bitboards. Or as linking/unlinking. It is of no use for generating slider atack sets, though.

[JohnWoe]

Too much complexity. Once my code is so simple that even my dog understand it. Then that code is high quality.

copy-make works in Mayhem as 8x8 is so simple.
make-unmake works better in Havoc.
Right tool for the job.
My engines are move generators w/ a little bit engine code on top...

[Chessnut1071]

Well, a mailbox representation is no good without a piece list telling where the pieces are. And a bitboard stack is basically a fancy kind of piece list, which does indicate locations not per individual piece, but per piece type.

My PEXT bitboard also includes a Piece list which includes ply, current square, type and number of moves. Never heard of a bitboard stack. How would that be better than a Piece matrix?

[hgm]

With 'bitboard stack' I refer to the usual array of bitboards indexed by piece type. I thought that this was the standard term. I have no idea what a 'piece matrix' is.

I also do not understand what the function of 'ply' would be in a piece list. With 'number of moves' you mean the moves it can do in the current position? And 'type' is the type of the piece?

[Chessnut1071]

With 'bitboard stack' I refer to the usual array of bitboards indexed by piece type. I thought that this was the standard term. I have no idea what a 'piece matrix' is.

I also do not understand what the function of 'ply' would be in a piece list. With 'number of moves' you mean the moves it can do in the current position? And 'type' is the type of the piece?

I transitioned to bitboards using my Piece matrix, consisting of no. of moves, current location, piece type and ply. It's a simple (33,4) byte matrix. It differs from the standard u64 piece boards, but, it includes all the information I need about the piece. I generate the occupancy boards from the Piece matrix. If there's something faster and still includes the same information I'd be interested. Most of this is still new to me, but, my search engine requires all that piece information. I keep everything in memory, so I don't have a move-take back move, I just copy from the previous ply. I thought the "bitboard stack" only included the piece position.

[hgm]

What I don't understand is how a piece can be associated with a ply. And why do you have 33? You also have an entry for an empty square?

The 'number of moves' seems derived information, not part of the game state. Do you calculate that from scratch in every node, by move generation?

The standard way to implement bitboard is to have black and white occupancy boards (possibly implemented as an array occupancy[2]), plus a bitboard for each colored type (pieces[2][6]). In MakeMove() two boards have to be updated for the moved piece as well as its capture viction: the colored occupancy and the board for its colored type. For generating slider moves you would need total occupance, but this can be obtained by just ORing the colored occupancies together. Which is faster than maintaining a separate, incrementally updated bitboard for it.

[Chessnut1071]

What I don't understand is how a piece can be associated with a ply. And why do you have 33? You also have an entry for an empty square?

The 'number of moves' seems derived information, not part of the game state. Do you calculate that from scratch in every node, by move generation?

The standard way to implement bitboard is to have black and white occupancy boards (possibly implemented as an array occupancy[2]), plus a bitboard for each colored type (pieces[2][6]). In MakeMove() two boards have to be updated for the moved piece as well as its capture viction: the colored occupancy and the board for its colored type. For generating slider moves you would need total occupance, but this can be obtained by just ORing the colored occupancies together. Which is faster than maintaining a separate, incrementally updated bitboard for it.

Your description of the standard implementation is very similar to what I have, however, I keep a separate Piece matrix from which to generate those boards. I also use the Piece data by ply for ent passant and pawn promotion, which I found more difficult to calculate using those bitboards. Anyway, I could use the increase in speed if the bit operations accomplish the same thing. Frustration, every time I think I'm done it's back to the code editor again.