Use a per-thread array for generated moves

This greately reduces stack usage and is a
prerequisite for next patch.

Verified with 40K games both in single and SMP
case that there are no regressions.

No functional change.

Update disabled warnings for Intel compiler

No functional change.

Replace -O3 with -fast for intel compiler

No functional change.

Reduce negative quiets by ONE_PLY / 2

Passed both short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 3402 W: 708 L: 593 D: 2101

And long TC:
LLR: 2.93 (-2.94,2.94) [0.00,6.00]
Total: 23379 W: 3972 L: 3759 D: 15648

bench: 3529630

Final time management setup

This is an even safer setup proposed and tested
by Alexandre Meirelles.

Regression testing of 40K games at 10+0.05 show
result is stable both against current master:

ELO: -0.29 +-2.2 (95%) LOS: 39.7%
Total: 40000 W: 8010 L: 8043 D: 23947

and again original master (the one with smallest
time parameters):

ELO: 1.71 +-2.2 (95%) LOS: 93.8%
Total: 40000 W: 8325 L: 8128 D: 23547

Alexandre verified with LittleBlitzer time losses are
greately reduced with this setup:

Games Completed = 2100 of 3000 (Avg game length = 35.745 sec)

Settings = RR/128MB/15000ms+50ms/M 1000cp for 12 moves, D 150 moves/
Time = 39200 sec elapsed, 16800 sec remaining
 1.  Stockfish 190913             1091.5/2100    803-720-577      (L: m=313 t=1 i=0 a=406)    (D: r=278 i=91 f=136 s=8 a=64)    (tpm=212.5 d=14.75 nps=925427)
 2.  Houdini 2.0 w32              1008.5/2100    720-803-577      (L: m=250 t=299 i=0 a=254)    (D: r=278 i=91 f=136 s=8 a=64)    (tpm=204.1 d=12.04 nps=1326351)

No functional change.

Increase Emergency Move Time to 20

Goes in the direction of avoiding time losses and seems
equivalent after almost 40K games at super fast TC of 10+0.05

ELO: 2.61 +-2.2 (95%) LOS: 99.1%
Total: 39869 W: 8258 L: 7959 D: 23652

No functional change.

Increase Emergency Move Time to 10

Goes in the direction of avoiding time losses and seems
equivalent after almost 40K games at super fast TC of 10+0.05

ELO: 2.41 +-2.3 (95%) LOS: 98.1%
Total: 37222 W: 7843 L: 7585 D: 21794

No functional change.

Fix a silly unstoppable eval bug

The logic is broken for black side because we get more bonus
for pawn in 7th rank than for pawn in 2nd rank!

Spotted by Reuven Peleg

bench:3884409

Fix time parameters for blitz games

The ideal setting for super-blitz might be something like:

    "Emergency Base Time" = 50
    "Emergency Move Time" = 5

This would give a total emergency time buffer of:

    50 + 40 * 5 = 250 ms

This setup replaces the previous half cooked hack
"Don't blunder under extreme time pressure".

Test results are very good at super blitz, but keep good even
at 60 secs.

At 5+0.05
ELO: 24.30 +-2.4 (95%) LOS: 100.0%
Total: 37802 W: 10060 L: 7420 D: 20322

At 15+0.05
ELO: 13.41 +-2.9 (95%) LOS: 100.0%
Total: 22271 W: 4853 L: 3994 D: 13424

At 60+0.05
ELO: 5.30 +-3.2 (95%) LOS: 99.9%
Total: 16000 W: 2897 L: 2653 D: 10450

No functional change.

Rewrite unstoppable pawns evaluation

Instead of current code, give a bonus according to the frontmost
square among candidate + passed pawns.

This is a big simplification that removes a lot of accurate code
substituting it with a statistically based one using the common
'bonus' scheme, leaving to the search to sort out the details.

Results are equivalent but code is much less and, as an added bonus,
we now store candidates bitboard in pawns hash and allow this
info to be used in evaluation. This paves the way to possible
candidate pawns evaluations together with all the other pieces,
as we do for passed.

Patch passed short TC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 16927 W: 3462 L: 3308 D: 10157

Then failed (quite quickly) at long TC
LLR: -2.95 (-2.94,2.94) [0.00,6.00]
Total: 8451 W: 1386 L: 1448 D: 5617

But when ran with a conclusive 40K fixed games at 60 secs it proved
almost equivalent to original one.

ELO: 1.08 +-2.0 (95%) LOS: 85.8%
Total: 40000 W: 6739 L: 6615 D: 26646

bench: 3884003

Code style at passed pawn eval

No functional change.

Nicer operator declerations

No functional change.

Use pre-increment also for native types

Now that we use pre-increment on enums, it
make sense, for code style uniformity, to
swith to pre-increment also for native types,
although there is no speed difference.

No functional change.

Fix operator++ definition

ENABLE_OPERATORS_ON has incorrect definitions of
post-increment and post-decrement operators.

In particularly the returned value is the variable
already incremented/decremented, while instead they
should return the variable _before_ inc/dec.

This has no real effect because are only used in loops
and where the returned value is never used, neverthless
it is wrong. The fix would be to copy the variable to a
dummy, then inc/dec the variable, then return the dummy.

So instead, rename to pre-increment that can be implemented
without the dummy, actually the current implementation
it is already the correct pre-increment, with the only change
to return a reference (an l-value) and not a copy, so
to properly mimic the pre-increment on native integers.

Spotted by Kojirion.

No functional change.

Don't blunder under extreme time pressure

We always attempt to keep at least this emergencyBaseTime
at clock. But if available time is very low it means that
we will force ourself to play immediately to satisfy the
emergencyBaseTime constrain and so leading to blunders.

Patch is good at short and very short TC (15secs and 5secs respectively)
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 26590 W: 5426 L: 5245 D: 15919

LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 5767 W: 1397 L: 1268 D: 3102

Instead seems has no influence at longer TC (60 secs)
LLR: -2.96 (-2.94,2.94) [0.00,6.00]
Total: 79862 W: 13623 L: 13339 D: 52900

So it is committed to have a broader testing but is
to be consider still EXPERIMENTAL and can be reverted
easily.

No functional change.

Move classify_leaf() to c'tor in bitbases

No functional change.

Small touches to bitbase.cpp

Inspired by Lucas's code:

https://github.com/lucasart/chess/blob/master/src/kpk.cc

No functional change.

Increase passed bonus for having more pieces

Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 36463 W: 7575 L: 7365 D: 21523

And long TC:
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 2953 W: 564 L: 446 D: 1943

bench: 3846852

Revert "Move draw by material check"

Possible regression

bench: 4554579

Revert "Fix random moves when time < 10ms"

Possible regression.

No functional change.

Extend checks more when below alpha

Passed both short TC:
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 8739 W: 1830 L: 1698 D: 5211

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 6716 W: 1238 L: 1101 D: 4377

bench: 4554576

Extend checks more in losing positions

Passed both short TC:
LLR: 2.98 (-2.94,2.94) [-1.50,4.50]
Total: 3974 W: 860 L: 741 D: 2373

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 16807 W: 2917 L: 2733 D: 11157

bench: 3767999

Simplify unstoppable pawns evaluation

No functional change

Fix random moves when time < 10ms

In case we have less then 10ms to think as soon as
we wake up the timer, it immediately fires and calls
check_time() where due to condition:

elapsed > TimeMgr.maximum_time() - 2 * TimerResolution

the stop flag is set and search returns immediately, without
actually search anything.

Here the somewhat hacky fix is to start the timer after
at least one iteration as been completed.

No functional change.

More readable space mask

No functional change.

Change condition to use relative rank

No functional change

Fix some comments in position.cpp

No functional change.

Move draw by material check

It is more natural to test this case among
others material distributions.

No functional change.

Remove unreachable values in mobility table

The possible maximum mobility cardinality (plus one in case of
zero squares available) is:

- Knights: max. 8  squares -> max. 9  entries
- Bishops: max. 13 squares -> max. 14 entries
- Rooks:   max. 14 squares -> max. 15 entries
- Queen:   max. 27 squares -> max. 28 entries

So remove the extra entries in the table.

Spotted by Dariusz Orzechowski.

No functional change.

Fix warning: double to float truncation

MSVC 2013 says:
warning C4305: '*=' : truncation from 'double' to 'float'

No functional change.

Singular extension at 8 plies also for PV nodes

Passed both short TC:
LLR: 2.96 (-2.94,2.94)
Total: 11451 W: 2455 L: 2282 D: 6714

And long TC
LLR: 2.96 (-2.94,2.94)
Total: 15813 W: 2907 L: 2723 D: 10183

bench: 3864419

Union of 2 changes

Union of

- LMR >= 3 plies from Gary tests.stockfishchess.org/tests/view/522522960ebc595d328fcafd

- allows() tweak from Reuven tests.stockfishchess.org/tests/view/5225fa1c0ebc595d328fcb53

Both passed Step I and failed Step II.

Instead this union passed both short TC:
LLR: 2.95 (-2.94,2.94)
Total: 14525 W: 3063 L: 2874 D: 8588

And long TC
LLR: 2.94 (-2.94,2.94)
Total: 31075 W: 5566 L: 5308 D: 20201

bench: 4238160

Do not prune useless checks in QS

Passed both SPRT tests in "simplification mode", so with
elo0: -3.00 alpha: 0.05 elo1: 3.00 beta: 0.05

Short TC:
LLR: 2.96 (-2.94,2.94)
Total: 6243 W: 1302 L: 1195 D: 3746

Long TC
LLR: 2.96 (-2.94,2.94)
Total: 22972 W: 4124 L: 4020 D: 14828

bench: 4633330

Revert "Fix check for bishop pair in material imbalance"

Idea is sound but implementation is partial. Ryan and Joona noticed that
    we leave an hole in material table. Also we got another report by an user
    of an odd behaviour. Namely, if you start stockfish and from the prompt
    give 'bench' you get 3453941, then if you run again bench you get 3453940.

    The reason is that two different positions with the same number of pieces,
    but one with a bishop pair and another without have the same material key.
    But after Eelco patch also different material imbalance and this yields
    to this issue.

    Restesting at long TC shows the patch does not really contribute at
    ELO improvement. Actually patch failed at long TC.

    LLR: -2.97 (-2.94,2.94)
    Total: 23109 W: 4104 L: 4092 D: 14913

    So revert.

    bench: 3453945

Rewrite backward pawn detection

Use the new backmost_sq() instead of a loop.

No functional change.

Fix check for bishop pair in material imbalance

Prefer pos.bishop_pair() to pos.count<BISHOP>(WHITE) > 1
because the first checks that the two bishops are on
different color squares.

Although the change seems to kick in only in very rare cases,
quite surprisingly it was able to pass SPRT test at short TC.

LLR: 2.95 (-2.94,2.94)
Total: 39818 W: 8174 L: 7956 D: 23688

bench: 3453941

Rewrite KBBKN endgame

This was thought to be a draw but the bishops generally win. However,
it takes up to 66 moves. The position in the diagram was thought to be
a draw for over one hundred years, but tablebases show that White wins
in 45 moves. All of the long wins go through this type of semi-fortress
position. It takes several moves to force Black out of the temporary
fortress in the corner; then precise play with the bishops prevents Black
from forming the temporary fortress in another corner (Nunn 1995:265ff).

Before computer analysis, Speelman listed this position as unresolved,
but "probably a draw" (Speelman 1981:109).

bench: 3453945

Don't use lpthread for Android

Thanks to Peter Osterlund for the feedback.

No functional change.

Improve ARM compatibility

STANDALONE-TOOLCHAIN.html in Android NDK says:

It is recommended to use the -mthumb compiler flag to force the generation
of 16-bit Thumb-1 instructions (the default being 32-bit ARM ones).

If you want to target the 'armeabi-v7a' ABI, you will need ensure that the
following two flags are being used:

  CFLAGS='-march=armv7-a -mfloat-abi=softfp'

Note: The first flag enables Thumb-2 instructions, and the second one
      enables H/W FPU instructions while ensuring that floating-point
      parameters are passed in core registers, which is critical for
      ABI compatibility. Do *not* use these flags separately!

Thanks to Peter Osterlund for pointout this doc and for showing me
an example Makefile to follow.

No functional change.

Union of 2 changes that failed with good score

This is a union of 2 changes:

A tweak of recaptures limit from Joona Kiiski
http://tests.stockfishchess.org/tests/view/52166d7c0ebc59319a242400

and a tweak of move count pruning from Leonid Pechenik
http://tests.stockfishchess.org/tests/view/5217c7e60ebc59319a242456

The set passed both short TC at 30+0.05
LLR: 2.96 (-2.94,2.94)
Total: 18936 W: 3723 L: 3566 D: 11647

And the usual long TC at 60+0.05
LLR: 2.95 (-2.94,2.94)
Total: 48962 W: 8837 L: 8487 D: 31638

bench: 3453945

Assorted clean up in endgames

No functional change.

Fix a bogus assert in allows()

Becuase castle is coded as "king captures the rook"
the to_sq(move), A1/8 or H1/8 is empty after the move,
leading to assert assert(p != NO_PIECE) in color_of().

Teach allows() asserts about castle and fix the crash.

Bug reported by Ryan Takker and tracked down by Tom Vijlbrief.

No functional change.

Use frontmost_sq() and backmost_sq helpers

Should easier to read than the lsb() / msb() low
level functions.

No functional change.

Enable LMR for dangerous moves

Passed both short TC
LLR: 2.96 (-2.94,2.94)
Total: 5598 W: 1250 L: 1125 D: 3223

And long TC
LLR: 2.97 (-2.94,2.94)
Total: 16441 W: 3102 L: 2912 D: 10427

bench: 4620975

Bonus for rook behind a passed

If our rook is behind a passed pawn, all
squares are defended.

One of the longest tests to pass !

Passed both short TC
LLR: 2.97 (-2.94,2.94)
Total: 44560 W: 9518 L: 9281 D: 25761

And long TC
LLR: 2.96 (-2.94,2.94)
Total: 61348 W: 11618 L: 11192 D: 38538

bench: 3787694

Replace hardcoded 128 by constant

No functional change.

Add lsb() overload

Helper to find least significant bit relative to
the given color.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Time management: move faster if PV is stable

Move faster but compensate by allocating more
time when the best move changes.

Passed short TC at 15+0.05
LLR: 2.93 (-2.94,2.94)
Total: 13895 W: 3030 L: 2882 D: 798

Long TC at 60+0.05
LLR: 2.96 (-2.94,2.94)
Total: 9266 W: 1777 L: 1624 D: 5865

At time increment 30+0.5
LLR: 2.96 (-2.94,2.94)
Total: 6703 W: 1238 L: 1134 D: 4331

And at fixed game number, longer TC 120+0.05
ELO: 5.17 +-2.8 (95%) LOS: 100.0%
Total: 19306 W: 3378 L: 3091 D: 12837

bench: 4728533

Simplify chain detection

No functional change.

Simplify kf definition in shelter_storm()

No functional change.

Fix KBPK bug

With

position fen 7k/8/8/8/8/7P/6K1/7B w - - 0 1
go depth 25

The evaluation at depth 22 is not draw as it should be. The reason is that
when search reaches the position 8/6kP/8/8/8/3B4/6K1/8 w - - 0 1 if white plays
h8R or h8N then we get a position that is a "KNOWN_WIN" and is _not_ a check, so
futility pruning in qsearch kicks in and black may think that it is "futile"
to reply Kxh8 since, according to the logic of the code, it cannot raise the score
back towards a draw.

bench: 4728533

Simplify condition for backward pawn

No functional changes.

Retire redundant endgames

The case of two lone kings on the board is already considered
by the "No pawns" scaling factor rules in material.cpp as is
KBK and KNK.

Moreover we had a small leak in endgames map because for
KK endgame it happens white and black material keys are the
same (both equal to zero), so when adding the black endgame in
Endgames::add() we were overwriting the already exsisting
white one, leading to a memory leak found by Valgrind.

So remove the endgames althogheter and rely on scaling
to correctly set the endgames value to a draw.

No functional change.

Use null move when depth >= 2 plies

Passed both short TC:
LLR: 2.96 (-2.94,2.94)
Total: 23725 W: 5031 L: 4855 D: 13839

And long TC:
LLR: 2.96 (-2.94,2.94)
Total: 15730 W: 2939 L: 2754 D: 10037

bench: 4729333

Restore development version

No functional change.

Stockfish 4

Stockfish bench signature is: 4132374

Fix crash when reaching max ply

Bug introduced in 1b7223a53c419212efbd that
updated the ss base stack without increasing
the dimension.

No functional change.

Remove useless condition in KXK endgame

Because eval is never called when in check.

No functional change.

Further tweak movecount pruning

Passed both short TC
LLR: 2.95 (-2.94,2.94)
Total: 15140 W: 3125 L: 2976 D: 9039

And long TC
LLR: 2.95 (-2.94,2.94)
Total: 17118 W: 3165 L: 2974 D: 10979

bench: 4132374

Normalize "pawn in front of minor" patch

No functional change.

Use constants arguments where possible

No functional changes.

Revert using exceptions

Due to crashes. It will be reapplied once
we understand what's happening.

No functional change.

Simplify DistanceRingsBB init

Verified by same benchmark and picking some random values.

No functional change.

Some renaming in TT store()

No functional change.

Use exceptions to stop the search

Instead of classical flags, throw an
exception when we want to immediately halt
the search. Currently only one type
is used for both UCI stop and threads
cut off.

No functional change.

Bonus for a pawn in front of knight/bishop

Idea originated from a post of Don Dailey
on talkchess and reported by Eelco.

This is the last succesful attempt of a long
series of trials (as usually happens, the
'idea' alone is not enough).

Passed both short 15secs TC
LLR: 2.97 (-2.94,2.94)
Total: 7629 W: 1645 L: 1515 D: 4469

And long 60secs TC
LLR: 2.96 (-2.94,2.94)
Total: 10218 W: 1932 L: 1775 D: 6511

bench: 4944581

Remove Now Unneeded Help Text

With the new automatic setting of split depth
instead of a default, the user no longer needs
guidance on setting the split point.

Also threads now defaults to one.

No functional change.

Don't set Search::RootColor in Eval::trace

Search::RootColor is a global parameter set
before to start a search, it is not something
trace() should change.

This patch allows to add trace() calls, for
debugging, inside search itself without altering
the bench, and also ensures that the values
returned by trace() and evaluate() are fully
equivalent.

No functional change.

Fix GrainSize rounding error

The rounding formula is different between
positive and negative scores due to the
GrainSize/2 term that is asymmetric.

So use truncation instead of rounding. This
guarantees that evaluation is rounded to zero
in the same way for both positive and negative
scores.

Found with position's flip

bench: 4634244

Fix 'improving' condition

Because VALUE_NONE is 30002, it happens that
after a check the next move is never an improving
one.

After this patch bench signature is independent from
VALUE_NONE actual value.

bench: 4303194

Increase LMR when not improving

Apply to LMR the same Eelco's idea
applied to move count pruning.

This is the result of a series of
attempts started by Thomas Kolarik.

Passed both short TC
LLR: 2.95 (-2.94, 2.94)
Total: 5675 W: 1241 L: 1117 D: 3317

And long TC:
LLR: 2.95 (-2.94, 2.94)
Total: 8748 W: 1689 L: 1539 D: 5520

bench: 4356801

Further tweak Position::flip

No functional change.

Rewrite flip() to use FEN string manipulation

Instead of dealing directly with internal parameters
just "flip" the FEN string and set the position from
that.

No functional change.

Streamline time computation

No functional change.

Update polyglot.ini with new "Min Split Depth" default

No functional change.

Refactor do_castle()

Not a real functional change, but bench changed due to different piecelist
reordering. To verify it a temporary my canonicalize_rooks function was
written as follows. It just ensures that the rook on the "smaller" square
is listed first.

void Position::canonicalize_rooks(Color c)
{
   if (pieceCount[c][ROOK] == 2)
   {
      Square s0 = pieceList[c][ROOK][0];
      Square s1 = pieceList[c][ROOK][1];
      if (s0 > s1)
      {
         pieceList[c][ROOK][0] = s1;
         pieceList[c][ROOK][1] = s0;
         index[s0] = 1;
         index[s1] = 0;
      }
   }
}

With this both bench and the test on Chess960 positions

./stockfish bench 128 1 8 Chess960.epd file > /dev/null

Gives same result.

bench: 4424151

Retire cpu_count()

Set threads number always to 1 at startup and let the
user explicitly to chose the number of threads.

Also preserve the useful behavior of automatically set
"Min Split Depth" according to the requested threads,
indeed this parameter is too technical for a casual user,
so, when left to zero, we set it on a sensible value.

No functional change

Further factor out position update code

Along the lines of previous patch.

No functional change

Factor out pieceList updating code

The new Position methods add_piece, move_piece, and remove_piece
now manage the member variables pieceList, pieceCount, and index,
and 9 blocks of code in Position that used to manipulate those
data structures by hand now call the new methods.

There is a slightly slowdown (< 1%) on Clang and on perft,
but the cleanup compensates the little speed loss.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Rework Thread hierarchy

Introduce ThreadBase struct that is search
agnostic and just handles low level stuff,
and derive all the other specialized classes
form here.

In particular TimerThread does not hinerits
anymore all the search related stuff from Thread.

Also some renaming while there.

Suggested by Steven Edwards

No functional change.

Fix a race at thread creation

At thread creation start_routine() is called
and from there the virtual function idle_loop()
because we do this inside Thread c'tor, where the
virtual mechanism is disabled, it could happen that
the base class idle_loop() is called instead.

The issue happens with TimerThread and MainThread
where, at launch, start_routine calls
Thread::idle_loop instead of the derived ones.

Normally this bug is hidden because c'tor finishes
before start_routine() is actually called in the
just created execution thread, but on some platforms
and in some cases this is not guaranteed and the
engine hangs.

Reported by Ted Wong on talkchess

No functional change.

Tidy up Position::pretty

No functional change.

Small renaming

No functional change.

Speed up move generation

Pass the color as template parameter
to generate_all()

Speedup of 1,3% in perft and 2,5% in bench !

No functional change.

Increase pruning if evaluation is not improving

Add an additional set of margins to movecount pruning
to be used when static evaluation is getting worse
than previous move.

Here are the margins table with changing
depth (fm0 not improving, fm1 improving):

    d: 0, fm0: 3, fm1: 3
    d: 1, fm0: 4, fm1: 4
    d: 2, fm0: 6, fm1: 6
    d: 3, fm0: 7, fm1: 10
    d: 4, fm0: 11, fm1: 15
    d: 5, fm0: 15, fm1: 21
    d: 6, fm0: 21, fm1: 29
    d: 7, fm0: 27, fm1: 37
    d: 8, fm0: 35, fm1: 47
    d: 9, fm0: 42, fm1: 57
    d: 10, fm0: 51, fm1: 68
    d: 11, fm0: 60, fm1: 81
    d: 12, fm0: 70, fm1: 94
    d: 13, fm0: 81, fm1: 108
    d: 14, fm0: 92, fm1: 123
    d: 15, fm0: 104, fm1: 139

Good at both short TC

LLR: 2.97 (-2.94,2.94)
Total: 11502 W: 2503 L: 2361 D: 6638

And long TC

LLR: 2.98 (-2.94,2.94)
Total: 7189 W: 1421 L: 1277 D: 4491

bench: 4364793

Annotate an unlikely condition

No functional change.

Fix an assert in KBK endgame

The endgame king + minor vs king is erroneusly
detected as king + minor vs king + minor

Here the fix is to detect king + minor earlier,
in particular to add these trivial cases to
endgame evaluation functions.

Spotted by Reuven Peleg

bench: 4727133

Rewrite pawn shield and storm code

Passes quickly both short TC:
LLR: 2.95 (-2.94,2.94)
Total: 5755 W: 1349 L: 1222 D: 3184

And long TC:
LLR: 2.95 (-2.94,2.94)
Total: 2744 W: 628 L: 505 D: 1611

bench: 4727133

Fix a typo in bitboard.h

Introduced by previous patch.

Spotted by Joerg Oster

No functional change.

Use #ifndef instead of #if !defined

And #ifdef instead of #if defined

This is more standard form (see for example iostream file).

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Simplify captures ordering

A big simplification and removing of useless code.

Finished at 50% both at short TC (with SPRT) than
at long TC at fixed number of games:
ELO: -0.14 +-3.4 (95%) LOS: 46.8%
Total: 15206 W: 2836 L: 2842 D: 9528

bench: 5059948

Revert "Halve king eval margin"

This reverts commit 4b3a0fdab03a7529ede42891963d3036712a0bd5.

As Gary says: " It failed when I tried it at long TC previously, and only
barely passed this time.  Some anecdotal evidence is that it hurts vs other
engines as well (the Lightspeed rating list showed a 16 elo drop from previous
best version - still +- 5 error bars on both, but that's still significant)"

I also agree that if we have some doubts (like in this case) it is better to
be safe than sorry.

bench: 4615572

Tune pawn PSQT values

Reduces the influence of PSQT for entries such as
the extended center and the h-file.

Passed both short TC test:
LLR: 2.95 (-2.94,2.94)
Total: 23919 W: 5207 L: 5029 D: 13683

And long TC one:
LLR: 2.96 (-2.94,2.94)
Total: 5762 W: 1108 L: 974 D: 3680

Bench: 4617880

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Use arrow operator instead of * and .

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Better condition in is_pseudo_legal()

Simplify occupied destination condition.

No functional change.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>

Small touches in move generation

No functional change.

Some renaming in MovePicker

No functional change.

Rewrite and simplify SEE

This very speed critical code was full of clever (!)
tricks and subtle details.

So I have rewritten it in a more straithforward way
and, as very often happens, result is even faster
than original.

No functional change.

Revert "Fix critical SEE bug (take 2)"

This reverts commit 3e95800814d

For some reason it fails the short TC test:
LLR: -2.96 (-2.94,2.94)
Total: 20033 W: 4214 L: 4265 D: 11554

bench: 4769737

Revert "Yet another attempt at signature-build"

Still broken on OS X

No functional change.