Project help required: Bitboard Fruit 2.1

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
syzygy
Posts: 4600
Joined: Tue Feb 28, 2012 10:56 pm

Re: Project help required: Bitboard Fruit 2.1

Post by syzygy » Tue May 08, 2012 10:15 pm

Sven Schüle wrote: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.
Is there any advantage to a 16x16 board when using bitboards?

Sven
Posts: 3867
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by Sven » Tue May 08, 2012 10:18 pm

syzygy wrote:
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 ;)
I think I pointed out a couple of issues in my previous two postings that are responsible for crashing. The one you mentioned isn't an issue if you look at the code in Matthew's posting where BLACK_PIECES_BB etc. is used. Some lines above it almost the same code appears but with 2 and 1 instead of the symbolic constants. These are simply indices into the bitboards[] array.

After fixing the SQUARE_TO_64 issue the engine seems to run somehow.

Sven

Sven
Posts: 3867
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by Sven » Tue May 08, 2012 10:21 pm

syzygy wrote:
Sven Schüle wrote: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.
Is there any advantage to a 16x16 board when using bitboards?
I don't understand your question, do you mean "is there any advantage of a 16x16 board"? If not, can you please explain your question?

syzygy
Posts: 4600
Joined: Tue Feb 28, 2012 10:56 pm

Re: Project help required: Bitboard Fruit 2.1

Post by syzygy » Tue May 08, 2012 10:59 pm

Sven Schüle wrote:
syzygy wrote:
Sven Schüle wrote: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.
Is there any advantage to a 16x16 board when using bitboards?
I don't understand your question, do you mean "is there any advantage of a 16x16 board"? If not, can you please explain your question?
Well, maybe we should not start a discussion on what is correct English idiom.

User avatar
lucasart
Posts: 3109
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by lucasart » Wed May 09, 2012 5:01 am

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?
Umko and DoubleCheck don't segfault on me... Coincidence ?

User avatar
lucasart
Posts: 3109
Joined: Mon May 31, 2010 11:29 am
Full name: lucasart
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by lucasart » Wed May 09, 2012 5:13 am

ZirconiumX wrote: 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; 
Not everything that Fruit does is "right". In this example, I would object that ~own_pieces is not the best way to do this. After many attempts, and lots of self-testing, I've come to the conclusion that you should remove squares occupied by your pawns (not pieces) and defended by enemy pawns. Don also recently said in a post that he was doing the same thing. But again, you need to experiment with these things, there is no absolute rule.
I think you'll learn a lot more about chess programming (and programming per se) by writing your own engine and doing some testing rather than using Fruit's recipies. Even if you end up getting the same conclusion as most top engine, reaching this conclusion that way, you'll have a much deeper understanding of how things should be done.
What happened to your own engine ? Did you drop the project ?

Sven
Posts: 3867
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by Sven » Wed May 09, 2012 11:33 am

syzygy wrote:
Sven Schüle wrote:
syzygy wrote:
Sven Schüle wrote: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.
Is there any advantage to a 16x16 board when using bitboards?
I don't understand your question, do you mean "is there any advantage of a 16x16 board"? If not, can you please explain your question?
Well, maybe we should not start a discussion on what is correct English idiom.
Agreed :-) And I apologize for my insufficient understanding of correct English idioms ;-)

So to answer your question: I don't see any advantage in it but that is not the point IMO. I think Matthew is experimenting with a way to use bitboards in Fruit with as little changes as possible, so initially he tries to keep most of Fruit's internal representation intact, including the 16x16 board stuff. Efficiency is not an issue at this stage. I think this approach is not bad in general. The next steps (after making the current state run correctly) would include removing everything that is now unused or no longer mandatory after introducing bitboards, and then improving and optimizing it. The latter also includes to apply some "obvious" changes, like reducing the number of bitboards per board from 256 to some reasonable number like 8, 9, 12, 13, 14, whatever seems to fit the needs.

Sven

Sven
Posts: 3867
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Project help required: Bitboard Fruit 2.1

Post by Sven » Wed May 09, 2012 11:35 am

lucasart wrote:
ZirconiumX wrote: 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; 
Not everything that Fruit does is "right". In this example, I would object that ~own_pieces is not the best way to do this.
That is not from original Fruit which has no bitboards :-)

Sven

ZirconiumX
Posts: 1327
Joined: Sun Jul 17, 2011 9:14 am

Re: Project help required: Bitboard Fruit 2.1

Post by ZirconiumX » Wed May 09, 2012 2:50 pm

I am basically trying to get a Fruit that runs (approx) ~1.5x current speed. I was not using board->bitboards[0] because I hoped to use the PieceNone256 constant to indicate empty squares.

@Sven
Thank you for your help in this, I shall correct the corrections and report back.

@Lucas
A basic barebones of Magic is under way. I currently have the Interface done, and ermmm not much else ATM.

Matthew:out
Some believe in the almighty dollar.

I believe in the almighty printf statement.

ZirconiumX
Posts: 1327
Joined: Sun Jul 17, 2011 9:14 am

Re: Project help required: Bitboard Fruit 2.1

Post by ZirconiumX » Wed May 09, 2012 2:57 pm

Yay!

The SQUARE_TO_64() macro saved it, thanks Sven!

Matthew:out
Some believe in the almighty dollar.

I believe in the almighty printf statement.

Post Reply