]> git.sesse.net Git - stockfish/log
stockfish
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

10 years agoAd-hoc shelter rule
Ralph Stößer [Sat, 11 Jan 2014 02:00:17 +0000 (03:00 +0100)]
Ad-hoc shelter rule

This hacky rule allows to get an about right eval out of this position:
r2qk2r/ppp2p2/2npbn2/2b1p3/2P1P1P1/2NB1PPp/PPNP3K/R1BQ1R2 b kq - 0 13

And, more importantly, passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 6239 W: 1249 L: 1127 D: 3863

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 38371 W: 6165 L: 5888 D: 26318

bench: 8183238

10 years agoRetire KBBKN endgame
Marco Costalba [Sun, 12 Jan 2014 21:32:41 +0000 (22:32 +0100)]
Retire KBBKN endgame

As pointed out by Joona, Lucas and otehr people in
the forum, this endgame is not a known, there are many
positions where it takes more than 50 moves to claim the
win and becasue exact rules is not possible better to
retire and allow the search to workout the endgame for us.

bench: 8502826

10 years agoRename Position::hidden_checkers to check_blockers
Henri Wiechers [Sat, 11 Jan 2014 09:58:09 +0000 (11:58 +0200)]
Rename Position::hidden_checkers to check_blockers

No functional change.

10 years agoPosition::gives_check - use ci.ksq
Henri Wiechers [Tue, 7 Jan 2014 15:55:32 +0000 (17:55 +0200)]
Position::gives_check - use ci.ksq

Also remove a couple of local variables while
there.

No functional change.

10 years agoFix early stop condition
Marco Costalba [Wed, 8 Jan 2014 21:58:25 +0000 (06:58 +0900)]
Fix early stop condition

While editing original Uri's messy patch
I have incorrectly simplified the logic
condition. Here is the correct original
version, as it was tested.

bench: 8502826

10 years agoRetire easy move
Ralph Stoesser [Wed, 8 Jan 2014 14:54:37 +0000 (23:54 +0900)]
Retire easy move

Remove the easy move code and add the condition to
play instantly if only one legal move is available.

Verified there is no regression at 60+0.05
ELO: 0.17 +-1.9 (95%) LOS: 57.0%
Total: 40000 W: 6397 L: 6377 D: 27226

bench: 8502826

10 years agoStop earlier if iteration is taking too long
Uri Blass [Mon, 6 Jan 2014 06:06:39 +0000 (08:06 +0200)]
Stop earlier if iteration is taking too long

If we are still at first move, without a fail-low and
current iteration is taking too long to complete then
stop the search.

Passed short TC:
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 26030 W: 4959 L: 4785 D: 16286

Long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 18019 W: 2936 L: 2752 D: 12331

And performed well at 40/30
ELO: 4.33 +-2.8 (95%) LOS: 99.9%
Total: 20000 W: 3480 L: 3231 D: 13289

bench: 8502826

10 years agoRetire grain size code
renouve [Thu, 2 Jan 2014 05:00:44 +0000 (00:00 -0500)]
Retire grain size code

Seems useless at long TC.

Tested at 60+0.05
ELO: 2.98 +-2.2 (95%) LOS: 99.6%
Total: 30440 W: 4934 L: 4673 D: 20833

And at 120+0.05
ELO: 2.50 +-2.6 (95%) LOS: 97.1%
Total: 19633 W: 2848 L: 2707 D: 14078

bench: 8502826

10 years agoAssorted grammar fixes
Marco Costalba [Tue, 7 Jan 2014 05:25:35 +0000 (14:25 +0900)]
Assorted grammar fixes

Mainly from Lyudmil Antonov and
one from Henri Wiechers and Louis Zulli.

No functional change.

10 years agoTweak King PST tables
Joona Kiiski [Mon, 6 Jan 2014 19:46:49 +0000 (19:46 +0000)]
Tweak King PST tables

First tested with 50K games at very short TC of 5+0.05
ELO: 3.11 +-2.0 (95%) LOS: 99.9%
Total: 49665 W: 10941 L: 10497 D: 28227

Then retested with usual SPRT at short TC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 16875 W: 3198 L: 3049 D: 10628

And at long TC
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 5890 W: 985 L: 857 D: 4048

bench: 7800379

10 years agoFix a typo
Marco Costalba [Mon, 6 Jan 2014 00:21:44 +0000 (01:21 +0100)]
Fix a typo

Spotted by Isaac H. Dunn.

No functional change.

10 years agoRemove duplicated code
Pablo Vazquez [Sun, 5 Jan 2014 13:08:26 +0000 (14:08 +0100)]
Remove duplicated code

Introduce update_stats() and remove correspondng
duplicated code.

No functional change.

10 years agoEnsure move_importance() is non-zero
H. Felix Wittmann [Thu, 2 Jan 2014 12:00:48 +0000 (13:00 +0100)]
Ensure move_importance() is non-zero

In case ply is very high, function will round
to zero (although mathematically it is always
bigger than zero). On my system this happens at
movenumber 6661.

Although 6661 moves in a game is, of course,
probably impossible, for safety and to be locally
consistent makes sense to ensure returned value
is positive.

Non functional change.

10 years agoScale eval when down to only one pawn
shane31 [Tue, 31 Dec 2013 20:45:20 +0000 (07:45 +1100)]
Scale eval when down to only one pawn

Passed both short TC
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 11921 W: 2346 L: 2208 D: 7367

And long TC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 21002 W: 3395 L: 3197 D: 14410

bench: 7602383

10 years agoUpdate copyright year
Marco Costalba [Thu, 2 Jan 2014 00:48:07 +0000 (01:48 +0100)]
Update copyright year

No functional change.

10 years agoSimplify move_importance(): take 3
Marco Costalba [Wed, 1 Jan 2014 12:43:58 +0000 (13:43 +0100)]
Simplify move_importance(): take 3

Use pow() of a negative number instead of 1/x

No functional change.

10 years agoFurther simplify move_importance()
Marco Costalba [Wed, 1 Jan 2014 12:35:11 +0000 (13:35 +0100)]
Further simplify move_importance()

Function move_importance() is already always
positive, so we don't need to add a constant
term to ensure it.

Becuase move_importance() is used to calculate
ratios of a linear combination (as explained in
previous patch), result is not affected. I have
also verified it directly.

No functional change.

10 years agoSimplify move_importance()
H. Felix Wittmann [Tue, 31 Dec 2013 11:24:57 +0000 (12:24 +0100)]
Simplify move_importance()

Drop a useless parameter. This works because ratio1 and ratio2
are ratios of linear combinations of thisMoveImportance and
otherMovesImportance and so the yscale cancels out.

Therefore the values of ratio1 and ratio2 are independent
of yscale and yscale can be retired.

The same applies to yshift, but here we want to ensure
move_importance() > 0, so directly hard-code this safety
guard in function definition.

Actually there are some small differences due to rounding errors
and usually are at most few millisecond, that's means below 1% of
returned time, apart from very short intervals in which a difference
of just 1 msec can raise to 2-3% of total available time.

No functional change.

10 years agoRename pawn chain to connected
Marco Costalba [Wed, 1 Jan 2014 09:50:30 +0000 (10:50 +0100)]
Rename pawn chain to connected

The flag raises also in case of a pawn duo, i.e.
when we have two adjacent pawns on the same rank,
and not only in case of a chain, i.e. when the two
pawns are on a diagonal line.

See this for a reference:
http://en.wikipedia.org/wiki/Connected_pawns

Renaming suggested by Ralph.

No functional change.

10 years agoRemove bishop pin bonus
Gary Linscott [Fri, 27 Dec 2013 22:12:08 +0000 (17:12 -0500)]
Remove bishop pin bonus

Shows no regression at LTC after 20K games:

ELO: 0.03 +-2.7 (95%) LOS: 51.0%
Total: 20608 W: 3252 L: 3250 D: 14106

bench: 7516178

10 years agoRetire KingExposed[] array
Arjun Temurnikar [Mon, 30 Dec 2013 07:13:39 +0000 (23:13 -0800)]
Retire KingExposed[] array

And merge its values into KPSQT table.

Passed blazingly fast both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 5348 W: 1091 L: 971 D: 3286

And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 3029 W: 530 L: 415 D: 2084

bench: 8702197

10 years agoRemove asymmThreshold stale comment
Henri Wiechers [Mon, 30 Dec 2013 04:56:28 +0000 (06:56 +0200)]
Remove asymmThreshold stale comment

No functional change.

10 years agoRetire asymmThreshold
Marco Costalba [Sat, 28 Dec 2013 09:30:35 +0000 (10:30 +0100)]
Retire asymmThreshold

Verified with 40K games at long TC does not regress:
ELO: 1.74 +-1.9 (95%) LOS: 96.2%
Total: 39624 W: 6402 L: 6203 D: 27019

bench: 7762310

10 years agoRetire MoveImportance[]
Matt Sullivan [Fri, 27 Dec 2013 01:48:14 +0000 (19:48 -0600)]
Retire MoveImportance[]

Use a skew-logistic function to replace the
MoveImportance[] array.

Verified it does not regress at fixed number
of games both at short TC:
LLR: -2.91 (-2.94,2.94) [-1.50,4.50]
Total: 39457 W: 7539 L: 7538 D: 24380

And long TC:
ELO: -0.49 +-1.9 (95%) LOS: 31.0%
Total: 39358 W: 6135 L: 6190 D: 27033

bench: 7335588

10 years agoFine tune previous patch
Stefan Geschwentner [Fri, 27 Dec 2013 17:46:05 +0000 (18:46 +0100)]
Fine tune previous patch

Passed short TC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 18331 W: 3608 L: 3453 D: 11270

And scored above 50% on a very long test in long TC
LLR: -2.97 (-2.94,2.94) [0.00,6.00]
Total: 51533 W: 8181 L: 8047 D: 35305

bench: 7335588

10 years agoFurther simplify previous patch
Marco Costalba [Thu, 26 Dec 2013 11:08:23 +0000 (12:08 +0100)]
Further simplify previous patch

Use a single XOR instead of NEGATE + AND

No functional change.

10 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

10 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

10 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

10 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

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

No functional change.

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

No functional change.

10 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

10 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

10 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

10 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

10 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.

10 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.

10 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.

10 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.

10 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.

10 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.

10 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.

10 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.

10 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

10 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.

10 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.

10 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.

10 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.

10 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.

10 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.

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

No functional change.

10 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.

10 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.

10 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.

10 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.

10 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.

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

bench: 8596156

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

Stockfish bench signature is: 8596156

10 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.

10 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

10 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

10 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

10 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

10 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)

10 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

10 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

10 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.

10 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

10 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.

10 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.

10 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.

10 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

10 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

10 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.