Project help required: Bitboard Fruit 2.1

[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:

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&#40;from,1ULL << from&#41;;

	    mob += population_count&#40;attacks & -board->bitboards&#91;&#40;colour&#41; ? 2 &#58; 1&#93;);

            op&#91;me&#93; += mob * BishopMobOpening;
            eg&#91;me&#93; += 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&#40;from,1ULL << from&#41;; // Umko bishop magics take &#40;square, bitboard&#41;

	    mob += population_count&#40;attacks & -board->bitboards&#91;COLOUR_IS_BLACK&#40;colour&#41; ? BLACK_PIECES_BB &#58; WHITE_PIECES_BB&#93;);

            op&#91;me&#93; += mob * BishopMobOpening;
            eg&#91;me&#93; += mob * BishopMobEndgame;

Download here.

Matthew:out

Note to mods: watch very carefully.

[bob]

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:

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&#40;from,1ULL << from&#41;;

	    mob += population_count&#40;attacks & -board->bitboards&#91;&#40;colour&#41; ? 2 &#58; 1&#93;);

            op&#91;me&#93; += mob * BishopMobOpening;
            eg&#91;me&#93; += 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&#40;from,1ULL << from&#41;; // Umko bishop magics take &#40;square, bitboard&#41;

	    mob += population_count&#40;attacks & -board->bitboards&#91;COLOUR_IS_BLACK&#40;colour&#41; ? BLACK_PIECES_BB &#58; WHITE_PIECES_BB&#93;);

            op&#91;me&#93; += mob * BishopMobOpening;
            eg&#91;me&#93; += mob * BishopMobEndgame;

Download here.

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...

[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.

[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

[syzygy]

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.

[Evert]

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)?

[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).

[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

[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

[syzygy]

@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