Call both new and reference functions in parallel
and verify return values match.
Log to file any difference to allow debugging while
playing real games.
Currently we return as soon as we reach
beta. This makes the bench signature to
depend on the move order in case we have
more than one possible capture and only
one of them reach beta then the nodes
searched are different in case we first
test one capture or the other.
Verify that the best value found by the
two move llops are the same. This check
will allow to remove old loop, replaced
by new one.
Currently we sort leading pawns before
to flip. This is ok becuase MapPawns[] is
(almost) flip invariant apart for the case
of two symmetric non-leading pawns like the
case of d2, e2, h2.
After MapPawns[] sorting we have h2, d2, e2
with values 46, 11, 10. Then we flip because
leading pawns is in h2 -> a2,e2,d2 with values
46,10,11. So this is not sorted anymore.
The fix is to sort after flipping. And instead
of forst sorting just pick the leading pawn
directly.
Ronald de Man says:
This difference has to do with the fact that the "sparse index"
does not point to "k * d->span", but to "k * d->span + d->span / 2".
Since k = idx / d->span, we know that k * d->span <= idx,
so k * d->span is a valid index into the table.
But k * d->span + d->span / 2 might be a value that is bigger than
the largest index for the table (if "idx" happens to be near the
end of the table).
So the last valid entry in the SparseIndex[] array might have
to a point to a block and (sub)index that is not part of the
real table but comes "after" it. To make this work, the generator
adds entries for a few "fake" blocks, each of maximum size 65536,
to the blockLength[] array so that there is something to point to
for the last valid entry in the SparseIndex[] array.
These fake blocks do not correspond to any compressed data.
So the fake blocks avoid the need to detect and handle this special
case in decompress_pairs().
