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().
Use indexSpan instead. This could be a teoretical
slwo down becuae we repalce some shifts by divide
and modulo, but this should not be measurable and
instead the code is more understandable now. This
is a big plus becuase this part of code is complex.
Just use the equivalent Ptwist[], renamed in
MapToEdges[] to indicate that gives highest
score to pawns near the edge and then, as
second order, to bottom rank squares.
We currently check onnly first key, while
we shoudl check both, as confirmed by
author on talkchess:
http://www.talkchess.com/forum/viewtopic.php?t=59947&start=30
This bug fix do not change functionality, we simply
find earlier the DTZ entry instead of reload it.
