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
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.
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.
Marco Costalba [Sat, 1 Mar 2014 21:07:41 +0000 (22:07 +0100)]
Rename xxx_to_char() -> to_char()
No functional change.
Marco Costalba [Sat, 1 Mar 2014 12:05:55 +0000 (13:05 +0100)]
Simplify Bitboards::pretty
No functional change.
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.
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
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
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
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
Marco Costalba [Thu, 20 Feb 2014 07:27:13 +0000 (08:27 +0100)]
Avoid recalculating CheckInfo in generate_castling()
No functional change.
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.
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.
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.
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
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.
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.
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.
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.
Marco Costalba [Sat, 15 Feb 2014 08:20:27 +0000 (09:20 +0100)]
Assorted renaming in search
Inspired by DON.
No functional change.
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
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.
Marco Costalba [Fri, 14 Feb 2014 08:42:50 +0000 (09:42 +0100)]
Additional renaming from DON
Assorted renaming and triviality.
No functional change.
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.
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
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.
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
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.
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.
Marco Costalba [Sat, 8 Feb 2014 12:21:50 +0000 (13:21 +0100)]
Rewrite previous patch removing the macro
No functional change.
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.
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)
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
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.
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.
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
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
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
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.
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.
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
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.
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
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
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.
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
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
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
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
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
Henri Wiechers [Sat, 11 Jan 2014 09:58:09 +0000 (11:58 +0200)]
Rename Position::hidden_checkers to check_blockers
No functional change.
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.
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
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
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
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
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.
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
Marco Costalba [Mon, 6 Jan 2014 00:21:44 +0000 (01:21 +0100)]
Fix a typo
Spotted by Isaac H. Dunn.
No functional change.
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.
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.
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
Marco Costalba [Thu, 2 Jan 2014 00:48:07 +0000 (01:48 +0100)]
Update copyright year
No functional change.
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.
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.
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.
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.
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
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
Henri Wiechers [Mon, 30 Dec 2013 04:56:28 +0000 (06:56 +0200)]
Remove asymmThreshold stale comment
No functional change.
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
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
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
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.
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
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
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
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
Marco Costalba [Tue, 17 Dec 2013 09:14:15 +0000 (10:14 +0100)]
Further simplify Makefile
No functional change.
Marco Costalba [Tue, 17 Dec 2013 08:30:42 +0000 (09:30 +0100)]
Reformat Makefile
No functional change.
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
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
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
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
Marco Costalba [Sat, 7 Dec 2013 11:09:33 +0000 (12:09 +0100)]
More work on Bitboards::init()
No functional change.
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.
Marco Costalba [Sat, 7 Dec 2013 09:57:05 +0000 (10:57 +0100)]
Further simplify Bitboards init()
No functional change.
Marco Costalba [Fri, 6 Dec 2013 09:43:17 +0000 (10:43 +0100)]
Clarify definition of capture_or_promotion()
No functional change.
Arjun Temurnikar [Thu, 5 Dec 2013 06:18:12 +0000 (07:18 +0100)]
Even more spelling fixes
No functional change.
Arjun Temurnikar [Wed, 4 Dec 2013 21:57:00 +0000 (13:57 -0800)]
Assorted spelling/grammar/captitalization
No functional change.
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.
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.
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
Marco Costalba [Tue, 3 Dec 2013 10:37:29 +0000 (11:37 +0100)]
Shrink Position::is_draw()
No functional change.
Marco Costalba [Tue, 3 Dec 2013 10:06:59 +0000 (11:06 +0100)]
Remove redundant argument from hidden_checkers()
No functional change.
Marco Costalba [Tue, 3 Dec 2013 09:09:17 +0000 (10:09 +0100)]
Small improvment to Position::fen()
No functional change.
Jerry Donald [Tue, 3 Dec 2013 07:50:00 +0000 (08:50 +0100)]
Re-fix a comment
No functional change.
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.
Richard Lloyd [Mon, 2 Dec 2013 18:04:09 +0000 (19:04 +0100)]
Big assorted spelling fixes
No functional change.
Jerry Donald [Mon, 2 Dec 2013 17:39:26 +0000 (18:39 +0100)]
Assorted spelling fixes
No functional change.