Project help required: Bitboard Fruit 2.1

[hgm]

Well, I don't know. As programmer you would control which method you use. And keeping the same square number system as the code you are gradually replacing seems a good way to avoid bugs due to (missing) conversion between number systems.

If you would write all loops over squares in your bitboard initialization code as

Code: Select all

#define BIT2SQ(b) squareNr[(b)*DEBRUIN>>58]

for&#40;b=1; b; b<<=1&#41; &#123;
  int sq= BIT2SQ&#40;b&#41;;
  ...
&#125;

you could easily switch back to a 0-63 system after you got rid of all 0x88 code, just by filling the squareNr table differently.

[Sven]

Well, I don't know. As programmer you would control which method you use. And keeping the same square number system as the code you are gradually replacing seems a good way to avoid bugs due to (missing) conversion between number systems.

If you would write all loops over squares in your bitboard initialization code as

Code: Select all

#define BIT2SQ(b) squareNr[(b)*DEBRUIN>>58]

for&#40;b=1; b; b<<=1&#41; &#123;
  int sq= BIT2SQ&#40;b&#41;;
  ...
&#125;

you could easily switch back to a 0-63 system after you got rid of all 0x88 code, just by filling the squareNr table differently.

That might be true. But in case of Fruit, it still requires a lot of code changes to even reach that state.

Sven

[bob]

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.

What is wrong for you is not necessarily wrong for others. In the given case, adding bitboard code to Fruit does not imply "debugging code that is going to be thrown away". Such code would be part of the original Fruit code (mailbox) which we certainly may assume to be sufficiently debugged.

No. The code needed to remap from 0-63 into 0-127...

Not needed. That was the code that I was talking about.

The strategy chosen here is one of several valid ways in my opinion, whether you like it or not. Please be aware that this is an "experimental" and "learning" project, not necessarily a "writing a new world class engine" project. As soon as move generation, eval and search are changed such that they no longer use the mailbox board apart from looking up the piece type on an occupied square (which could be done with bitboards as well but is probably a tiny bit faster with a redundant mailbox board), the 16x16 mailbox board can be replaced by a simple 8x8 board, and a lot of unused original Fruit mailbox code can go away. Doing it step by step while keeping the whole program's functionality intact at any time is something I would always recommend, for virtually all kinds of software, when doing a "translation" or "port". Obviously you won't do it like that when you write something completely new, but that is not the given situation.

Most of this translation is merely technical. The interesting part, of course, is to rewrite the evaluation such that it really takes advantage of the bitboard data structures.

Finally, nobody wants you to waste your precious time for that. But in that case I propose not to say "that' wrong what you do" to someone else even though you appear to be not much interested in that project. The other option would be to let others make their own experiences.

Sven

My general approach is to try to point out better ways to do something when it might be helpful. Anyone can choose to accept or ignore any advice I give without fear of anything...

But since I have actually done this once, on a pretty large program, experience is a good teacher...

[bob]

Just wondering: is there any reason why 0-63 square numbering would be better than 0x88 numbering, when using bitboards? When I would do a project like this (where old and new structures have to coexist during a transient period) I would try to keep the original structure as much as possible. It seems the square numbers in the bitboard code are only used to index tables of bitboards, and the tables could be given size 128 as easily as size 64. If you are worried about the unused elements of the 0x88 boards spoiling cache efficiency (which I am not sure the Fruit mailbox code does to begin with), you can always interleave different tables (using a "#define table2 (table1+8)").

You are sort of stuck with 0-63 in bitboards, until we see 128 bit machines.

[hgm]

Not really. We already had 64-bit bitboards when we only had 32-bit machines.

But I was not proposing to change the size of the bitboards, of course. Just the numbering of the bits.

[ZirconiumX]

I think that GCC supports the __int128 data type on some machines.

Matthew:out

[ZirconiumX]

OK - I swear that the move generator must be cursed or something...

Today I added bitboard quiet pawn moves.

Perft returns the correct result.

And lo!

Score : 0.00
Depth : 63/1
Time : 00:00:01
Nodes : 1368
N/sec : 1323
1. Nc3

I am seriously confused, as root moves are correct, but the main search sorted list buggers it.

Matthew:out

[Evert]

Yes.
Sjaak uses it.