Page 1 of 7
Project help required: Bitboard Fruit 2.1
Posted: Tue May 08, 2012 5:20 pm
by ZirconiumX
I have the
extreme barebones of a bitboard Fruit in the works, however it segfaults on me pretty much all the time.
I use the Umko/DoubleCheck GPLv3 Magic bitboard generator, and this seems to be the problem, as GDB reports that it oddly segfaults at a certain call to bishop_attacks(), coincidence hmmm?
At the moment it is only used for sliding piece mobility evaluation, but I did say extreme barebones.
Now I know that this is extremely ironic, what with the Rybka/Fruit debate, but hey, I get public domain "might have been" snapshots, such as:
Robert Hyatt wrote:
Code: Select all
attacks = bishop_attacks(square);
mob = popcnt(attacks & ~own_pieces);
opening += mob * BishopMobOpening;
endgame += mob * BishopMobEndgame;
And, oddly, my implementation looks like this:
Code: Select all
attacks = bishop_attacks(from,1ULL << from);
mob += population_count(attacks & -board->bitboards[(colour) ? 2 : 1]);
op[me] += mob * BishopMobOpening;
eg[me] += mob * BishopMobEndgame;
Yes, I apologise to Fabien Letouzey, and all of the other programming Gods for making it extremely hard to understand, and for breaking the "low memory footprint" ideology (it uses the xxx256 as it appears to be the most commonly used) but basically:
Code: Select all
attacks = bishop_attacks(from,1ULL << from); // Umko bishop magics take (square, bitboard)
mob += population_count(attacks & -board->bitboards[COLOUR_IS_BLACK(colour) ? BLACK_PIECES_BB : WHITE_PIECES_BB]);
op[me] += mob * BishopMobOpening;
eg[me] += mob * BishopMobEndgame;
Matthew:out
Note to mods: watch very carefully.
Re: Project help required: Bitboard Fruit 2.1
Posted: Tue May 08, 2012 5:31 pm
by bob
ZirconiumX wrote:I have the
extreme barebones of a bitboard Fruit in the works, however it segfaults on me pretty much all the time.
I use the Umko/DoubleCheck GPLv3 Magic bitboard generator, and this seems to be the problem, as GDB reports that it oddly segfaults at a certain call to bishop_attacks(), coincidence hmmm?
At the moment it is only used for sliding piece mobility evaluation, but I did say extreme barebones.
Now I know that this is extremely ironic, what with the Rybka/Fruit debate, but hey, I get public domain "might have been" snapshots, such as:
Robert Hyatt wrote:
Code: Select all
attacks = bishop_attacks(square);
mob = popcnt(attacks & ~own_pieces);
opening += mob * BishopMobOpening;
endgame += mob * BishopMobEndgame;
And, oddly, my implementation looks like this:
Code: Select all
attacks = bishop_attacks(from,1ULL << from);
mob += population_count(attacks & -board->bitboards[(colour) ? 2 : 1]);
op[me] += mob * BishopMobOpening;
eg[me] += mob * BishopMobEndgame;
Yes, I apologise to Fabien Letouzey, and all of the other programming Gods for making it extremely hard to understand, and for breaking the "low memory footprint" ideology (it uses the xxx256 as it appears to be the most commonly used) but basically:
Code: Select all
attacks = bishop_attacks(from,1ULL << from); // Umko bishop magics take (square, bitboard)
mob += population_count(attacks & -board->bitboards[COLOUR_IS_BLACK(colour) ? BLACK_PIECES_BB : WHITE_PIECES_BB]);
op[me] += mob * BishopMobOpening;
eg[me] += mob * BishopMobEndgame;
Matthew:out
Note to mods: watch very carefully.
First, I assume you use the usual black=0, white=1? If so, I don't see the need for the conversion to 1 or 2? C uses array indices of 0 ... N-1, so it would be far more natural, and much easier to read, to do something like
mob = popcnt(attacks);
or
mob = popcnt(attacks & ~occupied[color]) if you want to exclude counting squares that your pieces occupy...
It should be hard for a correct magic generator to segfault, that would likely mean that some of the initializing data was not properly set up...
Re: Project help required: Bitboard Fruit 2.1
Posted: Tue May 08, 2012 6:12 pm
by hgm
Interesting. I was considering to make a mailbox version of Ippolit. But I am not sure how 'contaminated' that engine is still considered to be.
Re: Project help required: Bitboard Fruit 2.1
Posted: Tue May 08, 2012 7:06 pm
by ZirconiumX
Bob (If I may call you that),
sorry, no. Fruit uses White = 0, Black = 1, viz:
Code: Select all
const int White = 0;
const int Black = 1;
So I had to use the awkward, and ugly hack to get that working.
H.G.,
that would be, ermm, interesting.
(I'd take it - I have to use a PowerPC mac, so all the inbedded INTEL macros are damned annoying. (And when you change them to universal macros it segfaults.))
Matthew:out
Re: Project help required: Bitboard Fruit 2.1
Posted: Tue May 08, 2012 8:43 pm
by syzygy
ZirconiumX wrote:Bob (If I may call you that),
sorry, no. Fruit uses White = 0, Black = 1, viz:
Code: Select all
const int White = 0;
const int Black = 1;
So I had to use the awkward, and ugly hack to get that working.
Then put the white pieces in element 0, black pieces in element 1?
Or if you somehow are forced to use element 2 for white, element 1 for black, then use "2 - colour" as index.
Do you realise that attacks = bishop_attacks(from,1ULL << from) gives you a bitboard representing the attacks of a sole bishop on an otherwise empty board? You could as well do bishop_attack(from, 0), since the "1ULL << from" is masked out anyway during the calculations.
The line
Code: Select all
mob += population_count(attacks & -board->bitboards[COLOUR_IS_BLACK(colour) ? BLACK_PIECES_BB : WHITE_PIECES_BB]);
seems to index the board->bitboard[] array by a
bitboard, which is bound to crash your program.
Re: Project help required: Bitboard Fruit 2.1
Posted: Tue May 08, 2012 10:34 pm
by Evert
ZirconiumX wrote:
sorry, no. Fruit uses White = 0, Black = 1, viz:
Code: Select all
const int White = 0;
const int Black = 1;
So I had to use the awkward, and ugly hack to get that working.
I've always found white=0, black=1 to be more intuitive, but apart from that I don't see how it matters one way or the other. Why would you need a "hack" (ugly or otherwise)?
Re: Project help required: Bitboard Fruit 2.1
Posted: Tue May 08, 2012 10:41 pm
by hgm
Well, using (x?2:1) when you know x can only be 0 or 1 is always very bad practice, because the compiler might not be smart enough to know that x can only be 0 or 1, and might generate expensive code (with branches) to compute it. While the expression under those conditions is equivalent to x+1 which, when used as an array index, can be optimized away completely. (a[x+1] = (a+1)[x], where a is a constant).
Re: Project help required: Bitboard Fruit 2.1
Posted: Tue May 08, 2012 10:43 pm
by Sven
Hi Matthew
In your version of move_do.cpp, the way you update your bitboards differs heavily between the functions square_clear() and square_set(). In square_clear() you are using piece_12.
Also, from looking at your changes it is not obvious which of the bitboards you are using for "all empty squares" resp. "all occupied squares".
If the version you offered for download is still up to date regarding the point above then your program will crash due to wrong board updates. This might be a reason for getting a crash at some point in time.
I therefore strongly suggest that you run "perft" tests until your modifications of board representation, make/unmake, attack generation and move generation are working perfectly. Only then I would start looking at the evaluation.
Have you also tried the debug version by compiling with the DEBUG preprocessor switch? That activates the ASSERT macro which is the most powerful debugging tool of the whole Fruit engine. Invalid or inconsistent operations on the board should be found quickly that way.
Finally, please consider to remove "Book.bin" from the archive you offer for download, that reduces its size quite a bit
@Ronald: BLACK_PIECES_BB and WHITE_PIECES_BB are most probably constants with the values 2 and 1 and seem to be meant as indices into the bitboards[] array denoting the "all black pieces" and "all white pieces" bitboards, respectively. So I don't think these are an issue.
Sven
Re: Project help required: Bitboard Fruit 2.1
Posted: Wed May 09, 2012 12:09 am
by Sven
You need to convert square numbers that are in the range 0..255 into those in the range 0..63 (using SQUARE_TO_64) before indexing any of the magic_bb_xxx arrays. Maybe you can do this within bishop_attacks(), rook_attacks() etc.
Sven
Re: Project help required: Bitboard Fruit 2.1
Posted: Wed May 09, 2012 12:11 am
by syzygy
Sven Schüle wrote:@Ronald: BLACK_PIECES_BB and WHITE_PIECES_BB are most probably constants with the values 2 and 1 and seem to be meant as indices into the bitboards[] array denoting the "all black pieces" and "all white pieces" bitboards, respectively. So I don't think these are an issue.
If the code runs at all, you must be right
