Hi Matthew,
please check your PM.
Sven
Project help required: Bitboard Fruit 2.1
Moderators: hgm, Rebel, chrisw
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Project help required: Bitboard Fruit 2.1
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.syzygy wrote:Well, maybe we should not start a discussion on what is correct English idiom.Sven Schüle wrote: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 wrote:Is there any advantage to a 16x16 board when using bitboards?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.
Makes no sense to consider a bitboard which must use 0-63, and then re-map to 0x88 or anything else...
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Project help required: Bitboard Fruit 2.1
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...Sven Schüle wrote:Agreed And I apologize for my insufficient understanding of correct English idiomssyzygy wrote:Well, maybe we should not start a discussion on what is correct English idiom.Sven Schüle wrote: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 wrote:Is there any advantage to a 16x16 board when using bitboards?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.
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
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Project help required: Bitboard Fruit 2.1
Why do you need 1 and 2 rather than 0 and 1? Does the array really have 3 elements (unknown, white and black)???ZirconiumX wrote:Bob (If I may call you that),
sorry, no. Fruit uses White = 0, Black = 1, viz:
So I had to use the awkward, and ugly hack to get that working.Code: Select all
const int White = 0; const int Black = 1;
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
-
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Project help required: Bitboard Fruit 2.1
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...
-
- Posts: 1334
- Joined: Sun Jul 17, 2011 11:14 am
Re: Project help required: Bitboard Fruit 2.1
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
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
Some believe in the almighty dollar.
I believe in the almighty printf statement.
I believe in the almighty printf statement.
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: Project help required: Bitboard Fruit 2.1
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.bob wrote: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...Sven Schüle wrote:Agreed And I apologize for my insufficient understanding of correct English idiomssyzygy wrote:Well, maybe we should not start a discussion on what is correct English idiom.Sven Schüle wrote: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 wrote:Is there any advantage to a 16x16 board when using bitboards?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.
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
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
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: Project help required: Bitboard Fruit 2.1
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.bob wrote:Why do you need 1 and 2 rather than 0 and 1? Does the array really have 3 elements (unknown, white and black)???ZirconiumX wrote:Bob (If I may call you that),
sorry, no. Fruit uses White = 0, Black = 1, viz:
So I had to use the awkward, and ugly hack to get that working.Code: Select all
const int White = 0; const int Black = 1;
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
Sven
-
- Posts: 4052
- Joined: Thu May 15, 2008 9:57 pm
- Location: Berlin, Germany
- Full name: Sven Schüle
Re: Project help required: Bitboard Fruit 2.1
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 correctZirconiumX wrote:It has a magic bitboard move generator, and generates quiet piece moves only.
Sven
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Project help required: Bitboard Fruit 2.1
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.Sven Schüle wrote: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.bob wrote: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...Sven Schüle wrote:Agreed And I apologize for my insufficient understanding of correct English idiomssyzygy wrote:Well, maybe we should not start a discussion on what is correct English idiom.Sven Schüle wrote: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 wrote:Is there any advantage to a 16x16 board when using bitboards?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.
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
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
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.