Page 1 of 1
Board without color flags
Posted: Sat Oct 31, 2009 4:35 pm
by LoopList
Hi!
Dose anyone has experiences with a chessboard without color flags?
It should't be a problem while generating moves, doing/undoing moves and evaluating withing the scope of a bitboard engine.
Many parts of the chess engine will get easier and the distinction between white and black is redundant.
?
Re: Board without color flags
Posted: Sat Oct 31, 2009 4:45 pm
by Gerd Isenberg
LoopList wrote:Hi!
Dose anyone has experiences with a chessboard without color flags?
It should't be a problem while generating moves, doing/undoing moves and evaluating withing the scope of a bitboard engine.
Many parts of the chess engine will get easier and the distinction between white and black is redundant.
?
I actually color-flip the board vertically after each move and have white to move always. Works fine. One quad-bb,
hashkey[piece][color][sq] == byteswap(hashkey[piece][other(color)][sq^56]).
Re: Board without color flags
Posted: Sat Oct 31, 2009 7:23 pm
by LoopList
What are the drawbacks of writing chessboard-related code for White and Black?
Pros:
Special code is easy to develop and to debug.
Special code is probably faster?!
Cons:
Redundant codes.
Changes and improvements have to be done twice.
Unintended assymetries are more likely.
The question arises, why many engine developers are using one general code for White and Black und no special code?
Re: Board without color flags
Posted: Mon Nov 02, 2009 1:43 am
by Michael Sherwin
LoopList wrote:What are the drawbacks of writing chessboard-related code for White and Black?
Pros:
Special code is easy to develop and to debug.
Special code is probably faster?!
Cons:
Redundant codes.
Changes and improvements have to be done twice.
Unintended assymetries are more likely.
The question arises, why many engine developers are using one general code for White and Black und no special code?
I do not know if I am qualified to answer this one. However, Gerd's approach interest me for one reason--moves would be generated identically no matter which color was on move from the moving side. This would allow a greater degree consistency of search and evaluation. Others are looking for evaluation symmetry, cash friendliness, or just clean abstraction of code.
Re: Board without color flags
Posted: Mon Nov 02, 2009 10:48 pm
by Gerd Isenberg
LoopList wrote:What are the drawbacks of writing chessboard-related code for White and Black?
Pros:
Special code is easy to develop and to debug.
Special code is probably faster?!
Cons:
Redundant codes.
Changes and improvements have to be done twice.
Unintended assymetries are more likely.
The question arises, why many engine developers are using one general code for White and Black und no special code?
One way to avoid duplicate, harder to maintain and more error prone color dependent code without a loss of its speed is to use color/side as compile time parameter, either as inlined C++ templates or as const parameters of inline functions.
Re: Board without color flags
Posted: Mon Nov 02, 2009 11:09 pm
by bob
LoopList wrote:What are the drawbacks of writing chessboard-related code for White and Black?
Pros:
Special code is easy to develop and to debug.
Special code is probably faster?!
Cons:
Redundant codes.
Changes and improvements have to be done twice.
Unintended assymetries are more likely.
The question arises, why many engine developers are using one general code for White and Black und no special code?
Several reasons, but the most serious is that duplicated code is much harder to maintain. I can't count the number of times I found asymmetries in something caused by a difference in the way black and white were handled. I added special debug code in Crafty specifically to help catch this in the evaluation, since each piece type and color had specific code. Not the way to develop bug-free code. Current crafty has none of this stuff. It is much smaller, easier to maintain and easier to modify since a change only has to be done once.
Re: Board without color flags
Posted: Tue Nov 03, 2009 8:03 am
by LoopList
Gerd Isenberg wrote:LoopList wrote:What are the drawbacks of writing chessboard-related code for White and Black?
Pros:
Special code is easy to develop and to debug.
Special code is probably faster?!
Cons:
Redundant codes.
Changes and improvements have to be done twice.
Unintended assymetries are more likely.
The question arises, why many engine developers are using one general code for White and Black und no special code?
One way to avoid duplicate, harder to maintain and more error prone color dependent code without a loss of its speed is to use color/side as compile time parameter, either as inlined C++ templates or as const parameters of inline functions.
I don't really understand how to color-flip the board vertically after each move in an
efficient way? Could you give me an example? And how many bitboards do you have? Do you need a board-vector, such as
?
I am currently using the following code for board representation:
Code: Select all
int king_sq[COLORS];
int piece_ct[COLORS];
int pawn_ct[COLORS];
int knight_ct[COLORS];
int bishop_ct[COLORS];
int rook_ct[COLORS];
int queen_ct[COLORS];
bitboard_t piece_bb[COLORS];
bitboard_t pawn_bb[COLORS];
bitboard_t knight_bb[COLORS];
bitboard_t bishop_bb[COLORS];
bitboard_t rook_bb[COLORS];
bitboard_t queen_bb[COLORS];
Thanks
Fritz
Re: Board without color flags
Posted: Tue Nov 03, 2009 8:20 am
by Gerd Isenberg
LoopList wrote:
I don't really understand how to color-flip the board vertically after each move in an
efficient way? Could you give me an example? And how many bitboards do you have? Do you need a board-vector, such as
?
Nope. I use a vector of four bitboards (quad-bb) as one and only board representation where a "vertical" nibble contains the piece code. One of those four bitboards represents the color of the pieces, the union of the three others the occupancy. To color-flip this board, four bswaps are needed, plus ones' complement and intersection with the occupancy of the color board. Incremental hashkey of the position is byte swapped as well.