We don't need to evaluate the position if it
is already cached in TT. We already do this
in non-PV case.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This is what actually is.
A standard naming convention suggests to name a variable
with someting resembling _what_ the variable is and not
_how_ the variable is used. This normally results
in easier to read code.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
A bigger "safety" value is actually a bigger
threat for the king, so it is a bigger "danger"
With this renaming "Cowardice" and "Aggressiveness"
UCI parameters become easier to understand.
It is also easier to understand why the once "safety"
value (that is a "danger") is subtracted from evaluation
instead of being added.
No functional change.
Use a Weights[] array instead of named variables to
store evaluation weights.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
More aggressive LMR reductions.
Tested at different time controls:
- Tested with 1CPU 1+0, after 3000 games, result was +12 ELO
- Tested this with 4CPU 1+0 and got sth around 5-10 ELO increase
- Last one at long time control,after ~1000 games with 10+0 result is:
Orig - Mod: 491 - 520 (+10 elo)
A testing marathon by Joona for this important change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Master thread returns from idle_loop() when sp->cpus == 0,
but cpus is decremented by slave threads under sp->lock,
so it could happen that we return in split(), where we release
the split point, with sp->lock still held.
This patch guarantees that sp->lock is released when returning
to split().
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
The idea here is that if we cut-off after a stand pat the
already exsisting TT entry was not usable with current
beta, so overwrite anyway.
After 999 games at 1+0
Mod vs Orig +173 =665 -161 + 4 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Almost no change and simplifies a bit the code.
After 961 games at 1+0
Mod vs Orig +156 =650 -146 +4 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Re-save the same TT entry if value is usable and allow
us to cut-off, it means that entry is valuable and
we want to keep it fresh updating the 'generation'
parameter up to the current value.
Patch suggested by J. Wesley Cleveland and better
clarified by Miguel A. Ballicora.
After 999 games at 1+0 64MB hash size
Mod vs Orig +167 =677 -155 +4 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In this case we avoid to name the 'black' version of the
endgame function but use a vector indexed by color instead.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Because exit_threads() references the global object TM, we
need to call the function when still inside main(), otherwise,
due to undefined global object initialization and destruction
we could end up with referencing an already destroyed object.
Actually this should not happen because Application singleton
is initialized _only_ after all the other globals due to how
Application::initialize() is defined, but this is very tricky
C++ and not easy to follow, even for me ;-)
Also rearranged a bit main() code flow.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Moved evaluation of unstoppable pawns out of
evauation of passed pawns because event frequency is
much lower. Added evaluate_unstoppable_pawns() that
is called very seldom and contains all the unstoppable
pawn logic.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Should be a very minor change, but there is a small
functional change because futility_margin() is used in more
places then in the pruning formula.
After 999 games at 1+0
Mod vs Orig +167 =678 -154 +5 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Also fix dimension of UnpairedPawnsTable[] to accomodate the
case in which we have 8 unpaired pawns, i.e. only one side has
pawns, the other side has no pawns.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
The idea is to reduce the score if we have many
pawns opposing an enemy pawn so that the draw
possibility increases.
Just introduced the logic, but no functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
A pawn is candidate to be passed if doesn't have enemy pawns
in just front of him, not also behind !
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Absolutely no useful at all, just code obfuscation so
use real definition instead.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It will be used to lookup squares in front of
a given square. Same concept of PassedPawnMask[]
and OutpostMask[].
Also small tweaks in bitboard.h
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Now with:
stockfish bench 128 1 5 default perft
it is possible to get perft 5 results of each position and
the first 3 positions correspond to the well known test
position in:
http://chessprogramming.wikispaces.com/Perft+Results
This allow to quickly check for perft consistency running
the 'bench' command.
No functional change but signature has changed because
bench default positions 2 and 3 have changed.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Revert all the patches that introduced the change and
more or less fixed the zugzwang issue.
There is a gain against last current version and we
can remove a lot of code.
After 979 games at 1+0 on my QUAD
Mod vs Orig +152 =688 -139 +5 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Real search is considered of higher quality then null
search one.
This allows to fix the zugzwang issue with a minimal
impact on ELO.
Zugzwang verified on position:
8/7P/8/8/K2b4/p7/1k6/1B6 b - -
After 999 games at 1+0 on my QUAD
Mod vs Orig(94bb196) +168 =657 -174 -2 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Is a boolean option that when set allows Stockfish
to select the best book move across the possible ones.
Feature requested by Salvo Spitaleri.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
