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.
Introducing a new multi-purpose penalty related to King safety, which
includes all kind of potential checks (from unsafe or unavailable
squares currently occupied by some other piece)
This will indirectly detect and reward some pins, discovered checks, and
motifs such as square vacation, or rook behind its pawn and aligned with
King (example Black Rg8, g7 against Kg1),
and penalize some pawn blockers (if they move, it allows a discovered
check by the pawn).
And since it looks also at protected squares, it detects some potential
defense overloading.
Finally, the rook contact checks had been removed some time ago. This
test will give a small bonus for them, as well as for bishop contact
checks.
Passed STC
http://tests.stockfishchess.org/tests/view/5729ec740ebc59301a354b36
LLR: 2.94 (-2.94,2.94) [0.00,5.00]
Total: 13306 W: 2477 L: 2296 D: 8533
and LTC
http://tests.stockfishchess.org/tests/view/572a5be00ebc59301a354b65
LLR: 2.97 (-2.94,2.94) [0.00,5.00]
Total: 20369 W: 2750 L: 2565 D: 15054
bench: 9298175
Just use _mm_popcnt_u64() that is available
both for MSVC abd Intel compiler.
Verified on MSVC that the produced assembly
has the hardware 'popcnt' instruction.
No functional change.
