Position flipping

[bob]

I also use a constant format for book, based on writing individual characters, so that endian is not an issue. Did this a long while back as I burned myself a few times when moving back and forth from the PC to a Sun Sparc, or a Sparc to a Dec alpha.

The routines to use are from the ntohl() and htonl() family. But there is no guarantee that there will be local support for eight byte integers. (Or doubles, either, I suppose.)

I wrote my own:

Code: Select all

bool ReadNet64(std::ifstream *ifsptr, ui64& value)
{
  bool okay = true;
  ui index = 0;

  value = 0;
  while &#40;okay && &#40;index < QwrdByteLen&#41;)
  &#123;
    char byte;

    ifsptr->read&#40;&byte, 1&#41;;
    if (*ifsptr&#41;
    &#123;
      value |= (&#40;ui64&#41; &#40;ui8&#41; byte&#41; << (&#40;QwrdByteLen - 1 - index&#41; * ByteBitsLen&#41;;
      index++;
    &#125;
    else
    &#123;
      value = 0;
      okay = false;
    &#125;;
  &#125;;
  return okay;
&#125;

bool WriteNet64&#40;std&#58;&#58;ofstream *ofsptr, const ui64 value&#41;
&#123;
  bool okay = true;
  ui index = 0;

  while &#40;okay && &#40;index < QwrdByteLen&#41;)
  &#123;
    const char byte = &#40;char&#41; &#40;value >> (&#40;QwrdByteLen - 1 - index&#41; * ByteBitsLen&#41;);

    ofsptr->write&#40;&byte, 1&#41;;
    if (*ofsptr&#41;
      index++;
    else
      okay = false;
  &#125;;
  return okay;
&#125;

I teach the htonl and friends in my network programming class. But for my book, I rolled my own since it runs on all sorts of operating systems, compilers, and architectures. I have functions like BookIn32(), BookOut32() and such. I have to write learn values (floats), as well as counters that can be 32 or 64 bits...

[michiguel]

If a chess program has the capability to run a search deterministically (no randomness, single threaded, stops at fixed limit of a node count or iteration, not time), then a position flip could be used to verify the search color-blindness.

Run a deterministic search with a position, then run the same search with the flipped position. All search results should be identical.

Only if you disable the hashtable. The zobrists will destroy this unless you completely flip them, but that is certainly not worth the trouble.

Miguel

[bob]

If a chess program has the capability to run a search deterministically (no randomness, single threaded, stops at fixed limit of a node count or iteration, not time), then a position flip could be used to verify the search color-blindness.

Run a deterministic search with a position, then run the same search with the flipped position. All search results should be identical.

Only if you disable the hashtable. The zobrists will destroy this unless you completely flip them, but that is certainly not worth the trouble.

Miguel

I think that's what he was talking about. He had mentioned flipping the hash signature as well. Whether he means actually "flipping the zobirst numbers as well I don't know, however.

I only use it to look for eval asymmetries. Used to be very common since I had black and white code separate. Since I don't, the most common bug now (and they are rare) is the right-left issue where I do something stupid like check the file to the left of the pawn, but not the right. "flop" will highlight that instantly.

[sje]

I teach the htonl and friends in my network programming class. But for my book, I rolled my own since it runs on all sorts of operating systems, compilers, and architectures. I have functions like BookIn32(), BookOut32() and such. I have to write learn values (floats), as well as counters that can be 32 or 64 bits...

It's likely that htonl() and its pals are more efficient than my approach as they support multibyte data transfer on a single I/O call.

Concerned about inefficiency, I did some timing and found that Symbolic's biggest book could be read into memory, one byte per I/O call, in under 400 milliseconds. That's not too much time to spend on something which occurs only once per program invocation.

Code: Select all

[2013.08.08 19:33:08.150] Loading opening book
[2013.08.08 19:33:08.534]   Opening book entry count: 226,912
[2013.08.08 19:33:08.534]   Opening book memory size: 7,261,184

[sje]

Only if you disable the hashtable. The zobrists will destroy this unless you completely flip them, but that is certainly not worth the trouble.

You are correct in that a different transposition table collision pattern will occur because of different hashes for the flipped root position and its descendants. Obviously, this could affect the search.

So the Zobrist code tables would also have to be flipped. But this is not too hard to do; instead of one code table, there would be two such that:

Hash(P, table0) == Hash(Flip(P), table1)