]> git.sesse.net Git - stockfish/log
stockfish
10 years agoRescale UCI scores to PawnValueEg
Lucas Braesch [Sun, 6 Apr 2014 09:43:30 +0000 (11:43 +0200)]
Rescale UCI scores to PawnValueEg

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

No functional change.

10 years agoSync some common names
Marco Costalba [Sun, 6 Apr 2014 08:50:27 +0000 (10:50 +0200)]
Sync some common names

No functional change.

10 years agoSome more work in pretty_pv
Marco Costalba [Sat, 5 Apr 2014 23:11:30 +0000 (01:11 +0200)]
Some more work in pretty_pv

No functional change.

10 years agoSmall tidy up in move_to_san
Marco Costalba [Sat, 5 Apr 2014 16:54:37 +0000 (18:54 +0200)]
Small tidy up in move_to_san

No functional change.

10 years agoSmaller and faster profile-build binaries
mstembera [Sat, 5 Apr 2014 10:46:17 +0000 (12:46 +0200)]
Smaller and faster profile-build binaries

I have noticed that increasing the bench depth produces
progressively smaller and slightly faster executables at
the cost of longer compile times.  Also using bench "time"
instead of "depth" seems to produce slightly smaller/faster
executables  given comparable compile times.

I have made a new Makefile that generates smaller and
about 1% to 2% faster profile executables at only a
little extra compile time.  On  my mobile 2GHz i7 a
full profile build time goes from 3'48" to 4'13" and
the exe goes down by 5% from 416,310 bytes to 395,567
bytes.

No functional change.

10 years agoRemove QueenOn7th and QueenOnPawn
Lucas Braesch [Thu, 3 Apr 2014 13:31:42 +0000 (21:31 +0800)]
Remove QueenOn7th and QueenOnPawn

Small simplification.

Passed SPRT(-3,1) both at STC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 17051 W: 3132 L: 3005 D: 10914

and LTC:
LLR: 4.55 (-2.94,2.94) [-3.00,1.00]
Total: 24890 W: 3842 L: 3646 D: 17402

The rationale behind this is that I've never managed to add a
Queen on 7th rank bonus in DiscoCheck, because it never showed
to be positive (evne slightly) in testing. The only thing that
worked is Rook on 7th rank.

In terms of SF code, it seemed natural to group it with QueenOnPawn
as well as those are done together. I know you're against groupping
in general, but when it comes to non regression test, you are being
more conservative by groupping. If the group passes SPRT(-3,1) it's
safer to commit, than test every component in SPRT(-3,1) and end up
with the risk of commiting several -1 elo regression instead of just
one -1 elo regression.

In chess terms, perhaps it's just easier to manouver a Queen (which
can more also diagonaly) than a Rook. Therefore you can let the search
do its job without needing eval ad-hoc terms to guide it. For the Rook
which takes more moves to manouver such eval terms can be (marginally)
useful.

bench: 7473314

10 years agoSpeed up apply_weight
mstembera [Fri, 4 Apr 2014 03:08:54 +0000 (20:08 -0700)]
Speed up apply_weight

Speed up by about 2% this hot path function pre-calculating
midgame and endgame values of the weight.

No functional change.

10 years agoUpdate Readme to 128 max threads
Marco Costalba [Thu, 3 Apr 2014 09:33:42 +0000 (11:33 +0200)]
Update Readme to 128 max threads

No functional change.

10 years agoQueen vs. 3 pieces imbalance
Joerg Oster [Thu, 3 Apr 2014 08:38:11 +0000 (10:38 +0200)]
Queen vs. 3 pieces imbalance

Passed both STC
LLR: 7.32 (-2.94,2.94) [-1.50,4.50]
Total: 98108 W: 18087 L: 17576 D: 62445

And LTC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 15082 W: 2417 L: 2248 D: 10417

bench: 7717336

10 years agoMake operator<< to return void
Marco Costalba [Thu, 3 Apr 2014 08:34:25 +0000 (10:34 +0200)]
Make operator<< to return void

This should help preventing misuse.

No functional change.

10 years agoDrop not defended by pawn condition
Stefan Geschwentner [Tue, 1 Apr 2014 09:58:10 +0000 (11:58 +0200)]
Drop not defended by pawn condition

Passed no-regression test both at STC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 96554 W: 17563 L: 17572 D: 61419

and at LTC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 31891 W: 4905 L: 4801 D: 22185

bench: 7720896

10 years agoDo not workaround function argument evaluation
Marco Costalba [Tue, 1 Apr 2014 07:39:41 +0000 (09:39 +0200)]
Do not workaround function argument evaluation

Rewrite options initialization to do not trying to
hack upon the undefined evaluation order of function
arguments.

No functional change.

10 years agoFix a compile error with Intel C++
Marco Costalba [Sun, 30 Mar 2014 12:20:12 +0000 (14:20 +0200)]
Fix a compile error with Intel C++

Error: a value of type "int" cannot be assigned
to an entity of type "Value"

No functional change.

10 years agoFix a warning with MSVC 2010
Marco Costalba [Sun, 30 Mar 2014 12:25:57 +0000 (14:25 +0200)]
Fix a warning with MSVC 2010

Warning C4804: '<' : unsafe use of type 'bool' in operation

No functional change.

10 years agoShow evaluation from white POV in trace
Marco Costalba [Sun, 30 Mar 2014 08:11:32 +0000 (10:11 +0200)]
Show evaluation from white POV in trace

We chose this instead of negamax sign convention
(ie. from the point of view of the side to move)
because it is more in line to how the eval
table is presented.

Also some tweak to formatting while there.

No functional change.

10 years agoRaise VALUE_INFINITE
Marco Costalba [Sat, 29 Mar 2014 10:12:37 +0000 (11:12 +0100)]
Raise VALUE_INFINITE

In some legal positions like this one:
R6R/3Q4/1Q4Q1/4Q3/2Q4Q/Q4Q2/Np1Q4/kB1N1KB1  b -- 0 1

We can have a very high score, in this case 30177 and 29267
for midgame and endgame respectively, and because
VALUE_INFINITE = 30001 we have an assert in interpolate()

Midgame and endgame scores are stored in 16 bit signed integers
so we can rise VALUE_INFINITE a little bit. This does not fix
the possibility of overflow in general case, just makes the
condition more difficult to trigger and anyhow better uses all
the score width.

Raising VALUE_INFINITE to 32000 seems to fix the problem for this
particular case.

No functional change.

10 years agoFurther simplification of TT replace strategy
Jean-Francois Romang [Thu, 27 Mar 2014 17:38:19 +0000 (18:38 +0100)]
Further simplification of TT replace strategy

No functional change

10 years agoRestore old aspiration window to 16
Marco Costalba [Wed, 26 Mar 2014 05:39:46 +0000 (06:39 +0100)]
Restore old aspiration window to 16

Tested directly at LTC because previous long
test series on this topic shows it is TC dependant.

Tested with no-regression mode because gets rid of
an ugly and ad-hoc rule.

Test at LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 67918 W: 10590 L: 10541 D: 46787

bench: 7926803

10 years agoPinned pieces affect king safety
Stefan Geschwentner [Fri, 28 Mar 2014 07:41:50 +0000 (08:41 +0100)]
Pinned pieces affect king safety

Here the new idea is to link pinned pieces
with king safety.

Passed both STC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 10047 W: 1867 L: 1737 D: 6443

And LTC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 10419 W: 1692 L: 1543 D: 7184

bench: 8325087

10 years agoFix a bug in pawns eval tracing
Marco Costalba [Wed, 26 Mar 2014 06:06:29 +0000 (07:06 +0100)]
Fix a bug in pawns eval tracing

Instead of totals we were showing white and
black values.

Spotted by Sven Schüle

No functional change.

10 years agoSimplify TT replace strategy
Marco Costalba [Sun, 23 Mar 2014 09:03:11 +0000 (10:03 +0100)]
Simplify TT replace strategy

Tested for no-regression with SPRT[-3, 1] at STC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 32046 W: 6020 L: 5918 D: 20108

No functional change.

10 years agoIntroduce penalty for weak (=unsupported) pawns.
snicolet [Sun, 23 Mar 2014 22:51:25 +0000 (23:51 +0100)]
Introduce penalty for weak (=unsupported) pawns.

We add a penalty for each pawn which is not protected by another pawn
of the same color.

Passed both short TC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 12107 W: 2411 L: 2272 D: 7424

And long TC
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 9204 W: 1605 L: 1458 D: 6141

bench: 7682173

10 years agoFix an incorrect 'friend' declaration
Marco Costalba [Sun, 23 Mar 2014 10:17:38 +0000 (11:17 +0100)]
Fix an incorrect 'friend' declaration

Spotted by Lee David.

No functional change.

10 years agoRetire last usage of operator|(File f, Rank r)
Marco Costalba [Sun, 23 Mar 2014 09:42:37 +0000 (10:42 +0100)]
Retire last usage of operator|(File f, Rank r)

This for some reason was missed.

No functional change.

10 years agoRefresh TT entries generation automatically on probe
mstembera [Sun, 23 Mar 2014 08:24:35 +0000 (09:24 +0100)]
Refresh TT entries generation automatically on probe

And other assorted simplifications, tested with SPRT[-3, 1]

Passed both short TC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 18814 W: 3600 L: 3475 D: 11739

And long TC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 20731 W: 3217 L: 3096 D: 14418

No functional change.

10 years agoRename score to value in ExtMove
Marco Costalba [Sun, 23 Mar 2014 07:52:42 +0000 (08:52 +0100)]
Rename score to value in ExtMove

We use 'score' for the value mid-endgame pair.

No functional change.

10 years agoTrivial formatting in ucioption.cpp
Marco Costalba [Sat, 22 Mar 2014 23:06:26 +0000 (00:06 +0100)]
Trivial formatting in ucioption.cpp

No functional change.

10 years agoRetire operator|(File f, Rank r)
Marco Costalba [Sat, 22 Mar 2014 22:35:30 +0000 (23:35 +0100)]
Retire operator|(File f, Rank r)

Use make_square() instead. Less fancy but
more clear.

No functional change.

10 years agoFix a subtle bug in UCI options printing
Marco Costalba [Sat, 22 Mar 2014 10:15:28 +0000 (11:15 +0100)]
Fix a subtle bug in UCI options printing

We want all the UCI options are printed in the order in which are
assigned, so we use an index that, depending on Options.size(),
increases after each option is added to the map. The problem is
that, for instance, in the first assignment:

o["Write Debug Log"] = Option(false, on_logger);

Options.size() can value 0 or 1 according if the l-value (that
increments the size) has been evaluated after or before the
r-value (that uses the size value).

The culprit is that assignment operator in C++ is not a
sequence point:

http://en.wikipedia.org/wiki/Sequence_point

(Note: to be nitpick here we actually use std::map::operator=()
 that being a function can evaluate its arguments in any order)

So there is no guarantee on what term is evaluated first and
behavior is undefined by standard in this case. The net result
is that in case r-value is evaluated after l-value the last
idx is not size() - 1, but size() and in the printing loop
we miss the last option!

Bug was there since ages but only recently has been exposed by
the removal of UCI_Analyze option so that the last one becomes
UCI_Chess960 and when it is missing engine cannot play anymore
Chess960.

The fix is trivial (although a bit hacky): just increase the
last loop index.

Reported by Eric Mullins that found it on an ARM and MIPS
platforms with gcc 4.7

No functional change.

10 years agoFix a typo
Marco Costalba [Tue, 18 Mar 2014 17:35:03 +0000 (18:35 +0100)]
Fix a typo

Spotted by Isaac Haïk Dunn.

No functional change.

10 years agoIncrease max threads to 128
Marco Costalba [Tue, 18 Mar 2014 11:07:26 +0000 (12:07 +0100)]
Increase max threads to 128

Thanks to std::bitset we can easily increase
the limit of active threads above 64.

Thanks to Lucas Braesch for pointing at the
correct solution of using std::bitset.

No functional change.

10 years agoFix a crash under MSVC
Marco Costalba [Sun, 16 Mar 2014 09:55:58 +0000 (10:55 +0100)]
Fix a crash under MSVC

Using memset on a std::vector is undefined behavior,
so manually init all the data memebers of LimitsType.

Bug intorduced in 41641e3b1eea0038ab6984

No functional change.

10 years agoSplit also if no slaves are found
Marco Costalba [Sat, 15 Mar 2014 22:43:35 +0000 (23:43 +0100)]
Split also if no slaves are found

Because we test for available slaves before
entering split(), we almost always allocate a
slave, only in the rare case of a race (less
then 2% of cases) this is not true, but to
special case this occurrence is not worth
the added complexity.

bench: 7451319

10 years agoRemove "Max Threads per Split Point" UCI option
Marco Costalba [Sat, 15 Mar 2014 20:13:43 +0000 (21:13 +0100)]
Remove "Max Threads per Split Point" UCI option

Experimental patch to verify if drop of nps
in endgames at very long TC is due to this.

Suggested by Ronald de Man.

bench: 7451319

10 years agoMerge default tests in pos_is_ok
Marco Costalba [Sat, 15 Mar 2014 14:26:29 +0000 (15:26 +0100)]
Merge default tests in pos_is_ok

No functional change.

10 years agoMicroptimize castling in undo_move()
Marco Costalba [Sat, 15 Mar 2014 10:21:47 +0000 (11:21 +0100)]
Microptimize castling in undo_move()

We don't need to set 'captured' and 'pt' after we
castle back.

No functional change.

10 years agoDepth dependant aspiration window delta
Mysseno [Fri, 14 Mar 2014 10:00:50 +0000 (21:00 +1100)]
Depth dependant aspiration window delta

Split delta value in aspiration window so that when
search depth is less than 24 a smaller delta value
is used. The idea is that the search is likely to
be more accurate at lower depths and so we can exclude
more possibilities, 25% to be exact.

Passed STC
LLR: 2.96 (-2.94, 2.94) [-1.50, 4.50]
Total: 20430 W: 3775 L: 3618 D: 13037

And LTC
LLR: 2.96 (-2.94, 2.94) [0.00, 6.00]
Total: 5032 W: 839 L: 715 D: 3478

Bench: 7451319

10 years agoUse legal positions for endgame initialization
Marco Costalba [Fri, 14 Mar 2014 08:57:34 +0000 (09:57 +0100)]
Use legal positions for endgame initialization

During endgame initialization we get the material
hash key of each endgame forging and ad-hoc position
that in same cases is illegal (leaves teh king under
capture). This is not a problem for the material key,
but rises an assert when SF is run in debug mode with
'testKingCapture' set in pos_is_ok().

So rewrite the code to always produce legal positions.

No functional change.

10 years agoFurther work in pos_is_ok()
Marco Costalba [Fri, 14 Mar 2014 08:43:19 +0000 (09:43 +0100)]
Further work in pos_is_ok()

No functional change.

10 years agoRe-add link time optimization on OS X
Daylen Yang [Fri, 14 Mar 2014 05:09:29 +0000 (22:09 -0700)]
Re-add link time optimization on OS X

In the new version of clang, -O4 does not imply -flto, so we set the
flag

10 years agoReformat do_castling()
Marco Costalba [Thu, 13 Mar 2014 11:53:03 +0000 (12:53 +0100)]
Reformat do_castling()

No functional change.

10 years agoFurther merge StateInfo setup functions
Marco Costalba [Wed, 12 Mar 2014 21:46:17 +0000 (22:46 +0100)]
Further merge StateInfo setup functions

No functional change.

10 years agoMerge hash key computation functions
Marco Costalba [Wed, 12 Mar 2014 08:14:38 +0000 (09:14 +0100)]
Merge hash key computation functions

No functional change.

10 years agoUse std::count in pos_is_ok()
Marco Costalba [Tue, 11 Mar 2014 22:19:47 +0000 (23:19 +0100)]
Use std::count in pos_is_ok()

No functional change.

10 years agoSmall simplification in gives_check
Marco Costalba [Tue, 11 Mar 2014 21:58:08 +0000 (22:58 +0100)]
Small simplification in gives_check

Use switch statement also for normal case.

No speed regression.

No functional change.

10 years agoPrint dbg counters after bench
Marco Costalba [Tue, 11 Mar 2014 21:19:14 +0000 (22:19 +0100)]
Print dbg counters after bench

Print last debug counters update just
before to exit benchmark.

Suggested by Stephane Nicolet.

No functional change.

10 years agoSimplify pseudo_legal()
Marco Costalba [Mon, 10 Mar 2014 07:38:23 +0000 (08:38 +0100)]
Simplify pseudo_legal()

Big simplification of pawn move check.

Code has been tested with a brute force approach: for
every position reached during a bench search, the function
has been called for each combinations of Move(from, to)
and verified the result is the same of old code.

Actually this function is very critical becuase is the
one that ensures corrupted TT moves are discarded, so
to properly test it a simple bench is not enough.

Verified also speed is not changed.

No functional chnage.

10 years agoSimplify generate<EVASIONS>
Marco Costalba [Sun, 9 Mar 2014 10:48:41 +0000 (11:48 +0100)]
Simplify generate<EVASIONS>

No speed regression, tested with both perft and
bench.

No functional change.

10 years agoRetire SERIALIZE macros
Marco Costalba [Sun, 9 Mar 2014 10:03:02 +0000 (11:03 +0100)]
Retire SERIALIZE macros

Explicitly write the 'while' loops. This adds some
code but makes clear what's the code behind the
macro.

No functional change.

10 years agoRename castling flag to castling right
Marco Costalba [Sat, 8 Mar 2014 14:08:55 +0000 (15:08 +0100)]
Rename castling flag to castling right

This is a more conventional naming as
reported also in:

http://chessprogramming.wikispaces.com/Castling+rights

No functional change.

10 years agoFix dbg_mean_of() for negative numbers
Stephane Nicolet [Wed, 5 Mar 2014 07:51:02 +0000 (08:51 +0100)]
Fix dbg_mean_of() for negative numbers

Type should be int64_t instead of uint64_t

No functional change.

10 years agoSome minor cleanup stuff
mstembera [Mon, 3 Mar 2014 07:07:57 +0000 (23:07 -0800)]
Some minor cleanup stuff

I came across while browsing the code.

No functional change.

10 years agoRevert dynamic draw value
Marco Costalba [Mon, 3 Mar 2014 07:39:34 +0000 (08:39 +0100)]
Revert dynamic draw value

When tested with weaker engines did not
performed as expected, actually it was even
a regression from standard version.

bench: 8430785

10 years agoPass CastlingFlag argument only
Marco Costalba [Sun, 2 Mar 2014 10:53:17 +0000 (11:53 +0100)]
Pass CastlingFlag argument only

Instead of Color and CastlingSide. Change functions API
accordingly.

No functional change.

10 years agoRemove limit of minimumSplitDepth
Marco Costalba [Sat, 1 Mar 2014 22:22:14 +0000 (23:22 +0100)]
Remove limit of minimumSplitDepth

There is no reason why an user cannot set
it at a value less than 4.

No functional change.

10 years agoRename xxx_to_char() -> to_char()
Marco Costalba [Sat, 1 Mar 2014 21:07:41 +0000 (22:07 +0100)]
Rename xxx_to_char() -> to_char()

No functional change.

10 years agoSimplify Bitboards::pretty
Marco Costalba [Sat, 1 Mar 2014 12:05:55 +0000 (13:05 +0100)]
Simplify Bitboards::pretty

No functional change.

10 years agoRetire UCI_AnalyseMode option
Marco Costalba [Sat, 1 Mar 2014 11:10:42 +0000 (12:10 +0100)]
Retire UCI_AnalyseMode option

It has been obsoleted out already some time ago
and currently there is no point in changing eval
score according to if we are in game or analyzing.

So retire the option.

No functional change.

10 years agoDynamic draw value
Joerg Oster [Wed, 26 Feb 2014 18:32:19 +0000 (19:32 +0100)]
Dynamic draw value

Try to avoid repetition draws at early midgame,
this should give an edge against weaker opponents
and reduce draw rate.

Tested for regressions with SPRT[-3, 1] and
passed both short TC
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 68498 W: 12928 L: 12891 D: 42679

And long TC
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 40212 W: 6386 L: 6295 D: 27531

bench: 7990513

10 years agoFix a warning with Intel compiler
Marco Costalba [Sat, 22 Feb 2014 11:00:14 +0000 (12:00 +0100)]
Fix a warning with Intel compiler

warning #2259: non-pointer conversion from "int" to
"uint8_t={unsigned char}" may lose significant bits

No functional change

10 years agoFix an assert in Probcut
Marco Costalba [Sat, 22 Feb 2014 09:34:48 +0000 (10:34 +0100)]
Fix an assert in Probcut

When running the following position:

8/kPp5/2P3p1/p1P1p1P1/2PpPp2/3p1p2/3P1P2/5K2 w - - 0 1

An assert is raised at depth 92:

assert(-VALUE_INFINITE <= alpha && alpha < beta && beta <= VALUE_INFINITE);

This is because it happens that beta = 29832,
so rbeta = 30032 that is > VALUE_INFINITE

Bug spotted and analyzed by Uri, fix suggested by Joerg.

Other fixes where possible but this one is pointed
exactly at the source of the bug, so it is the best
from a code documentation point of view.

bench: 8430785

10 years agoDistribute part of first move time to other moves
Leonid Pechenik [Thu, 20 Feb 2014 07:38:10 +0000 (08:38 +0100)]
Distribute part of first move time to other moves

Passed both short TC:
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 18907 W: 3475 L: 3322 D: 12110

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 19044 W: 2997 L: 2811 D: 13236

bench: 8430785

10 years agoAvoid recalculating CheckInfo in generate_castling()
Marco Costalba [Thu, 20 Feb 2014 07:27:13 +0000 (08:27 +0100)]
Avoid recalculating CheckInfo in generate_castling()

No functional change.

10 years agoDon't update pieceCount for ALL_PIECES
Marco Costalba [Tue, 18 Feb 2014 07:30:13 +0000 (08:30 +0100)]
Don't update pieceCount for ALL_PIECES

It is currently unused and only adds
overhead for nothing.

Also set proper type of chess960.

No functional change.

10 years agoUpdate SEE to return a Value
Marco Costalba [Sun, 16 Feb 2014 12:06:31 +0000 (13:06 +0100)]
Update SEE to return a Value

It seems more natural because the actual returned
value is from PieceValue[] array.

No functional change.

10 years agoSync code style in material.cpp
Marco Costalba [Sun, 16 Feb 2014 11:55:15 +0000 (12:55 +0100)]
Sync code style in material.cpp

Update to use common code style.

No functional change.

10 years agoIncrease MAX_PLY from 100 to 120
Marco Costalba [Sun, 16 Feb 2014 11:20:37 +0000 (12:20 +0100)]
Increase MAX_PLY from 100 to 120

Under some very rare case 100 plies of search
could be not enough. Increasing more could lead
to crashes due to reached stack size limit on
some platforms.

Strongly requested by Uri.

bench: 8430785

10 years agoFix material key for King
Marco Costalba [Sun, 16 Feb 2014 10:37:29 +0000 (11:37 +0100)]
Fix material key for King

Currently king has no material key associated because
it can never happen to find a legal position without
both kings, so there is no need to keep track of it.

The consequence is that a position with only the two
kings has material key set at zero and if the material
hash table is empty any entry will match and this is
wrong.

Normally bug is hidden becuase the checking for a draw
with pos.is_draw() is done earlier than evaluate() call,
so that we never check in gameplay the material key of a
position with two kings.

Nevertheless the bug is there and can be reproduced setting
at startup a position with only two kings and typing
'eval' from prompt.

The fix is very simple: add a random key also for the king.

Also fixed the condition in material.cpp to avoid asserting
when a 'just 2 kings' postion is evaluated.

No functional change.

10 years agoRestore PorbCut name
Marco Costalba [Sat, 15 Feb 2014 21:17:58 +0000 (22:17 +0100)]
Restore PorbCut name

Actually MultiCut is too different from current scheme.
Note that neither ProbCut is exactly what we do because
we try just a handful of captures instead of all moves,
nevertheless it seems more in line with what we do.

Suggested by Joona.

No functional change.

10 years agoReformat of eval tracing code
Marco Costalba [Sat, 15 Feb 2014 12:27:16 +0000 (13:27 +0100)]
Reformat of eval tracing code

Also assorted rename while there.

No functional change.

10 years agoRename ProbCut to Multicut
Marco Costalba [Sat, 15 Feb 2014 08:37:55 +0000 (09:37 +0100)]
Rename ProbCut to Multicut

The teqnique used is actually MultiCut:

https://chessprogramming.wikispaces.com/Multi-Cut

And not ProbCut:

https://chessprogramming.wikispaces.com/ProbCut

No functional change.

10 years agoAssorted renaming in search
Marco Costalba [Sat, 15 Feb 2014 08:20:27 +0000 (09:20 +0100)]
Assorted renaming in search

Inspired by DON.

No functional change.

10 years agoReturn static eval when reaching MAX_PLY
Joerg Oster [Thu, 13 Feb 2014 22:44:12 +0000 (23:44 +0100)]
Return static eval when reaching MAX_PLY

Makes more sense than returning a draw score. Tested
with reduced MAX_PLY = 30 and passed both short TC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 17434 W: 3345 L: 3194 D: 10895

And long TC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 2610 W: 488 L: 373 D: 1749

With current limit of MAX_PLY = 100 the patch should not
introduce any measurable change, nevertheless is the correct
approach.

Idea of returning eval is from  Michel Van den Bergh.

bench: 8430785

10 years agoFix magic boosters conversion
Marco Costalba [Fri, 14 Feb 2014 09:43:37 +0000 (10:43 +0100)]
Fix magic boosters conversion

Fix small overflow error while converting
magic boosters from right rotate to left rotate,
in particular booster 38 was converted to 4122
instead of the corrcet value 26.

Formula used was:

s1 = original & 63, s2 = (original >> 6) & 63;
new = (64 - s1) | ((64 - s2) << 6);

Instead of:

s1 = original & 63, s2 = (original >> 6) & 63;
new = ((64 - s1) & 63) | (((64 - s2) & 63) << 6);

This has no impact in number of cycles needed, but
just in the resultig number that yields to a rotate
amount bigger than 63.

Spotted by Ehsan Rashid.

No functional change.

10 years agoAdditional renaming from DON
Marco Costalba [Fri, 14 Feb 2014 08:42:50 +0000 (09:42 +0100)]
Additional renaming from DON

Assorted renaming and triviality.

No functional change.

10 years agoFix a compiler warning
joergoster [Mon, 10 Feb 2014 21:03:30 +0000 (22:03 +0100)]
Fix a compiler warning

Latest master triggers a compiler warning due
to comparing int64_t to uint64_t.

notation.cpp: In Funktion »std::string pretty_pv(Position&, int, Value, int64_t, Move*)«:
notation.cpp:230:30: Warnung: Vergleich zwischen vorzeichenbehafteten und vorzeichenlosen Ganzzahlausdrücken [-Wsign-compare]

This patch should fix it.

No functional change.

10 years agoSimplify time management
Leonid Pechenik [Tue, 11 Feb 2014 09:01:06 +0000 (04:01 -0500)]
Simplify time management

Tested with simplification mode SPRT[-4, 0]

Passed both short TC
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 34102 W: 6184 L: 6144 D: 21774

And long TC
LLR: 2.96 (-2.94,2.94) [-4.00,0.00]
Total: 16518 W: 2647 L: 2545 D: 11326

And also 40/10 TC
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 22406 W: 4390 L: 4312 D: 13704

bench: 8430785

10 years agoMove magic random to RKISS
Marco Costalba [Wed, 12 Feb 2014 13:47:36 +0000 (14:47 +0100)]
Move magic random to RKISS

When initializing the magic numbers used to
compute sliding attacks, we endless generate a
random and test it as a possible magic.

In the general case this takes a lot of iterations,
but here, insteaad of picking a casual random, we
rotate it a couple of times and generate a number that
we know has a good probability to be a magic candidate.

This is becuase the quantities by which we rotate the
number are known in advance to produce quickly a good
canidate.

The patch, inspired by DON, just moves the shuffle to RKISS
changing the boosters to take in account a left rotation
instead of a right rotation as in the original.

No functional change.

10 years agoRevert "Retire null search verification"
Marco Costalba [Wed, 12 Feb 2014 13:16:21 +0000 (14:16 +0100)]
Revert "Retire null search verification"

Although does not change ELO level, it seems
verification is useful in many zugzwang positions
as reported by many sources.

So revert this simplification.

bench: 8430785

10 years agoFaster handling of king captures in Position::see
Henri Wiechers [Sat, 8 Feb 2014 05:46:46 +0000 (07:46 +0200)]
Faster handling of king captures in Position::see

Another SEE speed up that passed the SPRT short TC test!

LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 81337 W: 15060 L: 14745 D: 51532

No functional change.

10 years agoAssorted tweaks from DON
Marco Costalba [Sun, 9 Feb 2014 16:31:45 +0000 (17:31 +0100)]
Assorted tweaks from DON

Mainly renames and some little code style improvment,
inspired by looking at DON sources:

https://github.com/erashid/DON

No functional change.

10 years agoRewrite previous patch removing the macro
Marco Costalba [Sat, 8 Feb 2014 12:21:50 +0000 (13:21 +0100)]
Rewrite previous patch removing the macro

No functional change.

10 years agoInline common path of pos.gives_check
Thanar2 [Mon, 3 Feb 2014 22:09:28 +0000 (17:09 -0500)]
Inline common path of pos.gives_check

Test for common case which, when running default
stockfish bench, avoids 96% of 19 million calls to
pos.gives_check().

Yields to a 2-4% speed up according to platform.

Passed fishtest at STC
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 12441 W: 2333 L: 2196 D: 7912
http://tests.stockfishchess.org/tests/view/52f02d790ebc5901df50f887

Passed fishtest at LTC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 42175 W: 6702 L: 6409 D: 29064
http://tests.stockfishchess.org/tests/view/52f0dbe00ebc5901df50f8a0

No functional change.

10 years agoDon't fear races when are harmless
Marco Costalba [Sat, 8 Feb 2014 12:07:57 +0000 (13:07 +0100)]
Don't fear races when are harmless

Actually race conditions do exist in an engine, just
think for a moment to TT concurrent access. Racy code
is not a problem per se, if the consequences are well
known and correctly handled.

In case of TT access we ensure that the TT move is validated
before to be tried, here we just retry the same move in less
that 1 case out of a million: this is totally harmless considering
that very probably the second time the move is tried we get
immediately a TT hit and search quickly returns.

So we simplify the code for no harm.

No fuctional change (in single thread case)

10 years agoRetire null search verification
Lucas Braesch [Sat, 8 Feb 2014 07:11:13 +0000 (08:11 +0100)]
Retire null search verification

Tested with SPRT in simplification mode [-4.00,0.00],
this ensures that the patch is (very probably) not
a regression.

Passed both short TC
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 27543 W: 4278 L: 4209 D: 19056

And long TC
LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 39483 W: 7325 L: 7305 D: 24853

bench: 8347121

10 years agoBetter document null search window
Lucas Braesch [Tue, 4 Feb 2014 07:18:19 +0000 (08:18 +0100)]
Better document null search window

Hopefully this patch makes the code more:

* Self-documenting: Null search is always a zero window search,
  because it is testing for a fail high. It should never be done
  on a full window! The current code only works because we don't
  do it at PV nodes, and therefore (alpha, beta) = (beta-1, beta):
  that's the kind of "clever" trick we should avoid.

* Idiot-proof: If we want to enable null search at PV nodes, all we
  need to do now is comment out the !PvNode condition. It's that simple!

In theory, null search should not be done at PV nodes, because PV nodes
should never fail high. But in practice, they DO fail high, because of
aspiration windows, and search inconsistencies, for example. So it makes
sense to keep that flexibility in the code.

No functional change.

10 years agoBetter document razoring
Lucas Braesch [Mon, 3 Feb 2014 01:41:32 +0000 (09:41 +0800)]
Better document razoring

Use ralpha instead of rbeta

* rbeta is confusing people. It took THREE attempts to code razoring
at PV nodes correctly in a recent test, because of the rbeta trick.
Unnecessary tricks should be avoided.

* The more correct and self-documenting way of doing this, is to say
that we use a zero window around alpha-margin, not beta-margin.
The fact that, because we only do it at PV nodes, alpha happens to be
beta-1 and that the current stuff with rbeta works, may be correct,
but is confusing.

Remove the misleading and partially erroneous comment about returning
v + margin:

* comments should explain what the code does, not what it could have done.

* this comment is partially wrong in saying that v+margin is "logical",
  and that it is "surprising" that is doesn't work.

From a theoretical perspective, at least 3 ways of doing this are equally
defendable:

1/ fail hard: return alpha: The most conservative. We bet that the search
will fail low, but we don't know by how much and don't want to take risks.

2/ aggressive fail soft: return v (what the current code does). This
corresponds to normal fail soft, with the added assumption that we don't
care about the reduction effect (see below point 3/)

3/ conservative fail soft: return v + margin. If the reduced search (qsearch)
gives us a score <= v, we bet that the non reduced search will give us a
score <= v + margin.

* Saying that 2/ is "logical" implies that 1/ and 3/ are not, which is
arguably wrong. Besides, experimental results tell us that 2/ beats 3/,
and that's not something we can argue against: experimental results are
the only trusted metric.

* Also, with the benefit of hindsight, I don't think the fact that 2/ is
better than 3/ is surprising at all. The point is that it is YOUR turn to
move, and you are assuming that by NOT playing (and letting the opponent
capture your hanging pieces in QS) you cannot generally GAIN razor_margin(depth).

No functional change.

10 years agoH-file penalty and center bonus
Joona Kiiski [Fri, 31 Jan 2014 10:37:40 +0000 (10:37 +0000)]
H-file penalty and center bonus

After almost 50K at long TC it seems
slightly positive:

ELO: 1.73 +-1.8 (95%) LOS: 97.3%
Total: 47122 W: 7507 L: 7273 D: 32342

bench: 8430785

10 years agoTweak bishop PSQT tables
Joona Kiiski [Sat, 25 Jan 2014 21:08:36 +0000 (21:08 +0000)]
Tweak bishop PSQT tables

Tuned after 49K iterations of SPSA.

Passed both short TC:
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 14231 W: 2684 L: 2542 D: 9005

And long TC:
LLR: 2.94 (-2.94,2.94) [0.00,4.00]
Total: 87556 W: 13757 L: 13342 D: 60457

bench: 6875743

10 years agoReduce VALUE_KNOWN_WIN to 10000
Uri Blass [Mon, 27 Jan 2014 19:08:31 +0000 (20:08 +0100)]
Reduce VALUE_KNOWN_WIN to 10000

With some positions like

8/8/8/2p2K2/1pp5/br1p1b2/2p2r2/qqkqq3 w - -

The eval score is higher than VALUE_INFINITE because
is the sum of VALUE_KNOWN_WIN plus a big material
advantage. This leads to an assert. Here are the
steps to reproduce:

Compile SF with debug=yes then do

./stockfish
position fen 8/8/8/2p2K2/1pp5/br1p1b2/2p2r2/qqkqq3 w - -
go depth 1

This patch fixes the issue in this case, but do exsist
other positions for which the patch is not enough and
we will need to limit the eval score to be sure not
overflow the limit.

Note that is not possible to increase the value of
VALUE_INFINITE because should remain within int16_t
type to be stored in a TT entry.

bench: 7356053

10 years agoFix null reduction formula
Marco Costalba [Mon, 27 Jan 2014 06:36:26 +0000 (07:36 +0100)]
Fix null reduction formula

Depth is already dependent on the actual value
of ONE_PLY, in particular can be expressed like:

Depth = n * ONE_PLY

And because formula is used to calculate R that is
also dependent on the value of ONE_PLY and can be
expressed like:

R = x * ONE_PLY

We don't want to divide depth by a 'ply' value but
directly by an integer number.

Spotted by sf-x

No functional change.

10 years agoGrammar fix in MovePicker::next_move
Marco Costalba [Sun, 26 Jan 2014 22:09:22 +0000 (23:09 +0100)]
Grammar fix in MovePicker::next_move

Thanks to Lyudmil Antonov and Michel Van den Bergh
for spotting this and suggesting the fix.

No functional change.

10 years agoVariable null-move value based reduction
Stefan Geschwentner [Fri, 24 Jan 2014 20:52:56 +0000 (21:52 +0100)]
Variable null-move value based reduction

Instead of a fixed reduction of ONE_PLY, now
Null move dynamic reduction based on value can
grow larger in case we are above beta of a value
much higher then PawnValueMg.

Note that now an eval returning VALUE_KNOWN_WIN
makes null search to drop in qsearch.

Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 26141 W: 4871 L: 4699 D: 16571

And long TC:
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 33695 W: 5309 L: 5056 D: 23330

bench: 7356053

10 years agoDo not set default value for architeture in Makefile
Joona Kiiski [Tue, 21 Jan 2014 22:18:39 +0000 (22:18 +0000)]
Do not set default value for architeture in Makefile

Fixes a regression that ARCH parameter was not properly validated.
Invalid value would default to generic 32-bit build.

No functional change.

10 years agoSmall simplification to Position::see
Henri Wiechers [Sat, 18 Jan 2014 11:58:10 +0000 (13:58 +0200)]
Small simplification to Position::see

Verified there are no hidden bugs and is
actually a speed optimization:

Fixed games at 15+0.05 TC
ELO: 1.72 +-2.9 (95%) LOS: 87.5%
Total: 20000 W: 3741 L: 3642 D: 12617

No functional change

10 years agoFix +M0 score when low on time
Joona Kiiski [Sun, 19 Jan 2014 00:53:43 +0000 (08:53 +0800)]
Fix +M0 score when low on time

When time remaining is less than Emergency Move Time,
we won't even complete one iteration and engine reports
a stale +M0 score.

To reproduce run "go wtime 10"

info depth 1 seldepth 1 score mate 0 upperbound nodes 2 nps 500 time 4 multipv 1 pv a2a3
info nodes 2 time 4
bestmove a2a3 ponder (none)

This patch fixes the issue.

Tested by Binky at very short TC: 0.05+0.05
ELO: 5.96 +-12.9 (95%) LOS: 81.7%
Total: 1458 W: 394 L: 369 D: 695

And at a bit longer TC:
ELO: 1.56 +-3.7 (95%) LOS: 79.8%
Total: 16511 W: 3983 L: 3909 D: 8619

bench: 7804908

10 years agoIncrease max hash size to 16GB
Marco Costalba [Sat, 18 Jan 2014 17:19:16 +0000 (18:19 +0100)]
Increase max hash size to 16GB

TCEC season 3, which is due to start in a few weeks, just
had its server upgraded to 64GB RAM and will therefore allow
16GB hash to be used per engine.

This is almost the upper limit without changing the
type of size and hashMask. After this we need to
move to uint64_t instead of uint32_t.

No functional change.

10 years agoTweak knight PSQT tables
Joona Kiiski [Sun, 12 Jan 2014 10:38:19 +0000 (10:38 +0000)]
Tweak knight PSQT tables

Passed both short TC:
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 31765 W: 6103 L: 5913 D: 19749

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 38867 W: 6268 L: 5988 D: 26611

bench: 7804908

10 years agoSimplify pawnless endgame evaluation
Chris Cain [Thu, 16 Jan 2014 21:50:08 +0000 (21:50 +0000)]
Simplify pawnless endgame evaluation

Retire KmmKm evaluation function. Instead give a very drawish
scale factor when the material advantage is small and not much
material remains.

Retire NoPawnsSF array. Pawnless endgames without a bishop will
now be scored higher. Pawnless endgames with a bishop pair will
be scored lower. The effect of this is hopefully small.

Consistent results both at short TC (fixed games):
ELO: -0.00 +-2.1 (95%) LOS: 50.0%
Total: 40000 W: 7405 L: 7405 D: 25190

And long TC (fixed games):
ELO: 0.77 +-1.9 (95%) LOS: 78.7%
Total: 39690 W: 6179 L: 6091 D: 27420

bench: 7213723

10 years agoIntroduce 'follow up' moves
Stefan Geschwentner [Sun, 12 Jan 2014 21:42:16 +0000 (22:42 +0100)]
Introduce 'follow up' moves

When we have a fail-high of a quiet move, store it in
a Followupmoves table indexed by the previous move of
the same color (instead of immediate previous move as
is in countermoves case).

Then use this table for quiet moves ordering in the same
way we are already doing with countermoves.

These followup moves will be tried just after countermoves
and before remaining quiet moves.

Passed both short TC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 10350 W: 1998 L: 1866 D: 6486

And long TC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 14066 W: 2303 L: 2137 D: 9626

bench: 7205153