Check for an available slave early on

Don't take the split lock if we don't have
available slaves (about 30-40% of times).

This new condition allows to retire the now
redundant one on number of threads.

No functional change.

Use unsigned char as argument of std::isspace

Although signature allows an int:

int isspace( int ch );

The behavior is undefined if the value of ch is
not representable as unsigned char and is not
equal to EOF.

See

http://en.cppreference.com/w/cpp/string/byte/isspace
http://www.greenend.org.uk/rjk/tech/cfu.html

This is really a tricky corner case of C standard!

Spotted and reported by Ron Britvich.

No functional change.

Avoid to use nullChild

Use instead:

(ss-1)->currentMove == MOVE_NULL

No functional change.

Remove 'update gains' hack

Use (move != MOVE_NONE) condition to
filtering out updating gains at root.

bench: 8454456

Temporary revert previous patch

Split previous patch in 2 steps: first remove
the MOVE_NULL hack, then retire nullChild.

The first step is a prerequisite
for second one and affects bench.

The second step (next patch) just removes nullChild
without affecting bench.

bench: 8205159

Avoid to use nullChild

Should be a non functional change, but
for some reason bench is changed.

bench: 8454456

Move Tempo to evaluation

No functional change.

Revert "Score extractors"

Are broken for big-endian case and
I have verified with MSVC 2013 Premium
bench is correct and there is no
miscompilation, so the main reason
to change the original code drops.

No functional change.

Fix a warning with MSVC Premium 2013

Reported by Ron Britvich.

No functional change.

Update Readme.md

Retire line about polyglot.ini and
book as they are not used anymore.

No functional change.

Symmetric King Safety: take 2

Another attempt at retiring current asymmetric
king evaluation and use a much simpler symmetric
one. As a good side effect we can avoid recalculating
eval after a null move.

Tested in no-regression mode and passed

STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21580 W: 3752 L: 3632 D: 14196

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 18253 W: 2593 L: 2469 D: 13191

And a LTC regression test against SF DD to
verify we don't have regression against
weaker engines due to some kind of 'contempt'
effect:

ELO: 54.69 +-2.1 (95%) LOS: 100.0%
Total: 40000 W: 11072 L: 4827 D: 24101

bench: 8205159

Use see() instead of see_sign() in previous patch

Before it was working by accident in case of
see_sign() and failing with see() due to how
castle moves are coded (king captures the rook).

Better to explicitly filter out castling moves
and use see() without any surprise/trick.

No functional case.

Add some const qualifier

No functional change.

Decrease reduction for moves that escape a capture

Passed both STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 10094 W: 1833 L: 1704 D: 6557

and LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 27738 W: 4147 L: 3928 D: 19663

bench : 8599236

Retire Polyglot Book management

Book handling belongs to GUI, we kept this code
for historical reasons, but nowdays there is
really no need of this old, (mostly) unused
and especially incorrect designed functionality.

It is up to the GUI to choose the book (far easier for
the user) and to select the book parameters. In no
place, including fishtest, TCEC, rating lists, etc.
the "own book" is used, moreover currently SF is
released without any book and even if in the future we
bundle a book in the release package, it will be the GUI
that will take care of it.

This corrects a wrong design decision that Galurung
and later Stockfish inherited from what was common
practice many yeas ago.

No functional change.

Retire eval weights UCI options

There is really little that user can achieve (apart
from a weakened engine) tweaking these parameters
that are already tuned and have no immediate or visible
effect.

So better do not expose them to the user and avoid the
typical "What is the best setup for my machine?" kind of
question (by far the most common, by far the most useless).

No functional change.

Retire polyglot.ini

All actively maintained GUI are able
to understand UCI protocol, so there
is no more need for this obsolete file.

No functional change.

Restore development version

bench: 8732553

Stockfish 5

Stockfish bench signature is: 8732553

Revert "Symmetric king safety"

Regression test of 40K games at 60 secs shows
this commit to be a 2-3 ELO regression.

So revert to original king safety.

bench: 8732553

Fix a warning with Intel compiler

warning #2259: non-pointer conversion from
"int" to "int16_t={short}" may lose significant
bits.

No functional change.

Tidy up tt.h

Backport some non-functional changes
found working on 'dense TT' patch.

No functional change.

Add perft 'divide' command

To show perft numbers for each move. Just
use 'divide' instead of 'perft', for instance:

position startpos moves e2e4 e7e5
divide 4

Inspired by Ronald de Man.

No functional change.

Update polyglot.ini after last patch

No functional change.

Symmetric king safety

Retire current asymmetric king evaluation
and use a much simpler symmetric one.

As a side effect retire the infamous
'Aggressiveness' and 'Cowardice' UCI
options.

Tested in no-regression mode,

Passed both STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 33855 W: 5863 L: 5764 D: 22228

And LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 40571 W: 5852 L: 5760 D: 28959

bench: 8321835

Fix an off-by-one bug in extract_pv_from_tt

At root we start counting plies from 1,
instead pv[] array starts from 0. So
the variable 'ply' we use in extract_pv_from_tt
to index pv[] is misnamed, indeed it is
not the real ply, but ply-1.

The fix is to leave ply name in extract_pv_from_tt
but assign it the correct start value and
consequentely change all the references to pv[].
Instead in insert_pv_in_tt it's simpler to rename
the misnamed 'ply' in 'idx'.

The off-by-one bug was unhidden when trying to use
'ply' for what it should have been, for instance in
this position:

position fen 8/6R1/8/3k4/8/8/8/2K5 w - - 0 1

at depth 24 mate line is erroneusly truncated due
to value_from_tt() using the wrong ply.

Spotted by Ronald de Man.

bench: 8732553

Extract a reliable PV line

Truncate the extracted PV from the point where
the score stored in hash starts to deviate from
the root score.

Idea from Ronald de Man.

bench: 8732553

Drop to qsearch at low depth in razoring

If razoring conditions are satisfied and
depth is low, then directly drop in qsearch.

Passed both STC
LLR: 2.98 (-2.94,2.94) [-1.50,4.50]
Total: 12914 W: 2345 L: 2208 D: 8361

And LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 50600 W: 7548 L: 7230 D: 35822

bench: 8739659

Remove undefended minors

Tested in "no regression" mode.

Passed both STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 68026 W: 12277 L: 12236 D: 43513

And LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 85682 W: 12861 L: 12836 D: 59985

bench: 7311935

Save stalemates in TT

When there aren't legal moves after
a search, instead of returning imediately,
save bestValue in TT as in the usual case.

There is really no reason to special case
this one.

With this patch is fully fixed (again) follwing
position:

    7k/6p1/6B1/5K1P/8/8/8/8 w - - 0 1

Also in SMP case.

bench: 8802105

Retire "Idle Threads Sleep" UCI option

After last Joona's patch there is no measurable
difference between the option set or unset.

Tested by Andreas Strangmüller with 16 threads
on his Dual Opteron 6376.

After 5000 games at 15+0.05 the result is:

1 Stockfish_14050822_T16_on   : 3003  5000 (+849,=3396,-755), 50.9 %
2 Stockfish_14050822_T16_off  : 2997  5000 (+755,=3396,-849), 49.1 %

bench: 880215

Make imbalance table more clear

No functional change.

Pass Position as const ref in update_stats()

No functional change.

Clarify some comments in SMP code

Spotted by Joona.

No functional change.

Reformat and simplify previous patch

No functional change.

Allow a slave to 'late join' another splitpoint

Instead of waiting to be allocated, actively search
for another split point to join when finishes its
search. Also modify split conditions.

This patch has been tested with 7 threads SMP and
passed both STC:

LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 2885 W: 519 L: 410 D: 1956

And a reduced-LTC at  25+0.05
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 4401 W: 684 L: 566 D: 3151

Was then retested against regression in 3 thread case
at standard LTC of  60+0.05:

LLR: 2.96 (-2.94,2.94) [-4.00,0.00]
Total: 40809 W: 5446 L: 5406 D: 29957

bench: 8802105

Rewrite Score extractors

Less tricky and even a bit faster. With this
version Visual Studio Ultimate 2013 Update 2 RC
runs fine even in O2 optimization.

No functional change.

Change search() signature

Pass SpNode as template parameter.

No functional change.

Revert dynamic contempt

On a final fixed game number test it failed
to prove better than standard version.

STC 15+0.05

ELO: -0.86 +-1.7 (95%) LOS: 15.8%
Total: 57578 W: 10070 L: 10213 D: 37295

bench: 8802105

Revert stalemate detection in evaluation

Unfortunatly we have a slow down that causes
a regression in STC with no-regression mode:

LLR: -2.96 (-2.94,2.94) [-3.00,1.00]
Total: 22454 W: 3836 L: 4029 D: 14589

bench: 8678654

Revert back KBPsK to latest Gary's version

The bug was found to be elsewhere. This version
is correct and also is able to detect as draw
positions like:

8/8/5b2/8/8/4k1p1/6P1/5K2 b - - 6 133

bench: 8678654

Fix KXK endgame

Position is win also if strong side has a bishop
and a knight (plus other material, otherwise
KBNK would be triggered instead of KXK).

This fixes a subtle bug where a search on position

k7/8/8/8/8/P7/PB6/K7 b - - 6 1

Instead of returning a draw score, suddendly returns
a big score. This happens because at one point in
search we reach this position:

8/Pk6/8/8/8/4B3/P7/K7 w - - 3 8

Where white can promote. In case of rook promotion (and also in case of
queen promotion) the resutling position gets a huge static eval that is
above VALUE_KNOWN_WIN (from the point of view of white). So for rook
promotion it is

          &&  futilityBase > -VALUE_KNOWN_WIN

that prevents futility pruning in qsearch. (Removing this condition indeed
lets the problem occur). Raising the static eval for K+B+N+X v K to a value
higher than VALUE_KNOWN_WIN fixes this particular problem without having to
introduce an extra futility pruning condition in qsearch.

I just checked and it seems K+R v K, K+2B v K and even K+B+N v K already get
a huge static eval. Why not K+B+N+P v K?

I think this fix corrects an oversight. There is special code for KBNK, but
KBNXK is handled by KXK, so the test for sufficient material should also test
for B+N.

bench: 8678654

Fully correct stealmate detection

In the (rare) cases when the two conditions
are true, then fully check again with a slow
but correct MoveList<LEGAL>(pos).size().

This is able to detect false positives like
this one:

8/8/8/Q7/5k1p/5P2/4KP2/8 b - - 0 17

When we have a possible simple pawn push that
is not stored in attacks[] array. Because the
third condition triggers very rarely, even if
it is slow, it does not alters in a measurable
way the average speed of the engine.

bench: 8678654

Add stealmate detection to evaluation

Currently a stealmate position is misevaluated
in a negative/positive score, this leads qsearch(),
that does not detects stealmates too, to return the
wrong score and this yields to some kind of endgames
to be completely misevaluated.

With this patch is fully fixed follwing position

7k/6p1/6B1/5K1P/8/8/8/8 w - - 0 1

Also in SMP case.

Correct root cause analysys by Ronald de Man.

bench: 8678654

Revert to Galurung's KBPsK endgame

After reverting to the original Tord's
endgame, a search on position

7k/6p1/6B1/5K1P/8/8/8/8 w - - 0 1

Reports, correctly, a draw score instead of
an advantage for white.

Issue reported by Uri Blass.

bench: 8678654

Use only standard conforming eg_value()

Remove the optimization for Intel, is not
standard and can break at any time, moreover
our release build is not done with Intel C++
anymore so we don't need to sqeeze the extra
speed out from this compiler.

No functional change.

Don't save stale value in TT after split

If we return from split with a stale value
due to a stop or a cutoff upstream occurred,
then we exit moves loop and save a stale value
in TT before returning search().

This patch, from Joona, fixes this.

bench: 8678654

Better document search stop condition

Handling a stop or a cutoff in the search is
a tricky business, so better document this
difficult part of the code.

No functional change.

Remove dead code in search

We can never have bestValue == -VALUE_INFINITE at
the end of move loop because if no legal move exists
we detect it with previous condition on !moveCount,
if a legal move exists we never prune it due to
futility pruning condition:

bestValue > VALUE_MATED_IN_MAX_PLY

So this code never executes, as I have also verified
directly.

Issue reported by Joona.

No functional change.

Fix a compile error with Intel C++

Intel compiler is very picky:
"error: this operation on an enumerated type requires an
applicable user-defined operator function"

Reported by Tony Gaor.

No functional change.

Penalize hanging pieces

Passed both STC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 8519 W: 1565 L: 1440 D: 5514

And LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 60618 W: 9141 L: 8777 D: 42700

bench: 8678654

Rearrange interpolation formula

Put the division at the end to reduce
rounding errors. This alters the bench
due to different rounding errors, but
should not alter ELO in any way.

bench: 7615217

Minor stuff scattered around

Just random minor stuff I found while browsing the code.

No functional change.

Remove other useless floor()

No functional change.

Don't need floor() in timeman.cpp

For positive numbers result is equivalent:
http://stackoverflow.com/questions/3300290/cast-to-int-vs-floor

Spotted by Joseph Ellis.

No functional change.

Fix Intel compiler warnings

Fallout from previous patch: Intel compiler
is very noisy.

No functional change.

Remove some useless casts

No functional change.

We can add an integer to a Value

We have defined corresponding operators,
so rely on them to streamline the code
and increase readibility.

No functional change.

Remove rook passers eval completely

Tested in no-regression mode.

Passed STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17727 W: 3248 L: 3122 D: 11357

And (a very long!) LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 106327 W: 16258 L: 16265 D: 73804

bench: 7396783

Reformatting in material.h

No functional change.

Move game phase constants to enum Value

No functional change.

Speed up by almost 3%

This apparentely silly tweak allows
to speed up the bench by almost 3%.

Not clear why, repeating with perft,
the speed up vanishes.

Suggested by Jonathan Calovski.

No functional change.

Fix issues detected by Coverity Scan

Most of Coverity Scan reports are false
positives, but in rare cases we have
confirmed (very small) issues.

No functional change.

Speed up picking of killers

Changing the order of the conditions gives
about 1% speed up!

No functional change.

Remove RookOn7th and merge values into psqt

Tested in no-regression mode:

STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 55678 W: 9954 L: 9892 D: 35832

LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 9238 W: 1448 L: 1311 D: 6479

bench: 7905850

Remove penalty for knight when few enemy pawns

Tested in standard mode at STC and no-regression
mode at LTC:

STC
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 19503 W: 3502 L: 3349 D: 12652

LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 67474 W: 9974 L: 9921 D: 47579

bench: 8331217

Shuffle movepicker score

Believed to be a speed optimization as benched
on Windows with bench realtime affinity 0x1 deleting
highest and lowest runs:

Base Test
1549259 1608202
1538115 1583934
1543168 1556938
1536365 1554179
1533026 1582010

Signature remains unchanged and gives anywhere from 1-2% nps
boost in analysis depending on number of cores used.

No functional change.

Correctly apply previous patch

Apply the correct values from previous patch.

bench: 8082049

Move queen vs. 3 minors rule to imbalance tables

Tuned with CLOP after 57k games.

Simplification: tested in no-regression mode.

Passed both STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17254 W: 3159 L: 3032 D: 11063

And LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 32413 W: 4967 L: 4864 D: 22582

bench: 8082049

Revert "Generalize shift_bb() to handle double pushes"

Seems to intorduce some compiler warning as
reported by Gary. Warning seems bogus, but
revert anyhow.

No functional change.

Reset DrawValue[] before new search

Spotted by Ronald de Man

bench: 7384368

Rise contempt when in advantage

This is a very discussed patch with many
argumentations pro and against. The fact is
it passed both STC:

LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 16305 W: 3001 L: 2855 D: 10449

And LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 34273 W: 5180 L: 4931 D: 24162

Although it is true that a correct test should
include foreign engines, we commit it anyhow so
people can test it out in the wild, under broader
conditions.

bench: 7384368

Streamline implementation of Position::pretty()

Simpler and more in line with Bitboards::pretty()

No functional change.

Raise penalty blocked enemy pawn on 6th rank

Idea from Lyudmil Tsvetkov.

The value seems to be raised a bit abruptly, but as
Gary said, a blocked pawn on the sixth rank has been
instrumental in limiting king mobility in multiple
losses that I've seen from SF. A blocked pawn on fifth
rank is much less serious on the king safety impact.

Passed both STC
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 14551 W: 2750 L: 2607 D: 9194

and LTC
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 43595 W: 6917 L: 6618 D: 30060

And even a retest at 60" fixed games 40K
ELO: 1.79 +-1.9 (95%) LOS: 97.0%
Total: 39889 W: 6018 L: 5813 D: 28058

bench: 7154916

Generalize shift_bb() to handle double pushes

And use it in evaluate_space.

No functional change.

Small simplification to passed pawns

Tested in no-regression mode.

Passed both STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 28521 W: 5066 L: 4958 D: 18497

And LTC
LLR: 3.04 (-2.94,2.94) [-3.00,1.00]
Total: 21939 W: 3261 L: 3138 D: 15540

bench: 8165681

Remove supporting pawns

Tested in no-regression mode

Passed both STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 44957 W: 7984 L: 7903 D: 29070

and LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 12396 W: 1916 L: 1783 D: 8697

Bench: 7907885

Enable BMI1 too when using BMI2 ARCH

Adding BMI1 allows the compiler to use _blsr_u64
automatically (the advertised 0.3% speed gain).
I verified that the compiler does not use this
instruction with the -mbmi2 flag only. Also, all
processors supporting BMI2 is also supporting BMI1.

No functional change

More readable trapped rook condition

Prefer

file_of(s) < file_of(ksq)

to the inidrect

file_of(ksq) < FILE_E

To evaluate if semiopen side to check is the left side.

Also other small touches while there.

No functional change.

Simplify Makefile by removing OS X targets

Right now the Makefile is cluttered with OS X equivalents
of all the x86 targets. We can get rid of all of them and
just check UNAME against "Darwin" for the few OS X-specific
things we need to do.

We also disable Clang LTO when using BMI2 instructions. For
some reason, LLVM cannot find the PEXT instruction when using
LTO. I don't know why, but disabling LTO for BMI2 fixes it.

No functional change.

Move args parsing to UCI::loop

This leaves a very clean main.cpp

No functional change.

Reshuffle in uci.cpp

Move function definitions before call site.

No functional change.

Reshuffle in timeman.cpp

Move template definitions before call site.

No functional change.

Fix a typo in evaluate

Spotted by Lyudmil Antonov.

No functional change.

Retire signature-build

Does not seem used.

No functional change.

Add ARCH x86-64-bmi2 support

Intel Haswell and newer CPUs can calculate sliders
attacks using special PEXT asm instructions instead
of magic bitboards. This gives a +3% speed up.

To enable it just compile with ARCH=x86-64-bmi2

No functional change.

Switch to hardware PEXT

Retire software pext and introduce hardware
call when USE_PEXT is defined during compilation.

This is a full complete implementation of sliding
attacks using PEXT.

No functional change.

Implement PEXT based attacks

According to:

https://chessprogramming.wikispaces.com/BMI2#PEXTBitboards

No functional change.

Add PEXT software implementation

For development/debug purposes.

No functional change.

Big reshuffle in evaluate.cpp

Reshuffle functions to define them in reverse
calling order (C style).

This allow us to define templates before they are
used. Currently it is not like this, for instance
evaluate_pieces is defined after do_evaluate that
calls it. This happens to work for some strange
reason (two phase lookup?) but we want to avoid
code that works 'by magic'.

As a nice side-effect we can now remove the function
prototypes.

No functional change.

Move LowMobPenalty into psq/mobility tables

Tested in no-regression mode.

Passed both STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 36705 W: 6537 L: 6443 D: 23725

and LTC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 9358 W: 1495 L: 1358 D: 6505

bench: 6921356

Reduce penalty for doubled pawns further away from each other

Passed both STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 38339 W: 6849 L: 6649 D: 24841

and LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 22693 W: 3455 L: 3256 D: 15982

bench: 7508468

Further simplification in evaluate

No functional change

Get rid of an evaluate_pieces() overload

Rewrite and greatly simplify that part of code.

No functional change.

Add a penalty for low mobility pieces

Passed both STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 81857 W: 14652 L: 14342 D: 52863

and LTC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 45400 W: 6999 L: 6697 D: 31704

bench: 7716978

Restrict queen mobility to safe squares

Passed both STC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 16188 W: 3119 L: 2971 D: 10098

and LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 6336 W: 1010 L: 882 D: 4444

bench: 7533692

Rescale UCI scores to PawnValueEg

This is more consistent with what other engines are doing.
Often people thinks that SF's scores are overblown. In the
end, it just boils down to the arbitrary way of rescaling them.

No functional change.

Sync some common names

No functional change.

Some more work in pretty_pv

No functional change.

Small tidy up in move_to_san

No functional change.