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.
Move game phase constants to enum Value

No functional change.
Reformatting in material.h

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
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 some useless casts

No functional change.
Fix Intel compiler warnings

Fallout from previous patch: Intel compiler
is very noisy.

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.
Remove other useless floor()

No functional change.
Minor stuff scattered around

Just random minor stuff I found while browsing the code.

No functional change.
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
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
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.
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.
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.
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
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.
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
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
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