Random value compute or table hard coded ?

[NaltaP312]

Hello,

if someone can explain me something :
if i take an engine like sungorus or strelka20b there is two method :
sungorus compute value and strelka20b have hard coded table for random :

Code: Select all

const unsigned __int64 Random[12][64] = {
{ 0x27C06528B11258B9,0x7CF0F94115C5F328,0x36FC1EEE0BFEA395,0x4E768C794FD8160E,
  0x3860CBD0E035FF75,0xF4BB6DD12DD219D8,0x1F5EF298C63766FC,0x7834100D52277DF9,
  0x01F25EC1630A5C37,0xC611DB41D62B9E54,0x39D9E2E106BE16BE,0x1F574CEB79EFDF7A,
  0x5E6279985EF2206D,0x2AE711874E578EAD,0x2CF0C0C4706C4341,0x516EFEF7D9E2232C,.....

if i use the sungorus method in strelka20b, strelka crash with an access violation.

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00000004393c4e60
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 strelka 0x000000010000bc6d evaluate + 5075 (eval.c:305)
1 strelka 0x000000010000a22a qu_check_search + 601 (search.c:780)
2 strelka 0x0000000100009d65 qu_search + 1112 (search.c:696)
3 strelka 0x000000010000a2dc qu_check_search + 779 (search.c:784)
4 strelka 0x0000000100009d65 qu_search + 1112 (search.c:696)

Do you know why strelka crash with this method, and what is the best way ?

Regards
Yves

[syzygy]

Do you know why strelka crash with this method,

Well, your code clearly has a bug. It is not the method that crashes the program, but something you did when implementing the method.

Maybe you didn't properly allocate the memory where you store the random values. Maybe you don't properly reference this memory. Maybe something else is wrong.

and what is the best way ?

Personal preference. I prefer a hardcoded table so I never have to bother about it again. Others will say they prefer a simple random generator so they never have to bother about it again.

[Sven]

Strelka 20B uses (see CONSTS.C):

Code: Select all

const unsigned __int64 RandomTurn = 0x2B5F86B85A7D3E98;
const unsigned __int64 RandomCastle[16] = {...};
const unsigned __int64 RandomEP[8] = {...};
const unsigned __int64 Random[12][64] = {...};

How does your initialization code look now for these data?

Sungorus 1.4 (that's what I found?) uses (see sungorus.h, init.c):

Code: Select all

#define SIDE_RANDOM     (~((U64)0))
...
extern U64 zob_piece[12][64];
extern U64 zob_castle[16];
extern U64 zob_ep[8];
...
for &#40;i = 0; i < 12; i++)
  for &#40;j = 0; j < 64; j++)
    zob_piece&#91;i&#93;&#91;j&#93; = Random64&#40;);
for &#40;i = 0; i < 16; i++)
  zob_castle&#91;i&#93; = Random64&#40;);
for &#40;i = 0; i < 8; i++)
  zob_ep&#91;i&#93; = Random64&#40;);

When implemented correctly, the difference is only in the values being used as zobrist keys. Crashing with SEGV indicates an attempt to access memory in an area where no access is possible. I have no idea how that should happen if you applied something like the Sungorus init code above within Strelka 20B.

Did you try to use a debugger? Should be easy to fix that way.

Sven

[NaltaP312]

Thanks for your response
i will search why this happend

Nonetheless i have just put in comment the table and use the function like this

Code: Select all

board->key ^= getRandom64();//RandomCastle[board->flags];
  if (board->ep_square != 0) board->key ^= getRandom64();//RandomEP[board->ep_square & 7];

with

Code: Select all

unsigned __int64 getRandom64(void)
{
  static unsigned __int64 next = 1;

  next = next * 1103515245 + 12345;
  return next;
}

[zongli]

That seems like a really poor 64 bit LCG.

[Rémi Coulom]

2 points:

First, the random number should always be the same for the same piece/square/ep_square/..., so you cannot generate them like that.

Second, your RNG looks terribly bad. But that should not matter so much.

Rémi

[NaltaP312]

That seems like a really poor 64 bit LCG.

ok for the poor : what do you recommand ?

[NaltaP312]

First, the random number should always be the same for the same piece/square/ep_square/..., so you cannot generate them like that.

Ok i will check this and same time try to found a good random generator for 64 bits.

[zongli]

Here's a simple xorshift PRNG:

Code: Select all

unsigned __int64 getRandom64(void) 
{ 
  static unsigned __int64 x = 11830773696567897325; 
  x ^= x << 21;
  x ^= x >> 35;
  x ^= x << 4;
  return x;
&#125;

It's fast and much better than LCGs (all bits are equally random).

[hgm]

Well, as already mentioned the quality of the random generator is of no importance whatsoever. 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.