Random value compute or table hard coded ?

[NaltaP312]

You should use the generator to fill the table that otherwise predefines the randoms, though. Not use it dynamically during search.

Many thanks it was this
I have write a initRandom function to fill all arrays :

Code: Select all

unsigned __int64 RandomCastle[16] = {};
unsigned __int64 RandomEP[8] = {};
unsigned __int64 Random[12][64] = {{}};

And not to give a random number during the search or the make unmake move
And now all is fine

Many thanks.

[zongli]

Well, as already mentioned the quality of the random generator is of no importance whatsoever.

Perhaps not if the algorithm is only good for 16 bits. :)

You should use the generator to fill the table that otherwise predefines the randoms, though. Not use it dynamically during search. Because then when you encounter the same position, you would generate a completely different key. So you would retrieve the wrong entry from the TT, which probably will have an invalid hash move for the position, which then will make the engine crash.

Well, most engines verify the hash move, right? The key would just be useless as it becomes random. ^^

[diep]

You should use the generator to fill the table that otherwise predefines the randoms, though. Not use it dynamically during search.

Many thanks it was this
I have write a initRandom function to fill all arrays :

Code: Select all

unsigned __int64 RandomCastle[16] = {};
unsigned __int64 RandomEP[8] = {};
unsigned __int64 Random[12][64] = {{}};

And not to give a random number during the search or the make unmake move
And now all is fine

Many thanks.

Just out of interest - why do you need 16 random numbers for castling?

[diep]

Well, as already mentioned the quality of the random generator is of no importance whatsoever.

Perhaps not if the algorithm is only good for 16 bits.

You should use the generator to fill the table that otherwise predefines the randoms, though. Not use it dynamically during search. Because then when you encounter the same position, you would generate a completely different key. So you would retrieve the wrong entry from the TT, which probably will have an invalid hash move for the position, which then will make the engine crash.

Well, most engines verify the hash move, right? The key would just be useless as it becomes random. ^^

verifying the hashmove is waste of cycles. Why would you waste code on that?

Note i'm using internal 128 bits from which a bit or 70-80 get stored in hashtable (i include lookup into that 70-80).

I had that built in 2003 one day for supercomputer - appeared useless though, but kept it in my code...

Obviously my philosophy is different from others there. My philosophy is that i want 0 collissions, let alone 0 errors, to occur.

That removes simply all kind of deep theoretical research on how big impact of such errors is.

[NaltaP312]

Just out of interest - why do you need 16 random numbers for castling?

It is the Strelka20b code not mine
The source is the following

Code: Select all

const unsigned __int64 RandomCastle[16] = {
  0x0000000000000000,0xC587778E1C593FA8,0xF1A05AA56ECAA853,0x34272D2B729397FB,
  0x3F7E0754A47719EC,0xFAF970DAB82E2644,0xCEDE5DF1CABDB1BF,0x0B592A7FD6E48E17,
  0xA7A6AE9FFD6151F2,0x6221D911E1386E5A,0x5606F43A93ABF9A1,0x938183B48FF2C609,
  0x98D8A9CB5916481E,0x5D5FDE45454F77B6,0x6978F36E37DCE04D,0xACFF84E02B85DFE5
};

[diep]

Just out of interest - why do you need 16 random numbers for castling?

It is the Strelka20b code not mine
The source is the following

Code: Select all

const unsigned __int64 RandomCastle[16] = {
  0x0000000000000000,0xC587778E1C593FA8,0xF1A05AA56ECAA853,0x34272D2B729397FB,
  0x3F7E0754A47719EC,0xFAF970DAB82E2644,0xCEDE5DF1CABDB1BF,0x0B592A7FD6E48E17,
  0xA7A6AE9FFD6151F2,0x6221D911E1386E5A,0x5606F43A93ABF9A1,0x938183B48FF2C609,
  0x98D8A9CB5916481E,0x5D5FDE45454F77B6,0x6978F36E37DCE04D,0xACFF84E02B85DFE5
};

You are building another clone?

Who pays you for that and why?

[NaltaP312]

I'm not building another clone i don't publish engine or particpiate to all engine tournament
i'm just interested about how works a chess engine and try to understand bitboard : just curiosity nothing more.

[zongli]

Well, if castling rights are stored as 4 bits, you can just XOR it out, update it, and XOR it back in. Hence 16 random numbers.

[Daniel Shawul]

Try this hash function to replace (piece,square) hash keys. I tested it with a real chess engine and it did not show much slow down compared to using pre-generated tables.

Code: Select all

U64 hash_cp_sq(int cp,int sq) {
	const U64 C1 = U64(0xeadf018b615d3be8);
	const U64 C2 = U64(0x109951162821a737);
	U64 h = C1;
	h = &#40;h << sq&#41; ^ &#40;h >> &#40;64 - sq&#41;); 
	h += C2;
	h = &#40;h << cp&#41; ^ &#40;h >> &#40;64 - cp&#41;);
	return h;
&#125;

For castling/epsquare hashkeys, find a good 64bit hash key and then rotate it until you have enough. So far there doesn't seem to be a major problem with this method ...

[diep]

Well, if castling rights are stored as 4 bits, you can just XOR it out, update it, and XOR it back in. Hence 16 random numbers.

that requires code special for white and for black.
I dislike that.

Personally i prefer generic code that works for both sides, wherever it is possible...