]>
git.sesse.net Git - stockfish/log
Chris Caino [Tue, 22 Oct 2013 21:02:38 +0000 (23:02 +0200)]
Simplify futility move count formula
Simpler formula but introduces some slight changes if d >= 10
Original code grows like 0.225 * d^1.8
New code grows like 0.222 * d^1.8
Full list of values:
d old new diff
--------------
0 2 2 0
1 2 2 0
2 3 3 0
3 4 4 0
4 5 5 0
5 6 6 0
6 7 7 0
7 9 9 0
8 11 11 0
9 13 13 0
10 15 16 1
11 18 19 1
12 21 21 0
13 24 24 0
14 27 28 1
15 31 31 0
16 35 35 0
17 39 38 -1
18 42 42 0
19 47 46 -1
20 51 51 0
21 55 55 0
22 60 60 0
23 65 65 0
24 70 70 0
25 75 75 0
26 81 80 -1
27 87 86 -1
28 92 91 -1
29 98 97 -1
30 104 103 -1
31 111 109 -2
Test code:
int main() {
for(int d=0; d<32; d++)
{
int a = int(3 + 0.3 * pow(double(d), 1.8)) * 3/4 + (2 < d && d < 5);
int b = int(2.4 + 0.222 * pow(d + 0.0, 1.8));
std::cout << d << " " << a << " " << b << " " << b-a << std::endl;
}
return 0;
}
bench:
8350690
Chris Caino [Tue, 22 Oct 2013 21:05:15 +0000 (23:05 +0200)]
Simplify futility margins formula
New formula mathces the old formula until d = 45
Test code:
int main() {
for(int d=1; d<=45; d++)
{
int a = int(log(double(d * d) / 2) / log(2.0) + 1.001);
int b = int(2.9 * log(double(d)));
if (a != b) std::cout << d << std::endl;
}
return 0;
}
bench:
8455956
Marco Costalba [Tue, 22 Oct 2013 15:47:16 +0000 (17:47 +0200)]
Tweak again chain pawn bonus
This is the first chain bonus version
from Ralph that also passed both
Short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 23460 W: 4727 L: 4556 D: 14177
And long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 31858 W: 5497 L: 5240 D: 21121
And performed better against current
committed version, always at 60secs:
LLR: -2.94 (-2.94,2.94) [-3.00,3.00]
Total: 26301 W: 4477 L: 4580 D: 17244
This test was done by Leonid.
bench:
8455956
Marco Costalba [Tue, 22 Oct 2013 15:33:11 +0000 (17:33 +0200)]
Re-add "Further increase safe checks bonus"
After 40K games at 60 secs, result is still
not clear, but not a regression against SF 4
After
ELO: 50.11 +-2.1 (95%) LOS: 100.0%
Total: 40000 W: 10547 L: 4817 D: 24636
Before
ELO: 49.51 +-2.1 (95%) LOS: 100.0%
Total: 40000 W: 10483 L: 4821 D: 24696
So re-apply the patch to avoid to
special-case this one.
bench:
7403882
Marco Costalba [Tue, 22 Oct 2013 15:27:58 +0000 (17:27 +0200)]
Restore behaviour after count<ALL_PIECES> fix
Because pos.count<ALL_PIECES>(Us) was always zero,
rewrite the formula as if this would still be
the case.
bench:
8510004
Ralph Stößer [Sun, 20 Oct 2013 21:41:02 +0000 (23:41 +0200)]
Further improve chain pawn evaluation
Passed both short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 28299 W: 5854 L: 5667 D: 16778
And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 9738 W: 1797 L: 1644 D: 6297
bench:
9294116
Marco Costalba [Sun, 20 Oct 2013 21:35:10 +0000 (23:35 +0200)]
Fix pos.count<ALL_PIECES>()
It was never updated !
Currently it only affects evaluate_passed_pawns()
and in particularly the rule to increase the bonus
if we have more non-pawn pieces. We could simply use
popcount() instead and avoid the little slowdown
in put_piece() and remove_piece(), but this would
leave a very subtle and tricky hole where people
are forced to remember that pos.count<ALL_PIECES>()
does not work. This is not obvious and so dangerous.
Thanks to Ronald de Man for spotting this.
bench:
7931424
Marco Costalba [Sat, 13 Jul 2013 21:07:24 +0000 (23:07 +0200)]
Fix build on Intel compiler
Due to a strange issue (bug?) the ternary
operator does not return a BitCountType for
icc, so revert to the expression.
The same patch was already applied in
9749f1f14c956133c2f42f96592b
Thanks to NssY Wanyonyi for pointing out
this.
No functional change.
Marco Costalba [Sun, 20 Oct 2013 07:55:12 +0000 (09:55 +0200)]
Revert "Further increase safe checks bonus"
This reverts commit
4bc2374450e30101392 for
two reasons.
First regression testing shows almost equal
score:
Before the patch:
ELO: 49.75 +-2.5 (95%) LOS: 100.0%
Total: 27205 W: 7113 L: 3244 D: 16848
After the patch:
ELO: 48.87 +-2.9 (95%) LOS: 100.0%
Total: 20860 W: 5478 L: 2563 D: 12819
Second, and more sensible to me, this patch
increases safe check bonuses to 4 times their
original value (!) and considering:
- Values were already well tuned
- Values are highly critical
- King safety is highly critical, very TC
dependent and very difficult to test
- Our testing coverage is partial (self-testing,
blitz times)
I think is better to be safe than sorry and so
I revert the patch.
bench:
8440524
Ralph Stößer [Tue, 15 Oct 2013 18:09:35 +0000 (20:09 +0200)]
Further increase safe checks bonus
Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 10466 W: 2087 L: 1953 D: 6426
And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 26334 W: 4540 L: 4310 D: 17484
And also proved stronger than a slightly
different patch, also succesful against master:
https://github.com/mcostalba/Stockfish/commit/
dc6830a3b4ed12
But losing against current one in a match
at 60secs with SPRT [-3, 3]:
LLR: -2.96 (-2.94,2.94) [-3.00,3.00]
Total: 44484 W: 7360 L: 7463 D: 29661
bench:
9160831
Marco Costalba [Fri, 18 Oct 2013 15:42:52 +0000 (08:42 -0700)]
Some evaluation code reshuffle
No functional change.
Jörg Oster [Fri, 18 Oct 2013 08:23:28 +0000 (10:23 +0200)]
Score chain pawn also by rank
Use the (rescaled) CandidatePassed[] table
that is already rank based.
Passed both short TC
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 11048 W: 2272 L: 2135 D: 6641
And long TC
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 4116 W: 769 L: 645 D: 2702
bench:
8440524
Chris Caino [Mon, 14 Oct 2013 23:20:34 +0000 (00:20 +0100)]
Simplification of KPsK function
Also the drawing criteria has been slightly loosened.
It now detects a draw if the king is ahead of all the
pawns and on the same file or the adjacent file.
bench:
7700683
Chris Caino [Mon, 14 Oct 2013 23:09:05 +0000 (00:09 +0100)]
Bug fix for KQKRPs endgame
This lost position 8/8/3q4/8/5k2/2P1R3/2K2P2/8 w - - 0 1
was previously evaluated as a draw.
The king and rook need to be correctly placed with
respect to the _same_ pawn.
(Note also that the check for the pawn being on RANK_2
in the old version is redundant: it must be on RANK_2 if
it hopes to protect a rook on RANK_3)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Ralph Stößer [Sat, 12 Oct 2013 10:59:43 +0000 (12:59 +0200)]
Double king safety weights
Good both at short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 5448 W: 1133 L: 1012 D: 3303
And at long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 40509 W: 6836 L: 6541 D: 27132
bench:
7700683
Chris Caino [Mon, 14 Oct 2013 17:53:08 +0000 (19:53 +0200)]
Remove a drawing rule from KBPsK function
The rule can be incorrect if the attacking king is
well placed e.g. 8/6K1/8/8/7k/1B6/7P/8 w - - 0 1
bench:
8279065
Marco Costalba [Mon, 14 Oct 2013 17:34:12 +0000 (19:34 +0200)]
Massive stronger/weaker renming
No functional change.
Chris Caino [Mon, 14 Oct 2013 12:57:08 +0000 (13:57 +0100)]
Add helper function verify_material
Allows to remove a lot of assert code in endgames.
No functional change.
ceebo [Sun, 13 Oct 2013 20:50:45 +0000 (21:50 +0100)]
Add some knowledge for KRPKB endgame
bench:
8279065
ceebo [Sun, 13 Oct 2013 15:44:51 +0000 (16:44 +0100)]
Improve KBPsK endgame
Better endgame with bishop and blocked g-pawn
bench:
8279065
Marco Costalba [Sun, 13 Oct 2013 09:20:35 +0000 (02:20 -0700)]
Remove unuseful optimization in RKISS
Don't need a struct here. Speed test shows
result is teh same. Moreover RKISS is used
mainly at startup to compute magics, so
prefer to keep it simple...RKISS ;-)
Also some assorted triviality while there.
No functional change.
Joona Kiiski [Tue, 8 Oct 2013 21:43:33 +0000 (22:43 +0100)]
Smoother transition for LMR
Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 12376 W: 2596 L: 2454 D: 7326
And long TC:
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 14798 W: 2584 L: 2409 D: 9805
bench:
8279065
Uri Blass [Sat, 5 Oct 2013 19:20:20 +0000 (22:20 +0300)]
Increase slowmover and reduce instability
These two changes go in opposite directions and it
seems that the combination is stronger than original.
Here are the positive tests at various TC:
15+0.05
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 24561 W: 4946 L: 4772 D: 14843
60+0.05
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 15259 W: 2598 L: 2423 D: 10238
40/30
LLR: 2.96 (-2.94,2.94) [-3.00,3.00]
Total: 2570 W: 527 L: 422 D: 1621
Unfortunately there is also a bad result
with one sec time increment that needs
to be further investigated:
12+1
LLR: -2.97 (-2.94,2.94) [-3.00,3.00]
Total: 2694 W: 438 L: 543 D: 1713
bench:
8340585
Lucas Braesch [Mon, 7 Oct 2013 07:10:48 +0000 (09:10 +0200)]
Use TT refined value to stand pat
Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 17811 W: 3520 L: 3366 D: 10925
And long TC:
LLR: 2.95 (-2.94,2.94) [0.00,6.00]
Total: 30255 W: 5070 L: 4825 D: 20360
bench:
8340585
Lucas Braesch [Thu, 3 Oct 2013 04:05:58 +0000 (12:05 +0800)]
Use double everywhere
Rationale:
- Speed of double and float is about the same (not on the hot path anyway)
- Double makes code prettier (no need to write 1.0f, just 1.0)
- Only practical advantage of float is to use less memory, but since we never
store large arrays of double, we don't care.
No functional change.
Lucas Braesch [Thu, 3 Oct 2013 04:01:38 +0000 (12:01 +0800)]
Use prefix operators wherever possible
No functional change.
Marco Costalba [Sun, 29 Sep 2013 07:43:10 +0000 (09:43 +0200)]
Add more depth/positions to bench
Increase bench default depth from 12 to 13 and
add 15 new endgame positions to have broader
coverage and also more reliable nps calulcation
used for fishtest framework.
Due to the new endgame positions, where nps is higher,
the total nps is increased of about 15%.
Thanks to Lucas and Jörg for the suggestions.
No functional change, but bench number is now:
bench:
8336338
Marco Costalba [Sat, 28 Sep 2013 12:43:50 +0000 (05:43 -0700)]
Drop 'is' prefix from query functions
Most but not all.
No functional change.
Marco Costalba [Sat, 28 Sep 2013 11:14:59 +0000 (04:14 -0700)]
Fix build on Mac OS X
For some users -stack_size,0x4000 does not work,
so revert for now.
osX 10.6.8
gcc version 4.7.3 (MacPorts gcc47 4.7.3_2)
g++: error: unrecognized command line option '-stack_size,0x4000'
make[2]: *** [stockfish] Error 1
make[1]: *** [gcc-profile-make] Error 2
make: *** [profile-build] Error 2
No functional change.
Marco Costalba [Sat, 28 Sep 2013 07:59:45 +0000 (09:59 +0200)]
Revert "Use a per-thread array"
This reverts commit
800410eef1c0811 and instead increases
stack size.
I went through the old emails with Daylen that reported the
crash issue on Mac OS X and was fixed by
0049d3f337b6f3a66a0 .
It was reported default stack size for a thread in Mac OS X is 8
megabytes while the patch that we are reverting allows to reduce
stack size at max of about 217KB, so the reason for the crash was
only marginal in MAX_MOVES value. On those emails Daylen also
hinted how to increase stack size for Mac OS X to 16MB.
So prefer to increase stack size to 16MB instad of re-inventing
the wheel and do our home grown stack as we did with the patch
that we are now reverting (it will remain anyhow in git history
for documentation purposes).
No functional change.
Lucas Braesch [Thu, 26 Sep 2013 10:25:27 +0000 (18:25 +0800)]
Simplify extensions
Unify extensions between PV and not PV nodes
and remove all but check extensions.
This is a simplification so tested at fixed number
of games where proved to not regress.
About 45k games at 15+0.05
ELO: 1.23 +-2.0 (95%) LOS: 88.5%
Total: 45643 W: 9107 L: 8946 D: 27590
About 45k games at 60+0.05
ELO: 1.07 +-1.8 (95%) LOS: 87.8%
Total: 46786 W: 7728 L: 7584 D: 31474
bench:
3172206
Reuven Peleg [Wed, 25 Sep 2013 11:04:38 +0000 (14:04 +0300)]
Simplify tte use condition
No functional change.
Raminder Singh [Wed, 25 Sep 2013 13:17:59 +0000 (18:47 +0530)]
Fix best move lookup bug
If the uci option 'Best Book Move' is set to true the lookup still
returns a move at random instead of the move with the highest
weight.
No functional change.
Marco Costalba [Fri, 27 Sep 2013 06:50:29 +0000 (08:50 +0200)]
Increase MAX_MOVES to 256
This should be enough for any legal position, even
the handcrafted ones, like the one presented by Reuven:
1Q5R/4Q1K1/B1Q5/B4Q2/N2Q4/pQ4Q1/pn2Q3/krQ4R w - -
Where currently we crash. This reverts the patch
0049d3f337b6f3a66a06503c of 8/4/2012 where stack
was shrinked due to crashes while in deep analysys.
No functional change.
Marco Costalba [Thu, 26 Sep 2013 17:25:50 +0000 (19:25 +0200)]
Use a per-thread array for generated moves
This greately reduces stack usage and is a
prerequisite for next patch.
Verified with 40K games both in single and SMP
case that there are no regressions.
No functional change.
Jean-Francois Romang [Sun, 22 Sep 2013 16:10:24 +0000 (18:10 +0200)]
Update disabled warnings for Intel compiler
No functional change.
Jean-Francois Romang [Sun, 22 Sep 2013 16:02:39 +0000 (18:02 +0200)]
Replace -O3 with -fast for intel compiler
No functional change.
Ralph Stößer [Mon, 23 Sep 2013 06:03:12 +0000 (08:03 +0200)]
Reduce negative quiets by ONE_PLY / 2
Passed both short TC:
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 3402 W: 708 L: 593 D: 2101
And long TC:
LLR: 2.93 (-2.94,2.94) [0.00,6.00]
Total: 23379 W: 3972 L: 3759 D: 15648
bench:
3529630
Marco Costalba [Mon, 23 Sep 2013 05:59:51 +0000 (07:59 +0200)]
Final time management setup
This is an even safer setup proposed and tested
by Alexandre Meirelles.
Regression testing of 40K games at 10+0.05 show
result is stable both against current master:
ELO: -0.29 +-2.2 (95%) LOS: 39.7%
Total: 40000 W: 8010 L: 8043 D: 23947
and again original master (the one with smallest
time parameters):
ELO: 1.71 +-2.2 (95%) LOS: 93.8%
Total: 40000 W: 8325 L: 8128 D: 23547
Alexandre verified with LittleBlitzer time losses are
greately reduced with this setup:
Games Completed = 2100 of 3000 (Avg game length = 35.745 sec)
Settings = RR/128MB/15000ms+50ms/M 1000cp for 12 moves, D 150 moves/
Time = 39200 sec elapsed, 16800 sec remaining
1. Stockfish 190913 1091.5/2100 803-720-577 (L: m=313 t=1 i=0 a=406) (D: r=278 i=91 f=136 s=8 a=64) (tpm=212.5 d=14.75 nps=925427)
2. Houdini 2.0 w32 1008.5/2100 720-803-577 (L: m=250 t=299 i=0 a=254) (D: r=278 i=91 f=136 s=8 a=64) (tpm=204.1 d=12.04 nps=
1326351 )
No functional change.
Marco Costalba [Thu, 19 Sep 2013 05:26:36 +0000 (07:26 +0200)]
Increase Emergency Move Time to 20
Goes in the direction of avoiding time losses and seems
equivalent after almost 40K games at super fast TC of 10+0.05
ELO: 2.61 +-2.2 (95%) LOS: 99.1%
Total: 39869 W: 8258 L: 7959 D: 23652
No functional change.
Marco Costalba [Tue, 17 Sep 2013 06:02:46 +0000 (08:02 +0200)]
Increase Emergency Move Time to 10
Goes in the direction of avoiding time losses and seems
equivalent after almost 40K games at super fast TC of 10+0.05
ELO: 2.41 +-2.3 (95%) LOS: 98.1%
Total: 37222 W: 7843 L: 7585 D: 21794
No functional change.
Marco Costalba [Mon, 16 Sep 2013 21:59:37 +0000 (23:59 +0200)]
Fix a silly unstoppable eval bug
The logic is broken for black side because we get more bonus
for pawn in 7th rank than for pawn in 2nd rank!
Spotted by Reuven Peleg
bench:
3884409
Joona Kiiski [Sun, 15 Sep 2013 19:54:26 +0000 (21:54 +0200)]
Fix time parameters for blitz games
The ideal setting for super-blitz might be something like:
"Emergency Base Time" = 50
"Emergency Move Time" = 5
This would give a total emergency time buffer of:
50 + 40 * 5 = 250 ms
This setup replaces the previous half cooked hack
"Don't blunder under extreme time pressure".
Test results are very good at super blitz, but keep good even
at 60 secs.
At 5+0.05
ELO: 24.30 +-2.4 (95%) LOS: 100.0%
Total: 37802 W: 10060 L: 7420 D: 20322
At 15+0.05
ELO: 13.41 +-2.9 (95%) LOS: 100.0%
Total: 22271 W: 4853 L: 3994 D: 13424
At 60+0.05
ELO: 5.30 +-3.2 (95%) LOS: 99.9%
Total: 16000 W: 2897 L: 2653 D: 10450
No functional change.
Marco Costalba [Tue, 10 Sep 2013 09:41:10 +0000 (11:41 +0200)]
Rewrite unstoppable pawns evaluation
Instead of current code, give a bonus according to the frontmost
square among candidate + passed pawns.
This is a big simplification that removes a lot of accurate code
substituting it with a statistically based one using the common
'bonus' scheme, leaving to the search to sort out the details.
Results are equivalent but code is much less and, as an added bonus,
we now store candidates bitboard in pawns hash and allow this
info to be used in evaluation. This paves the way to possible
candidate pawns evaluations together with all the other pieces,
as we do for passed.
Patch passed short TC
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 16927 W: 3462 L: 3308 D: 10157
Then failed (quite quickly) at long TC
LLR: -2.95 (-2.94,2.94) [0.00,6.00]
Total: 8451 W: 1386 L: 1448 D: 5617
But when ran with a conclusive 40K fixed games at 60 secs it proved
almost equivalent to original one.
ELO: 1.08 +-2.0 (95%) LOS: 85.8%
Total: 40000 W: 6739 L: 6615 D: 26646
bench:
3884003
Reuven Peleg [Sun, 15 Sep 2013 12:14:56 +0000 (15:14 +0300)]
Code style at passed pawn eval
No functional change.
Reuven Peleg [Sun, 15 Sep 2013 12:01:20 +0000 (15:01 +0300)]
Nicer operator declerations
No functional change.
Kojirion [Sun, 15 Sep 2013 07:11:29 +0000 (09:11 +0200)]
Use pre-increment also for native types
Now that we use pre-increment on enums, it
make sense, for code style uniformity, to
swith to pre-increment also for native types,
although there is no speed difference.
No functional change.
Marco Costalba [Sun, 15 Sep 2013 07:02:09 +0000 (09:02 +0200)]
Fix operator++ definition
ENABLE_OPERATORS_ON has incorrect definitions of
post-increment and post-decrement operators.
In particularly the returned value is the variable
already incremented/decremented, while instead they
should return the variable _before_ inc/dec.
This has no real effect because are only used in loops
and where the returned value is never used, neverthless
it is wrong. The fix would be to copy the variable to a
dummy, then inc/dec the variable, then return the dummy.
So instead, rename to pre-increment that can be implemented
without the dummy, actually the current implementation
it is already the correct pre-increment, with the only change
to return a reference (an l-value) and not a copy, so
to properly mimic the pre-increment on native integers.
Spotted by Kojirion.
No functional change.
Marco Costalba [Sat, 14 Sep 2013 07:46:32 +0000 (09:46 +0200)]
Don't blunder under extreme time pressure
We always attempt to keep at least this emergencyBaseTime
at clock. But if available time is very low it means that
we will force ourself to play immediately to satisfy the
emergencyBaseTime constrain and so leading to blunders.
Patch is good at short and very short TC (15secs and 5secs respectively)
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 26590 W: 5426 L: 5245 D: 15919
LLR: 2.96 (-2.94,2.94) [-1.50,4.50]
Total: 5767 W: 1397 L: 1268 D: 3102
Instead seems has no influence at longer TC (60 secs)
LLR: -2.96 (-2.94,2.94) [0.00,6.00]
Total: 79862 W: 13623 L: 13339 D: 52900
So it is committed to have a broader testing but is
to be consider still EXPERIMENTAL and can be reverted
easily.
No functional change.
Marco Costalba [Sat, 14 Sep 2013 10:49:24 +0000 (12:49 +0200)]
Move classify_leaf() to c'tor in bitbases
No functional change.
Marco Costalba [Sat, 14 Sep 2013 08:37:28 +0000 (10:37 +0200)]
Small touches to bitbase.cpp
Inspired by Lucas's code:
https://github.com/lucasart/chess/blob/master/src/kpk.cc
No functional change.
Reuven Peleg [Thu, 12 Sep 2013 13:20:53 +0000 (16:20 +0300)]
Increase passed bonus for having more pieces
Passed both short TC:
LLR: 2.95 (-2.94,2.94) [-1.50,4.50]
Total: 36463 W: 7575 L: 7365 D: 21523
And long TC:
LLR: 2.97 (-2.94,2.94) [0.00,6.00]
Total: 2953 W: 564 L: 446 D: 1943
bench:
3846852
Marco Costalba [Thu, 12 Sep 2013 06:41:28 +0000 (08:41 +0200)]
Revert "Move draw by material check"
Possible regression
bench:
4554579
Marco Costalba [Thu, 12 Sep 2013 06:37:50 +0000 (08:37 +0200)]
Revert "Fix random moves when time < 10ms"
Possible regression.
No functional change.
Marco Costalba [Wed, 11 Sep 2013 07:22:57 +0000 (09:22 +0200)]
Extend checks more when below alpha
Passed both short TC:
LLR: 2.97 (-2.94,2.94) [-1.50,4.50]
Total: 8739 W: 1830 L: 1698 D: 5211
And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 6716 W: 1238 L: 1101 D: 4377
bench:
4554576
Uri Blass [Tue, 10 Sep 2013 06:37:23 +0000 (08:37 +0200)]
Extend checks more in losing positions
Passed both short TC:
LLR: 2.98 (-2.94,2.94) [-1.50,4.50]
Total: 3974 W: 860 L: 741 D: 2373
And long TC:
LLR: 2.96 (-2.94,2.94) [0.00,6.00]
Total: 16807 W: 2917 L: 2733 D: 11157
bench:
3767999
Reuven Peleg [Tue, 10 Sep 2013 18:39:48 +0000 (21:39 +0300)]
Simplify unstoppable pawns evaluation
No functional change
Marco Costalba [Tue, 10 Sep 2013 19:14:09 +0000 (21:14 +0200)]
Fix random moves when time < 10ms
In case we have less then 10ms to think as soon as
we wake up the timer, it immediately fires and calls
check_time() where due to condition:
elapsed > TimeMgr.maximum_time() - 2 * TimerResolution
the stop flag is set and search returns immediately, without
actually search anything.
Here the somewhat hacky fix is to start the timer after
at least one iteration as been completed.
No functional change.
Reuven Peleg [Tue, 10 Sep 2013 11:54:05 +0000 (14:54 +0300)]
More readable space mask
No functional change.
homoSapiensSapiens [Mon, 9 Sep 2013 19:12:15 +0000 (22:12 +0300)]
Change condition to use relative rank
No functional change
Marco Costalba [Sun, 8 Sep 2013 13:28:53 +0000 (06:28 -0700)]
Fix some comments in position.cpp
No functional change.
Marco Costalba [Sun, 8 Sep 2013 12:49:04 +0000 (05:49 -0700)]
Move draw by material check
It is more natural to test this case among
others material distributions.
No functional change.
Marco Costalba [Sat, 7 Sep 2013 16:25:24 +0000 (18:25 +0200)]
Remove unreachable values in mobility table
The possible maximum mobility cardinality (plus one in case of
zero squares available) is:
- Knights: max. 8 squares -> max. 9 entries
- Bishops: max. 13 squares -> max. 14 entries
- Rooks: max. 14 squares -> max. 15 entries
- Queen: max. 27 squares -> max. 28 entries
So remove the extra entries in the table.
Spotted by Dariusz Orzechowski.
No functional change.
Marco Costalba [Sat, 7 Sep 2013 10:29:05 +0000 (12:29 +0200)]
Fix warning: double to float truncation
MSVC 2013 says:
warning C4305: '*=' : truncation from 'double' to 'float'
No functional change.
Lucas Braesch [Sat, 7 Sep 2013 07:32:01 +0000 (09:32 +0200)]
Singular extension at 8 plies also for PV nodes
Passed both short TC:
LLR: 2.96 (-2.94,2.94)
Total: 11451 W: 2455 L: 2282 D: 6714
And long TC
LLR: 2.96 (-2.94,2.94)
Total: 15813 W: 2907 L: 2723 D: 10183
bench:
3864419
Lucas Braesch [Sat, 7 Sep 2013 07:20:22 +0000 (09:20 +0200)]
Union of 2 changes
Union of
- LMR >= 3 plies from Gary tests.stockfishchess.org/tests/view/
522522960ebc595d328fcafd
- allows() tweak from Reuven tests.stockfishchess.org/tests/view/
5225fa1c0ebc595d328fcb53
Both passed Step I and failed Step II.
Instead this union passed both short TC:
LLR: 2.95 (-2.94,2.94)
Total: 14525 W: 3063 L: 2874 D: 8588
And long TC
LLR: 2.94 (-2.94,2.94)
Total: 31075 W: 5566 L: 5308 D: 20201
bench:
4238160
Lucas Braesch [Wed, 4 Sep 2013 23:26:05 +0000 (07:26 +0800)]
Do not prune useless checks in QS
Passed both SPRT tests in "simplification mode", so with
elo0: -3.00 alpha: 0.05 elo1: 3.00 beta: 0.05
Short TC:
LLR: 2.96 (-2.94,2.94)
Total: 6243 W: 1302 L: 1195 D: 3746
Long TC
LLR: 2.96 (-2.94,2.94)
Total: 22972 W: 4124 L: 4020 D: 14828
bench:
4633330
Marco Costalba [Thu, 5 Sep 2013 04:34:13 +0000 (06:34 +0200)]
Revert "Fix check for bishop pair in material imbalance"
Idea is sound but implementation is partial. Ryan and Joona noticed that
we leave an hole in material table. Also we got another report by an user
of an odd behaviour. Namely, if you start stockfish and from the prompt
give 'bench' you get
3453941 , then if you run again bench you get
3453940 .
The reason is that two different positions with the same number of pieces,
but one with a bishop pair and another without have the same material key.
But after Eelco patch also different material imbalance and this yields
to this issue.
Restesting at long TC shows the patch does not really contribute at
ELO improvement. Actually patch failed at long TC.
LLR: -2.97 (-2.94,2.94)
Total: 23109 W: 4104 L: 4092 D: 14913
So revert.
bench:
3453945
Reuven Peleg [Tue, 3 Sep 2013 16:05:53 +0000 (19:05 +0300)]
Rewrite backward pawn detection
Use the new backmost_sq() instead of a loop.
No functional change.
Eelco de Groot [Mon, 2 Sep 2013 20:50:32 +0000 (22:50 +0200)]
Fix check for bishop pair in material imbalance
Prefer pos.bishop_pair() to pos.count<BISHOP>(WHITE) > 1
because the first checks that the two bishops are on
different color squares.
Although the change seems to kick in only in very rare cases,
quite surprisingly it was able to pass SPRT test at short TC.
LLR: 2.95 (-2.94,2.94)
Total: 39818 W: 8174 L: 7956 D: 23688
bench:
3453941
Marco Costalba [Mon, 2 Sep 2013 09:03:01 +0000 (11:03 +0200)]
Rewrite KBBKN endgame
This was thought to be a draw but the bishops generally win. However,
it takes up to 66 moves. The position in the diagram was thought to be
a draw for over one hundred years, but tablebases show that White wins
in 45 moves. All of the long wins go through this type of semi-fortress
position. It takes several moves to force Black out of the temporary
fortress in the corner; then precise play with the bishops prevents Black
from forming the temporary fortress in another corner (Nunn 1995:265ff).
Before computer analysis, Speelman listed this position as unresolved,
but "probably a draw" (Speelman 1981:109).
bench:
3453945
Marco Costalba [Sun, 1 Sep 2013 20:37:26 +0000 (13:37 -0700)]
Don't use lpthread for Android
Thanks to Peter Osterlund for the feedback.
No functional change.
Marco Costalba [Sun, 1 Sep 2013 16:16:55 +0000 (09:16 -0700)]
Improve ARM compatibility
STANDALONE-TOOLCHAIN.html in Android NDK says:
It is recommended to use the -mthumb compiler flag to force the generation
of 16-bit Thumb-1 instructions (the default being 32-bit ARM ones).
If you want to target the 'armeabi-v7a' ABI, you will need ensure that the
following two flags are being used:
CFLAGS='-march=armv7-a -mfloat-abi=softfp'
Note: The first flag enables Thumb-2 instructions, and the second one
enables H/W FPU instructions while ensuring that floating-point
parameters are passed in core registers, which is critical for
ABI compatibility. Do *not* use these flags separately!
Thanks to Peter Osterlund for pointout this doc and for showing me
an example Makefile to follow.
No functional change.
Uri Blass [Sat, 31 Aug 2013 07:23:01 +0000 (10:23 +0300)]
Union of 2 changes that failed with good score
This is a union of 2 changes:
A tweak of recaptures limit from Joona Kiiski
http://tests.stockfishchess.org/tests/view/
52166d7c0ebc59319a242400
and a tweak of move count pruning from Leonid Pechenik
http://tests.stockfishchess.org/tests/view/
5217c7e60ebc59319a242456
The set passed both short TC at 30+0.05
LLR: 2.96 (-2.94,2.94)
Total: 18936 W: 3723 L: 3566 D: 11647
And the usual long TC at 60+0.05
LLR: 2.95 (-2.94,2.94)
Total: 48962 W: 8837 L: 8487 D: 31638
bench:
3453945
Marco Costalba [Sun, 1 Sep 2013 13:58:58 +0000 (06:58 -0700)]
Assorted clean up in endgames
No functional change.
Marco Costalba [Fri, 30 Aug 2013 14:40:11 +0000 (16:40 +0200)]
Fix a bogus assert in allows()
Becuase castle is coded as "king captures the rook"
the to_sq(move), A1/8 or H1/8 is empty after the move,
leading to assert assert(p != NO_PIECE) in color_of().
Teach allows() asserts about castle and fix the crash.
Bug reported by Ryan Takker and tracked down by Tom Vijlbrief.
No functional change.
Marco Costalba [Fri, 30 Aug 2013 05:05:25 +0000 (07:05 +0200)]
Use frontmost_sq() and backmost_sq helpers
Should easier to read than the lsb() / msb() low
level functions.
No functional change.
Gary Linscott [Thu, 29 Aug 2013 05:00:56 +0000 (01:00 -0400)]
Enable LMR for dangerous moves
Passed both short TC
LLR: 2.96 (-2.94,2.94)
Total: 5598 W: 1250 L: 1125 D: 3223
And long TC
LLR: 2.97 (-2.94,2.94)
Total: 16441 W: 3102 L: 2912 D: 10427
bench:
4620975
homoSapiensSapiens [Thu, 22 Aug 2013 14:19:58 +0000 (17:19 +0300)]
Bonus for rook behind a passed
If our rook is behind a passed pawn, all
squares are defended.
One of the longest tests to pass !
Passed both short TC
LLR: 2.97 (-2.94,2.94)
Total: 44560 W: 9518 L: 9281 D: 25761
And long TC
LLR: 2.96 (-2.94,2.94)
Total: 61348 W: 11618 L: 11192 D: 38538
bench:
3787694
homoSapiensSapiens [Thu, 29 Aug 2013 07:23:08 +0000 (10:23 +0300)]
Replace hardcoded 128 by constant
No functional change.
Gary Linscott [Wed, 28 Aug 2013 07:35:04 +0000 (09:35 +0200)]
Add lsb() overload
Helper to find least significant bit relative to
the given color.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Uri Blass [Sat, 24 Aug 2013 16:29:44 +0000 (19:29 +0300)]
Time management: move faster if PV is stable
Move faster but compensate by allocating more
time when the best move changes.
Passed short TC at 15+0.05
LLR: 2.93 (-2.94,2.94)
Total: 13895 W: 3030 L: 2882 D: 798
Long TC at 60+0.05
LLR: 2.96 (-2.94,2.94)
Total: 9266 W: 1777 L: 1624 D: 5865
At time increment 30+0.5
LLR: 2.96 (-2.94,2.94)
Total: 6703 W: 1238 L: 1134 D: 4331
And at fixed game number, longer TC 120+0.05
ELO: 5.17 +-2.8 (95%) LOS: 100.0%
Total: 19306 W: 3378 L: 3091 D: 12837
bench:
4728533
homoSapiensSapiens [Sun, 25 Aug 2013 14:59:47 +0000 (17:59 +0300)]
Simplify chain detection
No functional change.
homoSapiensSapiens [Sun, 25 Aug 2013 14:45:35 +0000 (17:45 +0300)]
Simplify kf definition in shelter_storm()
No functional change.
Chris Caino [Sat, 24 Aug 2013 08:05:48 +0000 (10:05 +0200)]
Fix KBPK bug
With
position fen 7k/8/8/8/8/7P/6K1/7B w - - 0 1
go depth 25
The evaluation at depth 22 is not draw as it should be. The reason is that
when search reaches the position 8/6kP/8/8/8/3B4/6K1/8 w - - 0 1 if white plays
h8R or h8N then we get a position that is a "KNOWN_WIN" and is _not_ a check, so
futility pruning in qsearch kicks in and black may think that it is "futile"
to reply Kxh8 since, according to the logic of the code, it cannot raise the score
back towards a draw.
bench:
4728533
homoSapiensSapiens [Thu, 22 Aug 2013 12:34:13 +0000 (15:34 +0300)]
Simplify condition for backward pawn
No functional changes.
Marco Costalba [Thu, 22 Aug 2013 11:02:20 +0000 (13:02 +0200)]
Retire redundant endgames
The case of two lone kings on the board is already considered
by the "No pawns" scaling factor rules in material.cpp as is
KBK and KNK.
Moreover we had a small leak in endgames map because for
KK endgame it happens white and black material keys are the
same (both equal to zero), so when adding the black endgame in
Endgames::add() we were overwriting the already exsisting
white one, leading to a memory leak found by Valgrind.
So remove the endgames althogheter and rely on scaling
to correctly set the endgames value to a draw.
No functional change.
Joona Kiiski [Tue, 20 Aug 2013 22:26:16 +0000 (23:26 +0100)]
Use null move when depth >= 2 plies
Passed both short TC:
LLR: 2.96 (-2.94,2.94)
Total: 23725 W: 5031 L: 4855 D: 13839
And long TC:
LLR: 2.96 (-2.94,2.94)
Total: 15730 W: 2939 L: 2754 D: 10037
bench:
4729333
Marco Costalba [Wed, 21 Aug 2013 06:40:49 +0000 (08:40 +0200)]
Restore development version
No functional change.
Marco Costalba [Tue, 20 Aug 2013 07:01:25 +0000 (09:01 +0200)]
Stockfish 4
Stockfish bench signature is:
4132374
Tom Vijlbrief [Mon, 19 Aug 2013 14:53:06 +0000 (16:53 +0200)]
Fix crash when reaching max ply
Bug introduced in
1b7223a53c419212efbd that
updated the ss base stack without increasing
the dimension.
No functional change.
Tom Vijlbrief [Mon, 19 Aug 2013 06:54:10 +0000 (08:54 +0200)]
Remove useless condition in KXK endgame
Because eval is never called when in check.
No functional change.
Leonid Pechenik [Sun, 18 Aug 2013 07:11:44 +0000 (09:11 +0200)]
Further tweak movecount pruning
Passed both short TC
LLR: 2.95 (-2.94,2.94)
Total: 15140 W: 3125 L: 2976 D: 9039
And long TC
LLR: 2.95 (-2.94,2.94)
Total: 17118 W: 3165 L: 2974 D: 10979
bench:
4132374
Marco Costalba [Sat, 17 Aug 2013 09:05:55 +0000 (11:05 +0200)]
Normalize "pawn in front of minor" patch
No functional change.
homoSapiensSapiens [Fri, 16 Aug 2013 07:57:16 +0000 (09:57 +0200)]
Use constants arguments where possible
No functional changes.
Marco Costalba [Thu, 15 Aug 2013 07:36:26 +0000 (09:36 +0200)]
Revert using exceptions
Due to crashes. It will be reapplied once
we understand what's happening.
No functional change.
homoSapiensSapiens [Wed, 14 Aug 2013 08:17:22 +0000 (11:17 +0300)]
Simplify DistanceRingsBB init
Verified by same benchmark and picking some random values.
No functional change.
homoSapiensSapiens [Wed, 14 Aug 2013 05:33:33 +0000 (08:33 +0300)]
Some renaming in TT store()
No functional change.
Marco Costalba [Wed, 14 Aug 2013 06:29:57 +0000 (08:29 +0200)]
Use exceptions to stop the search
Instead of classical flags, throw an
exception when we want to immediately halt
the search. Currently only one type
is used for both UCI stop and threads
cut off.
No functional change.
Tom Vijlbrief [Tue, 13 Aug 2013 12:19:42 +0000 (14:19 +0200)]
Bonus for a pawn in front of knight/bishop
Idea originated from a post of Don Dailey
on talkchess and reported by Eelco.
This is the last succesful attempt of a long
series of trials (as usually happens, the
'idea' alone is not enough).
Passed both short 15secs TC
LLR: 2.97 (-2.94,2.94)
Total: 7629 W: 1645 L: 1515 D: 4469
And long 60secs TC
LLR: 2.96 (-2.94,2.94)
Total: 10218 W: 1932 L: 1775 D: 6511
bench:
4944581