Complete rewrite the function and extend compatibility
also to X-FEN notation for Chess960.
We are now able to read standard FEN, Shredder-FEN and X-FEN.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
After 'Randomness' is retired, this is no longer necessary.
NOTE: Possibly some extra care is needed when tuning branch is synced
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Using multiple threads and good opening book is
much better and more reliable source of randomness than
spoiling psqt-tables
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Let be explicit about what this functions do, and
we save some code lines too.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
After we set ss->threatMove we could go under a IID step that
resets SearchStack ss and so also ss->threatMove.
When later we use that field in futility pruning we have this
set to MOVE_NONE !
The fix is to use a local variable and add threatMove to SplitPoint
to pass this move to slaves.
Spotted by Ralph Stoesser, fix suggested by Richard Vida.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Improvement is easily in error bar and there is
some added complexity making future changes more
difficult.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Because not all backward pawns are the same ;-) if the
blocking enemy pawn is near then our pawn is more backward
than another whose enemy pawn is far away so that can advance
for some sqaures.
After 2925 games at 30"+0 on my QUAD
Mod vs Orig +602 =1745 -578 +3 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Update outdated and even misleading documentation.
Also check #include-directives
No functional change
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
These functions have little to do with TranspositionTable
class and more with the search and in particular with the PV
handling. So move them where they belong.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
So to maximize the possibility to avoid to recalculate it
in the future. A small speed-up of 0.8%
Idea by Ralph Stoesser.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
The seocond check is no more needed now and
anyhow is wrong to overwrite a TT entry if
present.
Spotted by Ralph Stoesser.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
KILLER_MAX in search.h is quite pointless, because
we already hardcode this to 2 in MovePicker anyway.
By hard-coding this to 2 we can keep code simpler.
No functional change
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is more clear and also more correct because we
consider enemy pawns only in fornt of us and not just
on our file.
Very small functional change, almost not measurable, but
keep the patch for documenting purposes.
Spotted by Marek Kwiatkowski.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Almost no change so commit because is a pruning
reduction patch.
After 1088 games at 1'+0 with QUAD
Mod vs Orig +178 =727 -183 (-2 ELO)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We don't need to pass side_to_move because we can get
it directly from the position object.
Note that in benchmark we always used to pass '0' and
it was a bug, but with no effect because was used only
in time[] and increment[], set always to 0 for both
colors.
Also additional small cleanup while there.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Considering only VALUE_TYPE_EXACT nodes is too
restrictive and has a number of side-effects, most
notably the truncation of PV line after a fail high
at root.
Note that in this way we are no more guaranteed that
PV line is built up with PV nodes only, because
it could happen that a side search overwrites with a
cut-off move a PV node and this cut-off move ends up
in PV.
Change should be almost not measurable, perhaps with
ponder on we could have some beneficial effect.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Currently starting from depth 12*OnePly on we have a verification
search deeper then the null search.
Note that, although reduction is R we start from one ply less then
null search, so actually we reach a depth that is OnePly shallower
then null search.
After 1130 games at 1'+0 on QUAD
Mod vs Orig +202 =756 -172 +9 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
After the previous patch, it's impossible to build
anything else than x86 32-bit binary!
So revert.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Tested with Orig set at f5ef5632f so to evaluate
direct gain against 1.8
After 3239 games at 10"+0.1
Mod vs Orig +701 =1906 -632 +7 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Unfortunatly the source of this issue is not in the
different handling of log(0) illegal value.
No functional change on MSVC.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It happens that when d == 0 we calculate:
log(double(0 * 0) / 2)
Unfortunately, log(0) is "illegal" and can generate either a
floating point exception or return a nonsense "huge" value
depending on the platform.
This fixs in the proper way the GCC/ICC rounding difference,
bug was from our side, not in the intel compiler.
Also fixed some few other warnings.
Bug spotted by Richard Lloyd.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
