Project help required: Bitboard Fruit 2.1

[Sven]

Hi Matthew,
please check your PM.
Sven

[bob]

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.

Why would there be ANY square re-numbering when using bitboards... For bitboards, squares 0-63 is the ONLY thing that makes any sense at all. Leaving a 3-bit rank and 3-bit file which is perfect.

Makes no sense to consider a bitboard which must use 0-63, and then re-map to 0x88 or anything else...

[bob]

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

So, apparently, in theory he will do a bitboard move generator and leave everything else alone? That will be weaker. Move generation is not the big CPU cycle burner, but all the translation to an 0x88 will certainly slow things down if he tries to keep the fruit eval intact. Ugh...

[bob]

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

Why do you need 1 and 2 rather than 0 and 1? Does the array really have 3 elements (unknown, white and black)???

[hgm]

Well, there is this Chess variant called 'The Blue Queen', where next to the normal FIDE setup an extra Queen starts at d4, which can be moved by both sides in stead of a move with their own pieces...

[ZirconiumX]

Me and sven have been working behind the scenes on the project, which is why you haven't heard from me recently, so I will provide a short summary of what has happened:

I have shrunk the bitboard array from 256 to 10 slots.
It has a perft and divide function, courtesy of sven.
It has a magic bitboard move generator, and generates quiet piece moves only. Well, I say generate; perft is correct, but search does not provide any (one piece move at root) piece moves whatsoever...

HG, what happens if the blue queen checks both kings at the same time?

Matthew:out

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

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

So, apparently, in theory he will do a bitboard move generator and leave everything else alone? That will be weaker. Move generation is not the big CPU cycle burner, but all the translation to an 0x88 will certainly slow things down if he tries to keep the fruit eval intact. Ugh...

The project is in a very early stage, so no need to judge at that point ... I can almost assure you that "keeping the fruit eval intact" is not among Matthew's goals. But before changing the eval from mailbox to bitboards it is clear that the basic infrastructure must be working first.

And I think it is also a "learning project", not (yet) a "world class engine development project", so one has to apply different standards.

Sven

[Sven]

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

Why do you need 1 and 2 rather than 0 and 1? Does the array really have 3 elements (unknown, white and black)???

The reasons for using 1 and 2 as indices have gone in the meantime, but at that time it was really an array with more than 3 elements where the two color bitboards were at positions 1 and 2 and bitboard no. 0 had a different meaning. This has been changed now, so the discussion is obsolete.

Sven

[Sven]

It has a magic bitboard move generator, and generates quiet piece moves only.

To be more precise: it generates all moves but only the generation of quiet non-pawn moves does already use the magic bitboard generator (for sliders) or bitboard logic (for king/knight) at the moment. Otherwise "perft" could not be correct

Sven

[bob]

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

So, apparently, in theory he will do a bitboard move generator and leave everything else alone? That will be weaker. Move generation is not the big CPU cycle burner, but all the translation to an 0x88 will certainly slow things down if he tries to keep the fruit eval intact. Ugh...

The project is in a very early stage, so no need to judge at that point ... I can almost assure you that "keeping the fruit eval intact" is not among Matthew's goals. But before changing the eval from mailbox to bitboards it is clear that the basic infrastructure must be working first.

And I think it is also a "learning project", not (yet) a "world class engine development project", so one has to apply different standards.

Sven

My experience doing EXACTLY this project (Cray Blitz -> Crafty) says this is the wrong way to do it. You end up debugging code that is going to be thrown away. You first map from 0-63 to 0-127, and then you still have to change the eval and debug it. There are ways of testing the move generator without any eval or search whatsoever. First thing I wrote in Crafty was the move generator. I went no further until it was working correctly.

I suppose one can develop however they want, I'm old enough that I don't want to waste ANY time, for obvious reasons -- one is there is not that much time left to waste.