Fix build under gcc

Also some warnings squashed.

No functional change.

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

Add threat evaluation

Give a bonus for each kind of attacked piece. Bonus
value is based on the type of attacked piece and the
type of attacking one.

Penalize pieces attacked by enemy pawns, also in
this case penality value depends on the type of
attacked piece.

This patch oboletes as redundant the increased mobility
count of the attcked squares that is then removed.

After 956 games at 1+0
Mod vs Orig  +262 =462 -232 51.57%  493.0/956 +11 ELO

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

Micro optimize mobility calculation

Take out of mobility loop a constant expression.

No functional change.

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

Unify capture and promotion tests

Small code cleanup and a bit faster too.

The only functional change is that in extension
in pv node we extend promotions and not only captures
when condition met.

This is practically an undetectable change and has
no impact on strenght.

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

Don't prune TT move in qsearch even if SEE < 0

Even if SEE is negative there is always a good possibility
that TT move is a cut move anyway. For instance a lot of
BXN exchanges that have negative SEE can very easily be
good exchanges.

A nice side effect is a bit reduced frequency of
see_sign() calls.

After 643 games at 1+0
Mod vs Orig +174 =327 -142 52.49%  337.5/643 +17 ELO

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

Pick best moves one per cycle instead of sorting

When the move list is very small, like captures normally
are, it is faster to pick the best move with a linear
scan, one per cycle.

This has the added advantage that the picked capture move is
very possibly a cut-off move, so that other searches are
avoided. For non-captures it is still faster to sort in
advance.

Because scan-and-pick alghortim is not stable, node count
has changed.

After 885 games at 1+0
Mod vs Orig +196 =510 -179 50.96%  451.0/885

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

Avoid a needless locking in sp_search()

Only in less then 2% of cases we have a new sp->bestValue,
so check before to lock and save a costly locking
most of the times.

Patch suggested by Joona.

No functional search.

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

Similarize pruning code in search() and sp_search()

Use futility pruning also in split points.
Do not use history pruning in split points when
getting mated.

After 1000 games on Joona QUAD
Orig - Mod: 496 - 504

Added an optimization to avoid a costly lock in the
very common case that sp->futilityValue <= sp->bestValue.
A test on a dual CPU shows only 114 hits on 23196 events,
so avoid a lock in all the other cases.

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

Use an homegrown insertion sort instead of std::sort()

It is stable and it is also a bit faster then std::sort()
on the tipical small move lists that we need to handle.

Verified to have same functionality of std::stable_sort()

After 999 games at 1+0
Mod vs Orig +240 =534 -225 50.75%  507.0/999  +5 ELO

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

Do not prune the move if we are still under mate

If after the first tried 2 + int(depth) moves we still
have no any move that takes us out of a mate then do
not prune the following move, it is more important to
escape mate then speed up search.

This fixes an odd behaviour regarding mates, as example
the following diagram is a mate in 4, not in 3 as bogusly
reported before this patch.

1B2n3/8/2R5/5p2/3kp1n1/4p3/B3K3/8 w - - bm #4;

The performance impact should be minimal, the increment
in searched nodes is less then 0.1 %%

Idea and patch by Joona

After 999 games at 1+0
Mod vs Orig +193 =604 -202  -3 ELO

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

Minor improvement in eval of unstoppable pawns promoting one ply apart.

Marco's new code for evaluating two unstoppable passed pawns where
one pawn promotes a single ply before the other tried to detect
cases where the pawn that promotes first could immediately capture
the pawn that promotes a ply later, but didn't work in cases where
the two pawns are on the same file. An example of this is the
following position:

8/8/3K4/2P5/2p5/3k4/8/8 w - -

With the new code, such positions are handled correctly.

Fix a crash when reaching PLY_MAX in a check position

In this case we call evaluate() being in check and this
is not allowed.

Bug found testing with reduced PLY_MAX value as suggested
by Miguel A. Ballicora on talkchess.

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

Add a new rule on promoting pawns in evaluate_passed_pawns()

Add a rule about the situation when one side queens exactly
one ply before the other. To avoid difficult (but luckly rare)
cases we only handle the case of free paths to queen for
both sides.

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

Fix x-ray attack from behind in evaluate_passed_pawns()

Fix a condition for x-ray attack of a queen or
a rook behind a pawn of us. Previous condition does
not check if the enemy slider behind our pawn is
really attacking the pawn.

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

Small cleanup and in evaluate_passed_pawns()

No functional change.

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

Revert "Use std::stable_sort() instead of std::sort()"

Unfortunatly std::stable_sort() implementation in gcc is
horrendously slow. We have a big performance regression on
Linux systems (-20% !)

So revert the commit and wait to fix the issue in a different
way, perhaps with an our home grown sorting, that should be
comparable in speed with std::sort()

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

Use std::stable_sort() instead of std::sort()

Standard does not mandate std::sort() to be stable, so we
can have, and actually do have different node count on
different platforms.

So use the platform independent std::stable_sort() and gain
same functionality on any platform (Windows, Unix, Mac OS)
and with any compiler (MSVC, gcc or Intel C++).

This sort is teoretically slower, but profiling shows only a very
minimal drop in performance, probably due to the fact that
the set to sort is very small, mainly only captures and with
less frequency non-captures, anyhow we are talking of 30-40 moves
in the worst average case. Sorting alghortims are build to work on
thousands or even milions of elements. With such small sets
performance difference seems not noticable.

After 999 games at 1+0

Mod vs Orig +234 =523 -242 -3 ELO

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

Unroll color loops in evaluate_passed_pawns()

Speed increase is on 1.5% on Intel pgo build.

No functional change.

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

Use piece_list to scan the pawns in evaluate_pawns()

No functional change and small speed increase.

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

Fix pieceList initialization in Position::clear()

We want piece list to be terminated with SQ_NONE.

This happens with all the pieces but the pawns that
being 8 make the inner loop exit just before writing
the SQ_NONE value at the tail of the list.

This bug was hidden because currently we don't use
piece list to scan pawns, but this will change in the
future and in any case an initialization should be done
correctly for the whole array to avoid subtle bugs in
the future.

No functional change.

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

Unroll color loops in get_pawn_info

This allow to resolve a lot of addresses at compile time
instead of an indirect access at runtime.

Speed up on pgo compile is of 1.3%

No functional change.

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

Small micro-optimization in get_pawn_info()

No functional change.

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

Restore pliesFromNull counter

It is not equivalent because the check for the
50 moves rule get badly affected.

// Draw by the 50 moves rule?
if (st->rule50 > 100 || (st->rule50 == 100 && !is_check()))
    return true;

So we _really_ need two counters.

Thanks to Joona and Tord to be patience with a silly guy ;-)

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

Fix an off-by-one bug in extract_pv()

In case we reach ply == PLY_MAX we exit the function
writing

pv[PLY_MAX] = MOVE_NONE;

And because SearchStack is defined as:

struct SearchStack {
  Move pv[PLY_MAX];
  Move currentMove;
  .....

We end up with the unwanted assignment

SearchStack.currentMove = MOVE_NONE;

Fortunatly this is harmless because currentMove is not used where
extarct_pv() is called. But neverthless this is a bug that
needs to be fixed.

Thanks to Uri Blass for spotting out this.

No functional change.

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

Rewrite previous patch using only one counter

Use only rule50 and retire pliesFromNull.

No functional change.

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

Do not claim repetition after null move

Null moves can artificially create a repetition
draw where instead there is no one.

So use a second counter to reset history after
a null move.

Idea from Joona.

After 999 games at 1+0

Mod vs Orig +238 =553 -208 51.50%  514.5/999  +10 ELO

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

Restore development version

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

Stockfish 1.5.1

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

Fix the polling frequency when pondering

When pondering InfiniteSearch == false but myTime == 0 so that
NodesBetweenPolls = 1000 instead of the standard.

The patch fixes the bug and is more robust because checks
directly myTime for a non-zero value, without relying on
an indirect test (InfiniteSearch in this case).

No functional change.

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

Use slightly lower polling frequency in the last few seconds.

Instead of checking the time every 100 nodes in the last second,
and every 1000 nodes in the last five seconds, Stockfish now checks
every 1000 nodes in the last second and every 5000 nodes in the last
five seconds.  This was tested in 1036 games at a time control of
40 moves/10 seconds, and no losses on time occured.

Also fixed a bug pointed out by Marco:  In infinite mode, myTime
is actually 0, but of course we still don't want to check the time
more frequently than the standard once per 30000 nodes in this
case.

Minor change to time management code, to make sure we don't lose on
time at the last move before the time control when there is very
little time left.

Display fail high/fail low in search log file.

Fix bogus comment in extract_pv()

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

Fix use of an initialized SearchStack

In RootMoveList c'tor we allocate a search stack and then
call directly qsearch.

There is called init_node() that clears all the fields of the search
stack array that refers to current ply but not the the killer moves.

The killer moves cleared correspond to ply+2.

In id_loop() this is not a problem because killer moves of
corresponding ply are cleared anyway few instructions later,
but in RootMoveList c'tor we leave them uninitialized.

This patch fixes this very old bug. It comes direclty
from Glaurung age.

Bug spotted by Valgrind.

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

Remove a redundant assignment in PawnInfo c'tor

We don't need to set key to 0 because clear() already
takes care of that.

No functional change.

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

Small code reformat in TranspositionTable::extract_pv()

In particular don't use an array of StateInfo, this
avoids a possible overflow and is in any case redundant.

Also pass as argument the pv[] array size to avoid a second
possible overflow on this one.

Fix suggested by Joona.

No functional change.

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

Fixed an embarassing Chess960 bug found by Alexander Schmidt.

It turned out that we used do_move_bb to update the king and rook
bitboards when making and unmaking castling moves, which obviously
doesn't work in Chess960, where the source and destination squares
for the king or rook could be identical.

No functional change in normal chess.

Restore development version

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

Stockfish 1.5

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

Small touches to increased mobility patch

No functional change.

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

Move a comment where it belongs in SEE

No functional change of course.

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

Don't increase mobility if attacked piece is defended by a pawn

If an enemy piece is defended by a pawn don't give the
extra mobility bonus in case we attack it.

Joona says that "Paralyzing pawn" is usually worth of nothing.

On Joona QUAD after 964 games:
Orig - Patch_2: 191 - 218 - 555 (+ 10 elo)

On my PC after 999 games at 1+0:
Mod vs Orig +227 =550 -222 50.25%  502.0/999  +2 ELO

In both cases we tested against the original version (without
increased mobility), not against the previous patch that instead
seems to fail on Joona QUAD:
Orig vs. Prev.Patch: 237 - 217 - 627 (-6 elo)

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

Count two times number of attacked pieces in mobility

Now in mobility we count enemy attacked pieces as
empty squares.

With this patch we try to give an higher score to positions
where the number of attacked pieces is higher.

After 999 games at 1+0

Mod vs Orig +262 =517 -219 52.15% 520.5/998 +15 ELO

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

Optimize futilityValue calculation

Avoid calling evaluate() if we already have the score in TT

No functional change.

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

Store pawn attacks in PawnInfo

They are pawn structure invariant so has a sense to
store togheter with pawn info instead of recalculating
them each time evaluate() is called.

Speed up is around 1%

No functional change.

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

Fixed a couple of typos in a comment.

No functional change, of course.

Fix a MSVC warning in search.cpp

No functional change.

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

Temporarily removed the unfinished UCI_Elo code in preparation for
the release of the public Stockfish 1.5.

Print RootMoveList startup scoring

This satisfies a specific user request of 28/8/2009

"The only issue I have is that during multiPV analysis, the depth 1
best move score is not reported by the engine (reporting for the best
move begins at depth 2).  I need it at depth 1 also. Would it be
possible to make this modification in future versions? This would be
of great help as otherwise I will have to use a lesser engine.

The goal of my project is to calculate the ELO performance in a game
and also the ELO rating of individual moves. For this I need depth 1
scores for lower rated performances. I intend to distribute the program
for free upon completion.

Thanks, Jack Welbourne"

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

Retire compute_weight() in evaluation.cpp

Is used only in weight_option() so inline there.
Unroll color loop also for evaluate_space() and
finally also some assorted code style fixes.

No functional change.

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

Unroll color loops in evaluate

Use templates to manually unroll the loops so that
many values could be calculated at compile time or at
runtime but with a fast direct memory access instead of
an indirect one.

This change gives a speed up of 3.5 % on pgo build !!!  :-)

No functional change.

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

Change back file mode of misc.cpp

It was erroneusly changed by 6bf22f35 from
mode 100644 to 100755.

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

Update piece list iteration also in evaluate_pieces()

Move to what we already do in generate_piece_moves()

This simple patch gives a spped up of 1.4% !!

No functional change.

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

Retire faked Windows version of gettimeofday()

Use equivalent Windows function _ftime() instead.

This patch also removes two long standing warnings
under MSVC.

No functional change and no change for non-Windows systems.

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

Micro optimization of generate_piece_moves()

This patch make the piece list always terminated by SQ_NONE,
so that we can use a simpler and faster loop in move
generation.

Speedup is about 0.6%.

No functional change.

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

Retire kingSquare[] array

It is redundant. Use pieceList[c][KING][0] instead.

No functional change.

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

Reorder data layout and optimize access patern

With this very simple patch we get a speed boost
of 0.8% on my PC !

Sometime we find the most complex tricks to increase speed
when instead the best results come from the simplest solutions.

No functional change of course ;-)

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

Fix a couple of Intel compiler warnings

And avoid calculating emptySquares for pawns captures
case.

No functional change.

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

Fix a piece_of_color_and_type() / pieceS_of_color_and_type() typo

Bug introduced in 17c51192

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

Rename generate_piece_moves() in generate_piece_evasions()

A better and more specific name. Also a bit of code reshuffle.

Verified No functional change and No performance change
for the whole series.

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

Retire generate_pawn_captures()

And unify in generate_pawn_noncaptures() renamed
generate_pawn_moves()

No functional change.

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

Retire generate_pawn_blocking_evasions()

And unify in generate_pawn_noncaptures()

No functional change.

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

Standardize generate_pawn_blocking_evasions()

Rewrite in the form normally used in other similar
functions like generate_pawn_noncaptures()

This allow an easier reading of the pawn moves generators
and simplify a bit the code.

No functional change (tested on more then 100M nodes).

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

Code style and subtle fix in move_is_legal()

A bunch of trivial code style and comment fixes.

Among them there is a real fix for a subtle case
involving promotion moves.

We currently check that a pawn push to 8/1th rank
must be a promotion, but we don't check the contary,
i.e. that a pawn push on a different rank must NOT be
a promotion. Note that, funny enough, we perform this
control for all the other pieces, but not for the pawns!

This patch fixes this really corner case.

No functional change.

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

Simplify move legality check for uncommon cases

Remove a bunch of difficult and tricky code to test
legality of castle and ep moves and instead use a slower
but simpler check against the list of generated legal moves.

Because these moves are very rare the performance impact
is small but code semplification is ver big: almost 100 lines
of difficult code removed !

No functionality change. No performance change (strangely enough
there is no even minimal performance regression in pgo builds but
instead a slightly and unexpected increase).

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

Enable functionality of previous patch

Now under-promotion checks are generated.

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

When generating checks add possibly under-promotions

In qsearch at depth 0 we generate only captures and checks.
Queen promotion moves are generated among the captures, but
under-promotion moves (both captures and non-captures) are
never generated even if they could give a discovery check.

This patch fixes this limitation extending generate_pawn_noncaptures()
to generate also check moves when required.

Apart for adding the (rare) case of an under-promotion that gives
discovery check, the patch is also a good cleanup because removes
generate_pawn_checks() altoghter.

This patch does the code clean-up but not enables the functional
change so to allow an easier debug.

No functional change and no performance change (actually a very
very small speed increase).

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

Fix a bug in generate_piece_checks()

We are generating also king moves that give check !

Of course these moves are illegal so are in any case
filtered out in MovePicker. Neverthless we should avoid
to generate them.

Also simplify a bit the code.

No functional change.

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

Small micro optimization in generate_evasions()

No functional change.

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

Change evaluation GrainSize from 4 to 8

Idea from Joona.

After 999 games at 1+0 on my Intel Core 2 Duo
Orig - Mod: +215 =538 -226 (+11 ELO)

On Joona QUAD after 845 games at 1+0
Orig - Mod: 151 - 181 - 513 (+13 elo)

So it seems a good change !

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

Save static evaluation also for failed low nodes

When a node fails low and bestValue is still equal to
the original static node evaluation, then save this
in TT along with usual info.

This will allow us to avoid a future costly evaluation() call.

This patch extends to failed low nodes what we already do
for failed high ones.

No functional change.

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

Revert evaluation drift

Still not clear if it helps and, especially, how it
helps. So revert for now to avoid any influence on
future feature now under test.

With this patch we come back to be functional
equivalent to patch e33c94883 F_53.

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

Evaluation drift: add always 7 instead of ply

After 828 games at 1+0

Mod vs Orig +191 =447 -190 50.06%  414.5/828

So almost no difference. Patch is committed more for
documentation purposes then for other reasons.

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

Rename piece_attacks_from() in attacks_from()

It is in line with attackers_to() and is shorter and
piece is already redundant because is passed as template
parameter anyway.

Integrate also pawn_attacks_from() in the attacks_from()
family so to have an uniform attack info API.

No functional change.

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

Remove undefined pinned_pieces(Color c, Bitboard& p)

It was added in revision 5f142ec2 but never used.

No functional change.

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

Retire attackers_to(Square s, Color c)

Use the definition in the few places where is needed.

As a nice side effect there is also an optimization in
generate_evasions() where the bitboard of enemy pieces
is computed only once and out of a tight loop.

No functional change.

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

Rename piece_attacks() in piece_attacks_from()

It is a bit longer but much easier to understand especially
for people new to the sources. I remember it was not trivial
for me to understand the returned attack bitboard refers to
attacks launched from the given square and not attacking the
given square.

No functional change.

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

Cleanup piece_attacks_square() functions

Most of them are not required to be public and are
used in one place only so remove them and use its
definitions.

Also rename piece_attacks_square() in piece_attacks()
to be aligned to the current naming policy.

No functional change.

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

Rename attacks_to() in attackers_to()

These functions return bitboard of attacking pieces,
not the attacks themselfs so reflect this in the name.

No functional change.

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

Change pawn_attacks() API

Instead of pawn_attacks(Color c, Square s) define as
pawn_attacks(Square s, Color c) to be more aligned to
the others attack info functions.

No functional change.

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

Clean up API for attack information

Remove undefined functions sliding_attacks() and ray_attacks()
and retire square_is_attacked(), use the corresponding definition
instead. It is more clear that we are computing full attack
info for the given square.

Alos fix some obsolete comments in move generation functions.

No functional change.

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

Move kingSquare[] array to StateInfo

This avoids to reverting back when undoing the move.

No functional change. No performance change.

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

Don't compensate TT for evaluation drift

It seems that it works better without compensation
of drifted value when saving static evaluation in TT.

After 818 games at 1+0

Mod vs Orig +217 =429 -172 52.75%  431.5/818  +19 ELO

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

Use WIN32_LEAN_AND_MEAN in lock.h

This avoids inclusion of a bunch of not very commonly
used headers from windows.h

No functional change.

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

Make static value saved in TT independent from ply

After 963 games at 1+0

Mod vs Orig +246 =511 -206 52.08%  501.0/962  +14 ELO

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

Evaluation drift

Increase evaluation score with ply.

After 940 games at 1+0

Mod vs Orig +247 =487 -206  +15 ELO

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

Fix semantic of piece_attacks<PAWN>

Return the bitboard with the pawn attacks for both colors
so to be aligned to the meaning of the others piece_attacks<Piece>
templates.

No functional change.

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

Indirectly prefetch board[from]

One of the most time critical functions is move_is_check()
and in particular the call to type_of_piece_on(from) in the
switch statement.

This call lookups in board[] array and can be slow if board[from]
is not already cached. Few instructions before in the execution stream,
we check the move for legality with pl_move_is_legal().

This patch changes pl_move_is_legal() to use type_of_piece_on(from)
for checking for a king move so that board[from] is automatically
cached in L1 and ready to be used by the near follower move_is_check()

Another advantage is that the call to king_square(us) in pl_move_is_legal()
is avoided most of the times.

Speed up of this nice and tricky patch is 0.7% !

No functional change.

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

Retire piece_is_slider(PieceType pt)

Is not used in any part of the sources.

No functional change, of course ;-)

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

Second take at unifying bitboard representation access

This patch is built on Tord idea to use functions instead of
templates to access position's bitboards. This has the added advantage
that we don't need fallback functions for cases where the piece
type or the color is a variable and not a constant.

Also added Joona suggestion to workaround request for two types
of pieces like bishop_and_queens() and rook_and_queens().

No functionality or performance change.

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

Templetize functions to get pieces by type

Use a single template to get bitboard representation of
the position given the type of piece as a constant.

This removes almost 80 lines of code and introduces an
uniform notation to be used for querying for piece type.

No functional change and no performance change.

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

Set LMRPVMoves to 10 instead of 14

After 934 games at 1+0

Mod vs Orig +228 =493 -213 50.80%  474.5/934   +6 ELO

So it seems not negative and there is also the added
benefit to unify LMRPVMoves use in search_pv() and in
root list.

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

Fix poly values mismerge

I managed to completely mismerge correct values
for QuadraticCoefficientsOppositeColor table :-(

Now it correspond to tuning branch for real.

After 999 games at 1+0

Mod vs Orig +247 =512 -240 50.35%  503.0/999  +2 ELO

So almost no change, but the new values comes from the
same tuning session of the others, so has more sense to
use these ones.

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

Bug fix for discovered checks in connected_moves().

Because of a hard-to-spot single-character bug in connected_moves(),
the discovered check code had no effect whatsoever. The condition
in the if (...) statement at the beginning of the code would always
return false.

Thanks to Edsel Apostol for pointing out this bug!

Retire pieces_of_color_and_type()

It is used mainly in a bunch of inline oneliners
just below its definition. So substitute it with
the explicit definition and avoid information hiding.

No functional change.

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

MovePicker: rename number_of_moves() in number_of_evasions()

It is more clear that only in that case the move number is
correct, otherwise is only a partial quantity: the number of
moves of that phase.

In case of PH_EVASIONS instead we have only one phase.

No functional change.

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

Use pointers instead of array indices also for badCaptures

To have uniformity with moves array handling.

No functional change.

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

Document index[] and pieceList[] are not invariants

Array index[] and pieceList[] are not guaranteed to be
invariant to a do_move() + undo_move() sequence when a
capture move is involved.

The reason is that the captured piece is removed form
the list and substituted with the last one in do_move()
while in undo_move() is added again but at the end of
the list.

Because index[] and pieceList[] are used in move generation
to scan the pieces it means that moves will be generated
in a different order before and after a do_move() + undo_move()
sequence as, for instance, the one in Position::has_mate_threat()

After latest patches, move generation could now be invoked
also by MovePicker c'tor and this explains why order of
picked moves is different if MovePicker object is istantiated
before or after a Position::has_mate_threat() call.

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

Workaround a bug in Position::has_mate_threat()

It seems that pos.has_mate_threat() changes the position !

So that calling MovePicker c'tor before or after the
has_mate_threat() call changes the things !

Bug was unhidden by previous patch that makes MovePicker c'tor
to generate, score and sort good captures under some circumstances.

Because scoring the captures is position dependent it seems that
the moves returned by MovePicker are different when c'tor is
called before has_mate_threat()

Of course this is only a workaround because the real bug is still
hidden :-(

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

Skip TT_MOVES phase when possible

If we don't have tt moves to search skip the
useless loop associated with TT_MOVES phase.

Another 1% speed boost that brings this series
to a +6.2% against original revision 595a90df

No functional change.

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