stockfish
6 years agoBonus for file distance of the outermost pawns
Stefan Geschwentner [Tue, 24 Dec 2013 22:37:34 +0000 (23:37 +0100)]
Bonus for file distance of the outermost pawns

In endgame it's better to have pawns on both wings.
So give a bonus according to file distance between left
and right outermost pawns.

Passed both short TC
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 39073 W: 7749 L: 7536 D: 23788

And long TC
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 6149 W: 1040 L: 910 D: 4199

bench: 7665034

6 years agoLoosened trigger condition for king safety
Ralph Stößer [Sun, 22 Dec 2013 11:00:09 +0000 (12:00 +0100)]
Loosened trigger condition for king safety

Reduce eval discontinuity becuase now we kick in
king safety evaluation in many more cases.

Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 8708 W: 1742 L: 1613 D: 5353

And long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 6743 W: 1122 L: 990 D: 4631

bench: 6835416

6 years agoIncrease pawn king attack weight
Chris Caino [Mon, 23 Dec 2013 19:50:28 +0000 (20:50 +0100)]
Increase pawn king attack weight

Tighter lower bound for pawn attacks so to
activate king safety in some cases like here:

6k1/2B3p1/2Pp1p2/2nPp3/2Q1P2K/P2n1qP1/R6P/1R6 w

Original patch by Chris, further simplified by
Jörg Oster.

Passed both short TC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 30171 W: 5887 L: 5700 D: 18584

And long TC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 20706 W: 3402 L: 3204 D: 14100

bench: 7607562

6 years agoFaster and simplified threat eval
Gary Linscott [Wed, 18 Dec 2013 19:00:01 +0000 (14:00 -0500)]
Faster and simplified threat eval

Add a bonus according if the attacking
pieces are minor or major.

Passed both short TC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 13142 W: 2625 L: 2483 D: 8034

And long TC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 18059 W: 3031 L: 2844 D: 12184

bench: 7425809

6 years agoFurther simplify Makefile
Marco Costalba [Tue, 17 Dec 2013 09:14:15 +0000 (10:14 +0100)]
Further simplify Makefile

No functional change.

6 years agoReformat Makefile
Marco Costalba [Tue, 17 Dec 2013 08:30:42 +0000 (09:30 +0100)]
Reformat Makefile

No functional change.

6 years agoRemove threat move stuff
Lucas Braesch [Sat, 14 Dec 2013 11:27:29 +0000 (19:27 +0800)]
Remove threat move stuff

A great simplification that shows no regression
and it seems even a bit scalable.

Tested with fixed number of games:

Short TC
ELO: 0.60 +-2.1 (95%) LOS: 71.1%
Total: 39554 W: 7477 L: 7409 D: 24668

Long TC
ELO: 2.97 +-2.0 (95%) LOS: 99.8%
Total: 36424 W: 5894 L: 5583 D: 24947

bench: 8184352

6 years agoSync history and counter moves updating
Marco Costalba [Tue, 10 Dec 2013 06:05:06 +0000 (07:05 +0100)]
Sync history and counter moves updating

Change updating rule after a TT hit to match
the same one at the end of the search.

Small change in functionality, but we want to
have uniform rules in the code.

bench: 7767864

6 years agoUpdate History and Counter move on TT hit
Lucas Braesch [Mon, 9 Dec 2013 10:14:14 +0000 (18:14 +0800)]
Update History and Counter move on TT hit

We already update killers so it is natural to extend to
history and counter move too.

Passed both short TC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 52690 W: 9955 L: 9712 D: 33023

And long TC
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 5555 W: 935 L: 808 D: 3812

bench: 7876473

6 years agoResearch at intermediate depth if LMR is very high
Ralph Stößer [Mon, 9 Dec 2013 07:02:49 +0000 (08:02 +0100)]
Research at intermediate depth if LMR is very high

After a fail high in LMR, if reduction is very high do
a research at lower depth before teh full depth one.
Chances are that the re-search will fail low and the
full depth one is skipped.

Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 11363 W: 2204 L: 2069 D: 7090

And long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 7292 W: 1195 L: 1061 D: 5036

bench: 7869223

6 years agoMore work on Bitboards::init()
Marco Costalba [Sat, 7 Dec 2013 11:09:33 +0000 (12:09 +0100)]
More work on Bitboards::init()

No functional change.

6 years agoMore readable init of MS1BTable[]
Marco Costalba [Sat, 7 Dec 2013 10:33:31 +0000 (11:33 +0100)]
More readable init of MS1BTable[]

Because now it uses lsb(), the BSFTable[] must be
already initialized.

No functional change.

6 years agoFurther simplify Bitboards init()
Marco Costalba [Sat, 7 Dec 2013 09:57:05 +0000 (10:57 +0100)]
Further simplify Bitboards init()

No functional change.

6 years agoClarify definition of capture_or_promotion()
Marco Costalba [Fri, 6 Dec 2013 09:43:17 +0000 (10:43 +0100)]
Clarify definition of capture_or_promotion()

No functional change.

6 years agoEven more spelling fixes
Arjun Temurnikar [Thu, 5 Dec 2013 06:18:12 +0000 (07:18 +0100)]
Even more spelling fixes

No functional change.

6 years agoAssorted spelling/grammar/captitalization
Arjun Temurnikar [Wed, 4 Dec 2013 21:57:00 +0000 (13:57 -0800)]
Assorted spelling/grammar/captitalization

No functional change.

6 years agoMicro-optimise dangerous condition
Chris Caino [Wed, 4 Dec 2013 15:49:01 +0000 (15:49 +0000)]
Micro-optimise dangerous condition

Since all ENPASSANT moves are now considered dangerous, this
change of order should give a slight speedup.

Also simplify futilityValue formula.

No functional change.

6 years agoRetire TheirHalf[]
Marco Costalba [Wed, 4 Dec 2013 16:24:32 +0000 (17:24 +0100)]
Retire TheirHalf[]

We avoid to use an ad-hoc table at the cost of a
relative_rank() call in advanced_pawn_push().

On my 32 bit system it is even slightly faster (on 64bit
may be different). This is the speed in nps alternating
old and new bench runs:

new

368890
368825
369972

old

367798
367635
368026

No functional change.

6 years agoBroader condition for dangerous pawn moves
Chris Caino [Tue, 3 Dec 2013 21:58:39 +0000 (21:58 +0000)]
Broader condition for dangerous pawn moves

Instead of a passed pawn now we just require the pawn to
be in the opponent camp to be considered a dangerous
move. Added some renaming to reflect the change.

Passed both short TC test
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 10358 W: 2033 L: 1900 D: 6425

And long TC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 21459 W: 3486 L: 3286 D: 14687

bench: 8322172

6 years agoShrink Position::is_draw()
Marco Costalba [Tue, 3 Dec 2013 10:37:29 +0000 (11:37 +0100)]
Shrink Position::is_draw()

No functional change.

6 years agoRemove redundant argument from hidden_checkers()
Marco Costalba [Tue, 3 Dec 2013 10:06:59 +0000 (11:06 +0100)]
Remove redundant argument from hidden_checkers()

No functional change.

6 years agoSmall improvment to Position::fen()
Marco Costalba [Tue, 3 Dec 2013 09:09:17 +0000 (10:09 +0100)]
Small improvment to Position::fen()

No functional change.

6 years agoRe-fix a comment
Jerry Donald [Tue, 3 Dec 2013 07:50:00 +0000 (08:50 +0100)]
Re-fix a comment

No functional change.

6 years agoAnother round of spelling fixes
Jerry Donald [Mon, 2 Dec 2013 22:47:38 +0000 (23:47 +0100)]
Another round of spelling fixes

And also renamed a loop variable while there.

No functional change.

6 years agoBig assorted spelling fixes
Richard Lloyd [Mon, 2 Dec 2013 18:04:09 +0000 (19:04 +0100)]
Big assorted spelling fixes

No functional change.

6 years agoAssorted spelling fixes
Jerry Donald [Mon, 2 Dec 2013 17:39:26 +0000 (18:39 +0100)]
Assorted spelling fixes

No functional change.

6 years agoRename CASTLE to CASTLING
Marco Costalba [Sun, 1 Dec 2013 09:25:10 +0000 (10:25 +0100)]
Rename CASTLE to CASTLING

It is call 'castling move', not 'castle move'

Noticed while reading DiscoCheck sources.

No functional change.

6 years agoSimplify a condition in gives_check()
Marco Costalba [Sun, 1 Dec 2013 09:07:16 +0000 (10:07 +0100)]
Simplify a condition in gives_check()

Now that aligned() is quite fast we can skip
some logic.

No functional change.

6 years agoRename Bitboards print to pretty
Marco Costalba [Sat, 30 Nov 2013 10:25:05 +0000 (11:25 +0100)]
Rename Bitboards print to pretty

To align to same named Position function and
avoid using std::cout directly.

Also remove some stale <iostream> include while
there.

No functional change.

6 years agoRewrite some bitboard init code
Marco Costalba [Sat, 30 Nov 2013 09:27:23 +0000 (10:27 +0100)]
Rewrite some bitboard init code

And move the static function Position::attacks_from() to
bitboard code renaming it attacks_bb()

No functional change.

6 years agoMakefile improvements for compiling on OS X
Daylen Yang [Fri, 29 Nov 2013 21:30:28 +0000 (13:30 -0800)]
Makefile improvements for compiling on OS X

Add a Mac SSE4.2 target. Also change the Mac OS X minimum version to
10.6. Rationale: 97% of Macs run at least 10.6, version 10.9 is now
free, and using 10.6 as the minimum version gives a small 5% boost in
benchmark speed over versions using 10.0 as the minimum version.

Finally, enable Clang’s Link Time Optimization when compiling for the
Mac.

No functional change.

6 years agoRestore development version
Marco Costalba [Fri, 29 Nov 2013 09:50:14 +0000 (10:50 +0100)]
Restore development version

bench: 8596156

6 years agoStockfish DD
Marco Costalba [Fri, 29 Nov 2013 09:23:14 +0000 (10:23 +0100)]
Stockfish DD

Stockfish bench signature is: 8596156

6 years agoAdd support for PPC 64bit on Linux
Kelly Wilson [Fri, 29 Nov 2013 08:59:16 +0000 (09:59 +0100)]
Add support for PPC 64bit on Linux

In particular Debian Linux-3.9.8-1- PPC64

No functional change.

6 years agoGenerate Qsearch checks only at depth 0
Joona Kiiski [Wed, 20 Nov 2013 20:39:57 +0000 (20:39 +0000)]
Generate Qsearch checks only at depth 0

An old idea retested at SPRT(0, 3) with 60+0.05 TC:
LLR: 2.95 (-2.94,2.94) [0.00,3.00]
Total: 98872 W: 15549 L: 15123 D: 68200

This is a very small elo increase patch so it really
stresses the limits of fishtest.

bench: 8596156

6 years agoRevert previous fix
Marco Costalba [Tue, 19 Nov 2013 06:19:28 +0000 (07:19 +0100)]
Revert previous fix

It seems to intorduce a regression when tested
with 3 threads at 15+0.05:

ELO: -2.26 +-2.2 (95%) LOS: 2.4%
Total: 30000 W: 4813 L: 5008 D: 20179

bench: 8331357

6 years agoGet correct excluded moves for split nodes
Hongzhi Cheng [Mon, 18 Nov 2013 15:41:19 +0000 (16:41 +0100)]
Get correct excluded moves for split nodes

Tested setting FakeSplit to true and running

./stockfish bench 128 2

There is a different signature with and without
the patch so it affects functionality but
only in SMP case.

bench: 8331357

6 years agoRevert previous patch
Marco Costalba [Sun, 17 Nov 2013 22:47:18 +0000 (23:47 +0100)]
Revert previous patch

It seems a regression at 15+0.05:
ELO: -4.82 +-2.1 (95%) LOS: 0.0%
Total: 40000 W: 7181 L: 7736 D: 25083

bench: 8331357

6 years agoFix an assert in SMP case
Marco Costalba [Sun, 17 Nov 2013 09:15:45 +0000 (10:15 +0100)]
Fix an assert in SMP case

SMP case is very tricky and raises an assert in stage_moves():

assert(stage == KILLERS_S1 || stage == QUIETS_1_S1 || stage == QUIETS_2_S1)

So rewrite the code to just return moves[] when we are sure
we are in quiet moves stages.

Also rename stage_moves to quiet_moves to reflect that.

No functional change (but needs testing in SMP case)

6 years agoRetire quietsSearched[]
Marco Costalba [Sun, 17 Nov 2013 08:12:19 +0000 (09:12 +0100)]
Retire quietsSearched[]

Use MovePicker moves[] to access already tried
quiet moves. A bit of care shall be taken
to avoid calling stage_moves() when we are still
at ttMove stage, because moves are yet to be
generated. Actually our staging move generation
makes this code a bit more tricky than what I'd
like, but removing an ausiliary redundant
array like quietsSearched[] is a good thing.

Idea by DiscoCheck

bench: 9355734

6 years agoSimplify generate<EVASIONS>
Marco Costalba [Mon, 11 Nov 2013 18:48:29 +0000 (19:48 +0100)]
Simplify generate<EVASIONS>

Use the newly introduced LineBB[] to simplify this
super hot-path function.

Verified with perft we don't have any speed regression, although
the number of squares removed is less than before in case of
contact check.

Insipred by DiscoCheck implementation.

Perft numbers are the same, but we have an harmless functional
change due to reorder of moves, because now some illegal moves
are no more detected at generation time, but in the search.

bench: 8331357

6 years agoFaster castling in Chess960 case
Gregor Cramer [Mon, 11 Nov 2013 14:54:12 +0000 (15:54 +0100)]
Faster castling in Chess960 case

Only rook attackers has to be considered, all other attackers are
already handled in the lines above.

No functional change.

6 years agoReintroduce gains
Joona Kiiski [Sun, 10 Nov 2013 14:53:23 +0000 (14:53 +0000)]
Reintroduce gains

This seems a die hard idea :-)

Passed both short TC
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 17485 W: 3307 L: 3156 D: 11022

And long TC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 38181 W: 6002 L: 5729 D: 26450

bench: 8659830

6 years agoRemove opposed flag for doubled pawns
Jörg Oster [Sun, 10 Nov 2013 14:24:32 +0000 (15:24 +0100)]
Remove opposed flag for doubled pawns

Actually, it is not used, as both arrays have the
same values. Some local tests in either direction
showed no improvement.

Also some minor corrections in the comments.

No functional change.

6 years agoRename squares_aligned()
Marco Costalba [Sun, 10 Nov 2013 16:14:46 +0000 (17:14 +0100)]
Rename squares_aligned()

Rename to the shorter but still
clear aligned()

No functional change.

6 years agoSimplify squares_aligned()
Marco Costalba [Sun, 10 Nov 2013 11:00:15 +0000 (12:00 +0100)]
Simplify squares_aligned()

Use newly introduced LineBB[]

No functional change.

6 years agoEvaluate mobility of pinned pieces exactly
Chris Caino [Sat, 9 Nov 2013 02:06:47 +0000 (02:06 +0000)]
Evaluate mobility of pinned pieces exactly

Previously some squares could be "incorrectly" awarded
to a pinned piece.

e.g. in 3k4/1q6/3b4/3Q4/8/5K2/B7/8 b - - 0 1 the black
bishop get 4 squares too many and the white queen gets 6.

Passed both short TC.
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 4871 W: 934 L: 817 D: 3120

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 38968 W: 6113 L: 5837 D: 27018

bench: 9282549

6 years agoRemove RedundantMajor
Chris Caino [Thu, 7 Nov 2013 18:28:57 +0000 (18:28 +0000)]
Remove RedundantMajor

But compensate by reducing rook and queen
value by 53 = (160 / 3)

Material imbalances are affected as follows:

       Red. Major   Rook  Queen  Total
QRR      +160      -2*53    -53     +1
QR       +160        -53    -53    +54
RR       +160      -2*53      0    +54
R           0        -53      0    -53
Q           0          0    -53    -53

so that the imbalance changes by at most 54 + 53 = 107 units.
This corresponds to appromximately 3.5cp in the final evaluation.

Verified with fixed number 40000 games at both short
and long TC it does not regress.

Short TC 15+0.05
ELO: 1.93 +-2.1 (95%) LOS: 96.6%
Total: 40000 W: 7520 L: 7298 D: 25182

Long TC 60+0.05
ELO: -0.33 +-1.9 (95%) LOS: 36.5%
Total: 39663 W: 6067 L: 6105 D: 27491

bench: 6703846

6 years agoFix printing of incorrect PV in some cases
Marco Costalba [Sat, 9 Nov 2013 18:04:51 +0000 (19:04 +0100)]
Fix printing of incorrect PV in some cases

As, Gary (that analyzed the bug) says:

SF does not print a PV when the original best move fails low,
we hit our time allowance, and stop the search.  The output from
the SF search is below.  It was failing low on Ne1 at depth 34.
Then, we get bestmove Qd3, but no PV change.

info depth 34 seldepth 45 score cp 38 upperbound nodes 483484489 nps 15464575 time 31264 multipv 1 pv f3e1 h5h4 e1d3 h4g3 f2g3 a6f6 f1f6 e7f6 d1a4 f6e7 a1f1 d8f8 a4b3 b7b6 b3c2 f7f6 c2a4 h3g5 b2b3 g5f7 a4c6 f7d6 h1g2 f6f5 e4f5 d6f5
info depth 34 seldepth 45 score cp 38 upperbound nodes 483484489 nps 15464575 time 31264 multipv 1 pv f3e1 h5h4 e1d3 h4g3 f2g3 a6f6 f1f6 e7f6 d1a4 f6e7 a1f1 d8f8 a4b3 b7b6 b3c2 f7f6 c2a4 h3g5 b2b3 g5f7 a4c6 f7d6 h1g2 f6f5 e4f5 d6f5
info depth 34 seldepth 47 score cp 30 upperbound nodes 2112334132 nps 17255517 time 122415 multipv 1 pv f3e1 h5h4 d1a4 a6f6 e1d3 d8f8 a4c2 h4g3 f2g3 f6f1 a1f1 h7g8 b2b3 f7f6 a3a4 b7b6
info depth 34 seldepth 47 score cp 30 upperbound nodes 2112334132 nps 17255517 time 122415 multipv 1 pv f3e1 h5h4 d1a4 a6f6 e1d3 d8f8 a4c2 h4g3 f2g3 f6f1 a1f1 h7g8 b2b3 f7f6 a3a4 b7b6
info nodes 18235667001 time 969824
bestmove e2d3 ponder c8d7

Looking at the code, if we hit Signals.stop, we return from id_loop
before printing any PV.  It is possible for us to have resorted the
RootMove list though, which will change the move that is actually
played.

No functional change.

6 years agoFix compile in debug mode
Marco Costalba [Sat, 9 Nov 2013 17:41:51 +0000 (18:41 +0100)]
Fix compile in debug mode

No functional change.

6 years agoFutility pruning simplification
Lucas Braesch [Fri, 8 Nov 2013 10:42:22 +0000 (18:42 +0800)]
Futility pruning simplification

1/ eval margin and gains removed:
16bit are now free on TT entries, due to the removal of eval margin. may be useful
in the future :) gains removed: use instead by Value(128). search() and qsearch()
are now consistent in this regard.

2/ futility_margin()
linear formula instead of complex (log(depth), movecount) formula.

3/ unify pre & post futility pruning
pre futility pruning used depth < 7 plies, while post futility pruning used
depth < 4 plies. Now it's always depth < 7.

Tested with fixed number of games both at short TC:
ELO: 0.82 +-2.1 (95%) LOS: 77.3%
Total: 40000 W: 7939 L: 7845 D: 24216

And long TC
ELO: 0.59 +-2.0 (95%) LOS: 71.9%
Total: 40000 W: 6876 L: 6808 D: 26316

bench 7243575

6 years agoRevert "Retire eval margin and gains"
Marco Costalba [Thu, 7 Nov 2013 21:29:07 +0000 (22:29 +0100)]
Revert "Retire eval margin and gains"

This reverts commit ecd07e51d0f03ccd3e41e5634518b299989254dd.

Patch was incorrect and partial. It will be reapplied in
the correct form.

bench: 9189063

6 years agoRestrict mobility of pinned pieces
Gary Linscott [Thu, 7 Nov 2013 18:59:11 +0000 (13:59 -0500)]
Restrict mobility of pinned pieces

Passed both short TC:
LLR: 3.00 (-2.94,2.94) [-1.50,4.50]
Total: 54342 W: 10950 L: 10692 D: 32700

And long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 61976 W: 10654 L: 10251 D: 41071

This patch introduces a slowdown of 3.5 % !!!!!

bench: 7911558

6 years agoRetire eval margin and gains
Lucas Braesch [Wed, 30 Oct 2013 03:22:42 +0000 (11:22 +0800)]
Retire eval margin and gains

1/ eval margin and gains removed:
 - gains removed by Value(128): search() and qsearch() now behave consistently!

2/ futility_margin()
 - testing showed that there is no added value in this weird (log(depth), movecount)
   formula, and a much simpler linear formula is just as good. In fact, it is most
   likely better, as it is not yet optimally tuned.
 - the new simplified formula also means we get rid of FutilityMargins[], its
   initialization code, and more importantly ss->futilityMoveCount, and the hacky
   code that updates it throughout the search().
 - the current formula gives negative futility margins, and there is a hidden interaction
   between the move coutn pruning formula and the futility margin one: what happens is
   that MCP is supposed to be triggered before we use the non-sensical negative futility
   margins.

3/ unify pre & post futility pruning
 - pre futility pruning (what SF calls value based pruning) used depth < 7 plies,
   while post futility pruning (what SF calls static null move pruning) used depth < 4 plies.
 - also the condition depth < 7 in pre futility pruning was not obvious, and it seemd
   to be depth < 16 (futility_margin() returns an infinite value when depth >= 7).

Tested with fixed number of games both at short TC:
ELO: 0.82 +-2.1 (95%) LOS: 77.3%
Total: 40000 W: 7939 L: 7845 D: 24216

And long TC
ELO: 0.59 +-2.0 (95%) LOS: 71.9%
Total: 40000 W: 6876 L: 6808 D: 26316

bench: 10206576

6 years agoTwo more parameters eliminated
Chris Caino [Mon, 4 Nov 2013 17:03:02 +0000 (17:03 +0000)]
Two more parameters eliminated

RedundantRook and RedundantQueen replaced by simple
variable RedundantMajor. Also the SameColor coefficient
for Queen<->Queen has been set by definition to 0.

The remaining 5 parameters:

LinearCoefficients[ROOK]
LinearCoefficients[QUEEN]
QuadraticCoefficientsSameColor[ROOK][ROOK]
QuadraticCoefficientsSameColor[QUEEN][ROOK]
RedundantMajor

are sufficient to equate the material imbalances for the
5 common material configurations of R, RR, Q, QR and QRR
to any desired values simultaneously.

With the chosen parameters there should be no functional
change unless one side has more than 2 rooks or more
than 1 queen. For example bench from the start position
using the commands:

./stockfish
go depth 16

produces identical output except for one extra node
in the last iteration.

bench: 8198094

6 years agoZero more redundant coefficients
Chris Caino [Mon, 4 Nov 2013 15:20:17 +0000 (15:20 +0000)]
Zero more redundant coefficients

Coefficients for Bishop<->BishopPair and Bishop<->Bishop
are also pretty much redundant. By altering the values
in LinearCoefficients[] these coefficients can be zeroed
without changing the imbalance calculations in any position
with less than 3 bishops for one side.

bench: 7995098

6 years agoZero redundant material imbalance terms
Chris Caino [Mon, 4 Nov 2013 12:44:42 +0000 (12:44 +0000)]
Zero redundant material imbalance terms

First coefficient in the SameColor array does an
equivalent job when folded into the LinearCoefficients
array.

All of the diagonal terms in the OppositeColor array
are redundant due to cancellation.

No functional change.

6 years agoTest Easy Move if no BestMoveChanges
Joona Kiiski [Fri, 1 Nov 2013 20:42:47 +0000 (20:42 +0000)]
Test Easy Move if no BestMoveChanges

In case we find a very good move after a
troubled start, we don't return immediately
anymore.

Tested directly at long TC where it passed:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 13910 W: 2397 L: 2228 D: 9285

bench: 7995098

6 years agoSet timer to a fixed interval
Marco Costalba [Fri, 1 Nov 2013 07:53:29 +0000 (08:53 +0100)]
Set timer to a fixed interval

And remove a complex (and broken) formula.

Indeed previous code was broken in case of TC with big
time increments where available_time() was too similar
to total time yielding to many time losses, so for instance:

go wtime 2600 winc 2600
info nodes 4432770 time 2601 <-- time forfeit!

maximum search time = 2530 ms
available_time = 2300 ms

For a reference and further details see:

https://groups.google.com/forum/?fromgroups=#!topic/fishcooking/dCPAvQDcm2E

Speed tested with bench disabling timer alltogheter vs timer set at
max resolution, showed we have no speed regressions both in single
core and when using all physical cores.

No functional change.

6 years agoUse a formula for chain membership bonus
Ralph Stößer [Thu, 31 Oct 2013 05:02:17 +0000 (06:02 +0100)]
Use a formula for chain membership bonus

Passed both short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 5087 W: 1072 L: 951 D: 3064

And long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 28620 W: 5042 L: 4798 D: 18780

bench: 7995098

7 years agoTweak bishop pair and knight weight
Marco Costalba [Mon, 28 Oct 2013 18:31:10 +0000 (19:31 +0100)]
Tweak bishop pair and knight weight

A combo of two patches that failed SPRT with score
higher than 50% but togheter they succeed:

SPRT at 60+0.05
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 7312 W: 1276 L: 1139 D: 4897

bench: 8029334

7 years agoFix divide by zero bug in late game
Matthew Sullivan [Fri, 25 Oct 2013 16:22:43 +0000 (11:22 -0500)]
Fix divide by zero bug in late game

If the game got late enough that move_importance(currentPly) * slowMover / 100
rounds to 0, then we ended up dividing 0 by 0 when only looking 1 move ahead.

This apparently caused the search to almost immediately abort and Stockfish
would blunder in long games. So convert thisMoveImportance to a double.

No functional change.

7 years agoRetire mirror()
Marco Costalba [Thu, 24 Oct 2013 18:38:02 +0000 (20:38 +0200)]
Retire mirror()

Inline the only caller site.

No functional change.

7 years agoPrefer file_bb() to FileBB[]
Marco Costalba [Thu, 24 Oct 2013 18:34:11 +0000 (20:34 +0200)]
Prefer file_bb() to FileBB[]

No functional change.

7 years agoPenalty for Knight when enemy pawns are few
Jörg Oster [Sun, 20 Oct 2013 18:59:48 +0000 (20:59 +0200)]
Penalty for Knight when enemy pawns are few

This seems more a material imbalance topic,
anyhow test is good and so patch is applied
as is.

Passed both short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 17391 W: 3548 L: 3393 D: 10450

And long TC:
LLR: 3.00 (-2.94,2.94) [0.00,6.00]
Total: 34660 W: 5972 L: 5700 D: 22988

bench: 8291883

7 years agoFurther smplify pawn endgames
Marco Costalba [Wed, 23 Oct 2013 13:50:20 +0000 (15:50 +0200)]
Further smplify pawn endgames

Dumb down a bit the code and trade some possible
speed (but this is far from hot path anyhow) for
some added readability for the layman.

No functional change.

7 years agoUse flip_sq idea in endgame.cpp
Chris Caino [Tue, 22 Oct 2013 22:03:45 +0000 (23:03 +0100)]
Use flip_sq idea in endgame.cpp

The normalising transformation is computed all at
once by the helper function get_flip_sq and then
applied immediately to the relevant squares as soon
as they are loaded from the position class.

bench: 8350690

7 years agoSimplify futility move count formula
Chris Caino [Tue, 22 Oct 2013 21:02:38 +0000 (23:02 +0200)]
Simplify futility move count formula

Simpler formula but introduces some slight changes if d >= 10

Original code grows like  0.225 * d^1.8
New code grows like       0.222 * d^1.8

Full list of values:

d old new diff
--------------
0 2 2 0
1 2 2 0
2 3 3 0
3 4 4 0
4 5 5 0
5 6 6 0
6 7 7 0
7 9 9 0
8 11 11 0
9 13 13 0
10 15 16 1
11 18 19 1
12 21 21 0
13 24 24 0
14 27 28 1
15 31 31 0
16 35 35 0
17 39 38 -1
18 42 42 0
19 47 46 -1
20 51 51 0
21 55 55 0
22 60 60 0
23 65 65 0
24 70 70 0
25 75 75 0
26 81 80 -1
27 87 86 -1
28 92 91 -1
29 98 97 -1
30 104 103 -1
31 111 109 -2

Test code:

int main() {

  for(int d=0; d<32; d++)
  {
     int a = int(3 + 0.3 * pow(double(d), 1.8)) * 3/4 + (2 < d && d < 5);
     int b = int(2.4 + 0.222 * pow(d + 0.0, 1.8));

     std::cout << d << " " << a << " " << b << " " << b-a << std::endl;
  }

  return 0;
}

bench: 8350690

7 years agoSimplify futility margins formula
Chris Caino [Tue, 22 Oct 2013 21:05:15 +0000 (23:05 +0200)]
Simplify futility margins formula

New formula mathces the old formula until d = 45

Test code:

int main() {

  for(int d=1; d<=45; d++)
  {
     int a = int(log(double(d * d) / 2) / log(2.0) + 1.001);
     int b = int(2.9 * log(double(d)));

     if (a != b) std::cout << d << std::endl;
  }

  return 0;
}

bench: 8455956

7 years agoTweak again chain pawn bonus
Marco Costalba [Tue, 22 Oct 2013 15:47:16 +0000 (17:47 +0200)]
Tweak again chain pawn bonus

This is the first chain bonus version
from Ralph that also passed both

Short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 23460 W: 4727 L: 4556 D: 14177

And long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 31858 W: 5497 L: 5240 D: 21121

And performed better against current
committed version, always at 60secs:

LLR: -2.94 (-2.94,2.94) [-3.00,3.00]
Total: 26301 W: 4477 L: 4580 D: 17244

This test was done by Leonid.

bench: 8455956

7 years agoRe-add "Further increase safe checks bonus"
Marco Costalba [Tue, 22 Oct 2013 15:33:11 +0000 (17:33 +0200)]
Re-add "Further increase safe checks bonus"

After 40K games at 60 secs, result is still
not clear, but not a regression against SF 4

After
ELO: 50.11 +-2.1 (95%) LOS: 100.0%
Total: 40000 W: 10547 L: 4817 D: 24636

Before
ELO: 49.51 +-2.1 (95%) LOS: 100.0%
Total: 40000 W: 10483 L: 4821 D: 24696

So re-apply the patch to avoid to
special-case this one.

bench: 7403882

7 years agoRestore behaviour after count<ALL_PIECES> fix
Marco Costalba [Tue, 22 Oct 2013 15:27:58 +0000 (17:27 +0200)]
Restore behaviour after count<ALL_PIECES> fix

Because pos.count<ALL_PIECES>(Us) was always zero,
rewrite the formula as if this would still be
the case.

bench: 8510004

7 years agoFurther improve chain pawn evaluation
Ralph Stößer [Sun, 20 Oct 2013 21:41:02 +0000 (23:41 +0200)]
Further improve chain pawn evaluation

Passed both short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 28299 W: 5854 L: 5667 D: 16778

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 9738 W: 1797 L: 1644 D: 6297

bench: 9294116

7 years agoFix pos.count<ALL_PIECES>()
Marco Costalba [Sun, 20 Oct 2013 21:35:10 +0000 (23:35 +0200)]
Fix pos.count<ALL_PIECES>()

It was never updated !

Currently it only affects evaluate_passed_pawns()
and in particularly the rule to increase the bonus
if we have more non-pawn pieces. We could simply use
popcount() instead and avoid the little slowdown
in put_piece() and remove_piece(), but this would
leave a very subtle and tricky hole where people
are forced to remember that pos.count<ALL_PIECES>()
does not work. This is not obvious and so dangerous.

Thanks to Ronald de Man for spotting this.

bench: 7931424

7 years agoFix build on Intel compiler
Marco Costalba [Sat, 13 Jul 2013 21:07:24 +0000 (23:07 +0200)]
Fix build on Intel compiler

Due to a strange issue (bug?) the ternary
operator does not return a BitCountType for
icc, so revert to the expression.

The same patch was already applied in
9749f1f14c956133c2f42f96592b

Thanks to NssY Wanyonyi for pointing out
this.

No functional change.

7 years agoRevert "Further increase safe checks bonus"
Marco Costalba [Sun, 20 Oct 2013 07:55:12 +0000 (09:55 +0200)]
Revert "Further increase safe checks bonus"

This reverts commit 4bc2374450e30101392 for
two reasons.

First regression testing shows almost equal
score:

Before the patch:
ELO: 49.75 +-2.5 (95%) LOS: 100.0%
Total: 27205 W: 7113 L: 3244 D: 16848

After the patch:
ELO: 48.87 +-2.9 (95%) LOS: 100.0%
Total: 20860 W: 5478 L: 2563 D: 12819

Second, and more sensible to me, this patch
increases safe check bonuses to 4 times their
original value (!) and considering:

- Values were already well tuned

- Values are highly critical

- King safety is highly critical, very TC
  dependent and very difficult to test

- Our testing coverage is partial (self-testing,
  blitz times)

I think is better to be safe than sorry and so
I revert the patch.

bench: 8440524

7 years agoFurther increase safe checks bonus
Ralph Stößer [Tue, 15 Oct 2013 18:09:35 +0000 (20:09 +0200)]
Further increase safe checks bonus

Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 10466 W: 2087 L: 1953 D: 6426

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 26334 W: 4540 L: 4310 D: 17484

And also proved stronger than a slightly
different patch, also succesful against master:

https://github.com/mcostalba/Stockfish/commit/dc6830a3b4ed12

But losing against current one in a match
at 60secs with SPRT [-3, 3]:

LLR: -2.96 (-2.94,2.94) [-3.00,3.00]
Total: 44484 W: 7360 L: 7463 D: 29661

bench: 9160831

7 years agoSome evaluation code reshuffle
Marco Costalba [Fri, 18 Oct 2013 15:42:52 +0000 (08:42 -0700)]
Some evaluation code reshuffle

No functional change.

7 years agoScore chain pawn also by rank
Jörg Oster [Fri, 18 Oct 2013 08:23:28 +0000 (10:23 +0200)]
Score chain pawn also by rank

Use the (rescaled) CandidatePassed[] table
that is already rank based.

Passed both short TC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 11048 W: 2272 L: 2135 D: 6641

And long TC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 4116 W: 769 L: 645 D: 2702

bench: 8440524

7 years agoSimplification of KPsK function
Chris Caino [Mon, 14 Oct 2013 23:20:34 +0000 (00:20 +0100)]
Simplification of KPsK function

Also the drawing criteria has been slightly loosened.
It now detects a draw if the king is ahead of all the
pawns and on the same file or the adjacent file.

bench: 7700683

7 years agoBug fix for KQKRPs endgame
Chris Caino [Mon, 14 Oct 2013 23:09:05 +0000 (00:09 +0100)]
Bug fix for KQKRPs endgame

This lost position 8/8/3q4/8/5k2/2P1R3/2K2P2/8 w - - 0 1
was previously evaluated as a draw.

The king and rook need to be correctly placed with
respect to the _same_ pawn.

(Note also that the check for the pawn being on RANK_2
in the old version is redundant: it must be on RANK_2 if
it hopes to protect a rook on RANK_3)

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
7 years agoDouble king safety weights
Ralph Stößer [Sat, 12 Oct 2013 10:59:43 +0000 (12:59 +0200)]
Double king safety weights

Good both at short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 5448 W: 1133 L: 1012 D: 3303

And at long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 40509 W: 6836 L: 6541 D: 27132

bench: 7700683

7 years agoRemove a drawing rule from KBPsK function
Chris Caino [Mon, 14 Oct 2013 17:53:08 +0000 (19:53 +0200)]
Remove a drawing rule from KBPsK function

The rule can be incorrect if the attacking king is
well placed e.g. 8/6K1/8/8/7k/1B6/7P/8 w - - 0 1

bench: 8279065

7 years agoMassive stronger/weaker renming
Marco Costalba [Mon, 14 Oct 2013 17:34:12 +0000 (19:34 +0200)]
Massive stronger/weaker renming

No functional change.

7 years agoAdd helper function verify_material
Chris Caino [Mon, 14 Oct 2013 12:57:08 +0000 (13:57 +0100)]
Add helper function verify_material

Allows to remove a lot of assert code in endgames.

No functional change.

7 years agoAdd some knowledge for KRPKB endgame
ceebo [Sun, 13 Oct 2013 20:50:45 +0000 (21:50 +0100)]
Add some knowledge for KRPKB endgame

bench: 8279065

7 years agoImprove KBPsK endgame
ceebo [Sun, 13 Oct 2013 15:44:51 +0000 (16:44 +0100)]
Improve KBPsK endgame

Better endgame with bishop and blocked g-pawn

bench: 8279065

7 years agoRemove unuseful optimization in RKISS
Marco Costalba [Sun, 13 Oct 2013 09:20:35 +0000 (02:20 -0700)]
Remove unuseful optimization in RKISS

Don't need a struct here. Speed test shows
result is teh same. Moreover RKISS is used
mainly at startup to compute magics, so
prefer to keep it simple...RKISS ;-)

Also some assorted triviality while there.

No functional change.

7 years agoSmoother transition for LMR
Joona Kiiski [Tue, 8 Oct 2013 21:43:33 +0000 (22:43 +0100)]
Smoother transition for LMR

Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 12376 W: 2596 L: 2454 D: 7326

And long TC:
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 14798 W: 2584 L: 2409 D: 9805

bench: 8279065

7 years agoIncrease slowmover and reduce instability
Uri Blass [Sat, 5 Oct 2013 19:20:20 +0000 (22:20 +0300)]
Increase slowmover and reduce instability

These two changes go in opposite directions and it
seems that the combination is stronger than original.

Here are the positive tests at various TC:

15+0.05
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 24561 W: 4946 L: 4772 D: 14843

60+0.05
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 15259 W: 2598 L: 2423 D: 10238

40/30
LLR: 2.96 (-2.94,2.94) [-3.00,3.00]
Total: 2570 W: 527 L: 422 D: 1621

Unfortunately there is also a bad result
with one sec time increment that needs
to be further investigated:

12+1
LLR: -2.97 (-2.94,2.94) [-3.00,3.00]
Total: 2694 W: 438 L: 543 D: 1713

bench: 8340585

7 years agoUse TT refined value to stand pat
Lucas Braesch [Mon, 7 Oct 2013 07:10:48 +0000 (09:10 +0200)]
Use TT refined value to stand pat

Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 17811 W: 3520 L: 3366 D: 10925

And long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 30255 W: 5070 L: 4825 D: 20360

bench: 8340585

7 years agoUse double everywhere
Lucas Braesch [Thu, 3 Oct 2013 04:05:58 +0000 (12:05 +0800)]
Use double everywhere

Rationale:

- Speed of double and float is about the same (not on the hot path anyway)

- Double makes code prettier (no need to write 1.0f, just 1.0)

- Only practical advantage of float is to use less memory, but since we never
  store large arrays of double, we don't care.

No functional change.

7 years agoUse prefix operators wherever possible
Lucas Braesch [Thu, 3 Oct 2013 04:01:38 +0000 (12:01 +0800)]
Use prefix operators wherever possible

No functional change.

7 years agoAdd more depth/positions to bench
Marco Costalba [Sun, 29 Sep 2013 07:43:10 +0000 (09:43 +0200)]
Add more depth/positions to bench

Increase bench default depth from 12 to 13 and
add 15 new endgame positions to have broader
coverage and also more reliable nps calulcation
used for fishtest framework.

Due to the new endgame positions, where nps is higher,
the total nps is increased of about 15%.

Thanks to Lucas and Jörg for the suggestions.

No functional change, but bench number is now:

bench: 8336338

7 years agoDrop 'is' prefix from query functions
Marco Costalba [Sat, 28 Sep 2013 12:43:50 +0000 (05:43 -0700)]
Drop 'is' prefix from query functions

Most but not all.

No functional change.

7 years agoFix build on Mac OS X
Marco Costalba [Sat, 28 Sep 2013 11:14:59 +0000 (04:14 -0700)]
Fix build on Mac OS X

For some users -stack_size,0x4000 does not work,
so revert for now.

osX 10.6.8
gcc version 4.7.3 (MacPorts gcc47 4.7.3_2)

g++: error: unrecognized command line option '-stack_size,0x4000'
make[2]: *** [stockfish] Error 1
make[1]: *** [gcc-profile-make] Error 2
make: *** [profile-build] Error 2

No functional change.

7 years agoRevert "Use a per-thread array"
Marco Costalba [Sat, 28 Sep 2013 07:59:45 +0000 (09:59 +0200)]
Revert "Use a per-thread array"

This reverts commit 800410eef1c0811 and instead increases
stack size.

I went through the old emails with Daylen that reported the
crash issue on Mac OS X and was fixed by 0049d3f337b6f3a66a0.

It was reported default stack size for a thread in Mac OS X is 8
megabytes while the patch that we are reverting allows to reduce
stack size at max of about 217KB, so the reason for the crash was
only marginal in MAX_MOVES value. On those emails Daylen also
hinted how to increase stack size for Mac OS X to 16MB.

So prefer to increase stack size to 16MB instad of re-inventing
the wheel and do our home grown stack as we did with the patch
that we are now reverting (it will remain anyhow in git history
for documentation purposes).

No functional change.

7 years agoSimplify extensions
Lucas Braesch [Thu, 26 Sep 2013 10:25:27 +0000 (18:25 +0800)]
Simplify extensions

Unify extensions between PV and not PV nodes
and remove all but check extensions.

This is a simplification so tested at fixed number
of games where proved to not regress.

About 45k games at 15+0.05
ELO: 1.23 +-2.0 (95%) LOS: 88.5%
Total: 45643 W: 9107 L: 8946 D: 27590

About 45k games at 60+0.05
ELO: 1.07 +-1.8 (95%) LOS: 87.8%
Total: 46786 W: 7728 L: 7584 D: 31474

bench: 3172206

7 years agoSimplify tte use condition
Reuven Peleg [Wed, 25 Sep 2013 11:04:38 +0000 (14:04 +0300)]
Simplify tte use condition

No functional change.

7 years agoFix best move lookup bug
Raminder Singh [Wed, 25 Sep 2013 13:17:59 +0000 (18:47 +0530)]
Fix best move lookup bug

If the uci option 'Best Book Move' is set to true the lookup still
returns a move at random instead of the move with the highest
weight.

No functional change.