1
0
Fork 0
mirror of https://github.com/sockspls/badfish synced 2025-05-01 17:19:36 +00:00
Commit graph

150 commits

Author SHA1 Message Date
protonspring
fc3af7c4fb Optimize an expression in endgame.cpp
I believe using foward_file_bb() here is fewer instructions.

a) Fewer instructions and probably more clear (debatable).
b) Possible that a lookup is slower than a few local operations, but the
   forward_file_bb table is probably used often enough that it is always
   cached.

Passed
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 21004 W: 4263 L: 4141 D: 12600
http://tests.stockfishchess.org/tests/view/5b1cad830ebc5902ab9c6239

Closes https://github.com/official-stockfish/Stockfish/pull/1644

No functional change.
2018-06-11 10:22:55 +02:00
Stéphane Nicolet
d9cac9a414 Simplify KBPKB endgame with opposite bishops
When we reach a position with only two opposite colored bishops and
one pawn on the board, current master would give it a scale factor
of 9/64=0.14 in about one position out of 7200, and a scale factor
of 0.0 in the 7199 others. The patch gives a scale factor of 0.0 in
100% of the cases.

STC:
LLR: 2.96 (-2.94,2.94) [-3.00,1.00]
Total: 55845 W: 11467 L: 11410 D: 32968
http://tests.stockfishchess.org/tests/view/5abc585f0ebc5902926cf15e

LTC:
LLR: 2.95 (-2.94,2.94) [-3.00,1.00]
Total: 11915 W: 1852 L: 1719 D: 8344
http://tests.stockfishchess.org/tests/view/5abc7f750ebc5902926cf18c

We also have exhaustive coverage analysis of this patch effect by
Alain Savard, comparing the perfect evaluation given by the Syzygy
tablebase with the heuristic play after this patch for the set of
all legal positions of the KBPKP endgame with opposite bishops, in
the comments thread for this pull request:
https://github.com/official-stockfish/Stockfish/pull/1520

Alain's conclusion:
> According to this definition and the data, I consider this PR is
> identical to master to "solve for draw" and slightly better than
> master to solve earlier for "wins".

Note: this patch is a side effect of an ongoing effort to improve
the evaluation of positions involving a pair of opposite bishops.
See the GitHub diff of this LTC test which almost passed at sprt[0..5]
for a discussion:
http://tests.stockfishchess.org/tests/view/5ab9030b0ebc5902932cbf93

No functional change (at small bench depths)
2018-04-01 02:19:42 +02:00
Ronald de Man
759b3c79cf Mark all compile-time constants as constexpr.
To more clearly distinguish them from "const" local variables, this patch
defines compile-time local constants as constexpr. This is consistent with
the definition of PvNode as constexpr in search() and qsearch(). It also
makes the code more robust, since the compiler will now check that those
constants are indeed compile-time constants.

We can go even one step further and define all the evaluation and search
compile-time constants as constexpr.

In generate_castling() I replaced "K" with "step", since K was incorrectly
capitalised (in the Chess960 case).

In timeman.cpp I had to make the non-local constants MaxRatio and StealRatio
constepxr, since otherwise gcc would complain when calculating TMaxRatio and
TStealRatio. (Strangely, I did not have to make Is64Bit constexpr even though
it is used in ucioption.cpp in the calculation of constexpr MaxHashMB.)

I have renamed PieceCount to pieceCount in material.h, since the values of
the array are not compile-time constants.

Some compile-time constants in tbprobe.cpp were overlooked. Sides and MaxFile
are not compile-time constants, so were renamed to sides and maxFile.

Non-functional change.
2018-03-18 23:48:16 +01:00
Joost VandeVondele
9afa1d7330 New Year 2018
Adjust copyright headers.

No functional change.
2018-01-01 13:18:10 +01:00
syzygy1
822695d4d3 Use a Direction enum for Square deltas
Currently the NORTH/WEST/SOUTH/EAST values are of type Square, but conceptually they are not squares but directions. This patch separates these values into a Direction enum and overloads addition and subtraction to allow adding a Square to a Direction (to get a new Square).

I have also slightly trimmed the possible overloadings to improve type safety. For example, it would normally not make sense to add a Color to a Color or a Piece to a Piece, or to multiply or divide them by an integer. It would also normally not make sense to add a Square to a Square.

This is a non-functional change.
2017-12-04 17:52:31 +01:00
tthsqe12
5837228aa0 Fix the handling of opposite bishops in KXK endgame evaluation
The case of three or more bishops against a long king must look at all of the
bishops and not just the first two in the piece lists. This patch makes sure
that the position is treated as a win when there are bishops on opposite
colors. This functional change is very small because bench remains the same.

LLR: 2.95 (-2.94,2.94) [-4.00,0.00]
Total: 24249 W: 4349 L: 4275 D: 15625
http://tests.stockfishchess.org/tests/view/598186530ebc5916ff64a218

Bench: 5608839
2017-08-12 02:47:11 -07:00
Alain SAVARD
6d24ef8585 Tidy up
No functional change

Closes #1148
2017-07-02 21:53:45 -07:00
Marco Costalba
27ba611a3d Better naming in endgame code
And small clean-up of magic bitboards code.

No functional change.

Closes #1138
2017-06-16 19:33:44 -07:00
Marco Costalba
b48439e906 Assorted code style issues
I have removed the check for

 pieceCount[PAWN] > FILE_NB

because totally useless.

No functional change.
2017-04-24 09:49:44 +02:00
Joost VandeVondele
d8f683760c Adjust copyright headers to 2017 (#965)
No functional change.
2017-01-11 08:46:29 +01:00
Miroslav Fontán
445aade39c Simplify code, delete else after return 2016-11-05 08:08:25 +01:00
Marco Costalba
c0bb041539 Rewrite syzygy in C++
Rewrite the code in SF style, simplify and
document it.

Code is now much clear and bug free (no mem-leaks and
other small issues) and is also smaller (more than
600 lines of code removed).

All the code has been rewritten but root_probe() and
root_probe_wdl() that are completely misplaced and should
be retired altogheter. For now just leave them in the
original version.

Code is fully and deeply tested for equivalency both in
functionality and in speed with hundreds of games and
test positions and is guaranteed to be 100% equivalent
to the original.

Tested with tb_dbg branch for functional equivalency on
more than 12M positions.

stockfish.exe bench 128 1 16 syzygy.epd

Position: 2016/2016
Total 12121156 Hits 0 hit rate (%) 0
Total time (ms) : 4417851
Nodes searched : 1100151204
Nodes/second : 249024

Tested with 5,000 games match against master, 1 Thread,
128 MB Hash each, tc 40+0.4, which is almost equivalent
to LTC in Fishtest on this machine. 3-, 4- and 5-men syzygy
bases on SSD, 12-moves opening book to emphasize mid- and endgame.

Score of SF-SyzygyC++ vs SF-Master: 633 - 617 - 3750  [0.502] 5000
ELO difference: 1

No functional change.
2016-11-05 07:55:08 +01:00
Stéphane Nicolet
7ae3c05795 Rename shift_bb() to shift()
Rename shift_bb() to shift(), and DELTA_S to SOUTH, etc.
to improve code readability, especially in evaluate.cpp
when they are used together:

    old b = shift_bb<DELTA_S>(pos.pieces(PAWN))
    new b = shift<SOUTH>(pos.pieces(PAWN))

While there fix some small code style issues.

No functional change.
2016-09-25 10:45:10 +02:00
Marco Costalba
7eaea3848c StateInfo is usually allocated on the stack by search()
And passed in do_move(), this ensures maximum efficiency and
speed and at the same time unlimited move numbers.

The draw back is that to handle Position init we need to
reserve a StateInfo inside Position itself and use at
init time and when copying from another Position.

After lazy SMP we don't need anymore this gimmick and we can
get rid of this special case and always pass an external
StateInfo to Position object.

Also rewritten and simplified Position constructors.

Verified it does not regress with a 3 threads SMP test:
ELO: -0.00 +-12.7 (95%) LOS: 50.0%
Total: 1000 W: 173 L: 173 D: 654

No functional change.
2016-04-17 08:29:33 +02:00
mstembera
8fb45caade Simplify popcnt
Also a speedup(about 1%) on 64-bit w/o hardware popcnt

Retire Max15 and Full template parameters
(Contributed by Marco Costalba)

Now that we have just SW and HW versions, use
template default parameter to get rid of explicit
template parameters.

Retire bitcount.h and move the only defined
function to bitboard.h

No functional change

Resolves #620
2016-04-08 18:52:15 +01:00
ppigazzini
d4af15f682 Update AUTHORS and copyright notice
No functional change

Resolves #555
2016-01-02 09:43:51 +00:00
Marco Costalba
9742fb10fd Update Copyright year
No functional change.

Resolves #554
2016-01-01 10:17:36 +00:00
Alain SAVARD
6a79d5d10e Correct Pawn Trace Score + Code Clean up
No functional change

Resolves #542
2015-12-30 11:30:28 +00:00
Marco Costalba
3e4fed3a91 Fix assert with very high score position
In case of a very high material score, we can
overflow VALUE_INFINITE.

This patch fixes an assert with:

position fen 7k/QQQQR3/2B5/4KN1Q/3QQ3/8/8/4R3 b - - 0 1
go depth 1

No functional change.

Resolves #546
2015-12-30 11:16:48 +00:00
Marco Costalba
86f04dbcc0 Assorted trivia in search.cpp
The only interesting change is the moving of
stack[MAX_PLY+4] back to its original position
in id_loop (now renamed Thread::search).

No functional change.
2015-10-31 19:26:35 +01:00
Stefano80
3428a28751 KRPPKRP endgame: Simplify ugly switch statement
No functional change

Resolves #470
2015-10-24 23:17:08 +01:00
Stefano80
436c303731 Tuning of assorted values
Passed STC

LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 45401 W: 8590 L: 8274 D: 28537

Passed LTC

LLR: 2.96 (-2.94,2.94) [0.00,4.00]
Total: 36089 W: 5589 L: 5331 D: 25169

Bench: 8397672

Resolves #445
2015-10-05 19:49:52 -07:00
Marco Costalba
e6310b3469 Rename Position::list
Use Position::square and Position::squares instead.

This allow us to remove king_square(), simplify
endgames and to have more naming uniformity.

Moreover, this is a prerequisite step in case
in the future we decide to retire piece lists
altoghter and use pop_lsb() to loop across
pieces and serialize the moves. In this way
we just need to change definition of Position::square
to something like:

template<PieceType Pt> inline
Square Position::square(Color c) const {
  return lsb(byColorBB[c]);
}

No functional change.
2015-08-04 09:51:06 +02:00
joergoster
3054db989d Use distance<file>() function in endgame.cpp
This one occurance of distance function was most likely overlooked.

No functional change.

Resolves #376
2015-07-12 20:48:50 +01:00
Marco Costalba
36f8814aa6 Rearrange Endgames
Remove references to EndgameBase and use instead
Value and ScaleFactor as template parameters of
the endgames maps.

No functional change.
2015-01-21 17:35:53 +01:00
Marco Costalba
3c07603dac Import C++11 branch
Import C++11 branch from:

https://github.com/mcostalba/Stockfish/tree/c++11

The version imported is teh last one as of today:
6670e93e50

Branch is fully equivalent with master but syzygy
tablebases that are missing (but will be added with
next commit).

bench: 8080602
2015-01-18 08:00:50 +01:00
Marco Costalba
42b48b08e8 Update copyright year
No functional change.
2015-01-10 11:46:28 +01:00
Marco Costalba
aea2fde611 Assorted formatting and comment tweaks in position.h
No functional change.
2015-01-07 09:09:41 +01:00
Marco Costalba
3fda064a66 Retire one implementation of pop_lsb()
We have two implementations that are equivalent,
so retire one.

Plus usual tidy up of comments and code reshuffle.

No functional change.
2015-01-03 22:16:30 +01:00
hxim
fbb53524ef Rename some variables for more clarity.
No functional change.

Resolves #131
2014-12-08 07:53:33 +08:00
Marco Costalba
6fb0a1bc40 Introduce distance() and unify some API
Original work by Lucas.

No functional change.
2014-11-09 10:27:04 +01:00
lucasart
d12378497c Do not assume that enum are signed
Clang 3.5 issues warning on constructs like: abs(f1 - f2). The thing is that
f1 and f2 are enum types, and the range given (all positive) allows the
compiler to choose an unsigned type (efficiency being one reason to prefer
unsigned arithmetic). If f1 < f2 are unsigned, then f1 - f2 wraps around zero
and the abs() becomes a no-op. It's the reinterpretation of the unsigned
result (large value) as a signed int that happens to give the correct result,
thanks to 2's complement. This is all tricky and dangerous!

In the spirit of the standard, we assume nothing on the signedness of enums,
and simply calculate the rank and file distances as:
- rank_dist(r1, r2) = r1 < r2 ? r2 - r1 : r1 - r2
- file_dist(f1, f2) = f1 < f2 ? f2 - f1 : f1 - f2
this logic can in fact be applied to any enum we may use, so for better
generality and to avoid code duplication, we use a template function diff()
here.

No functional change.

Resolves #95
2014-11-04 00:35:02 +08:00
Marco Costalba
f1240483fb Revert back KBPsK to latest Gary's version
The bug was found to be elsewhere. This version
is correct and also is able to detect as draw
positions like:

8/8/5b2/8/8/4k1p1/6P1/5K2 b - - 6 133

bench: 8678654
2014-05-04 09:34:22 +02:00
Ronald de Man
c0d3010438 Fix KXK endgame
Position is win also if strong side has a bishop
and a knight (plus other material, otherwise
KBNK would be triggered instead of KXK).

This fixes a subtle bug where a search on position

k7/8/8/8/8/P7/PB6/K7 b - - 6 1

Instead of returning a draw score, suddendly returns
a big score. This happens because at one point in
search we reach this position:

8/Pk6/8/8/8/4B3/P7/K7 w - - 3 8

Where white can promote. In case of rook promotion (and also in case of
queen promotion) the resutling position gets a huge static eval that is
above VALUE_KNOWN_WIN (from the point of view of white). So for rook
promotion it is

          &&  futilityBase > -VALUE_KNOWN_WIN

that prevents futility pruning in qsearch. (Removing this condition indeed
lets the problem occur). Raising the static eval for K+B+N+X v K to a value
higher than VALUE_KNOWN_WIN fixes this particular problem without having to
introduce an extra futility pruning condition in qsearch.

I just checked and it seems K+R v K, K+2B v K and even K+B+N v K already get
a huge static eval. Why not K+B+N+P v K?

I think this fix corrects an oversight. There is special code for KBNK, but
KBNXK is handled by KXK, so the test for sufficient material should also test
for B+N.

bench: 8678654
2014-05-03 21:40:09 +02:00
Marco Costalba
dc87ec7258 Revert to Galurung's KBPsK endgame
After reverting to the original Tord's
endgame, a search on position

7k/6p1/6B1/5K1P/8/8/8/8 w - - 0 1

Reports, correctly, a draw score instead of
an advantage for white.

Issue reported by Uri Blass.

bench: 8678654
2014-05-02 11:04:18 +02:00
Marco Costalba
c9e396b542 We can add an integer to a Value
We have defined corresponding operators,
so rely on them to streamline the code
and increase readibility.

No functional change.
2014-04-27 11:25:42 +02:00
Marco Costalba
5f12069cbf Retire operator|(File f, Rank r)
Use make_square() instead. Less fancy but
more clear.

No functional change.
2014-03-22 23:54:18 +01:00
Marco Costalba
d0587f2c7f Use legal positions for endgame initialization
During endgame initialization we get the material
hash key of each endgame forging and ad-hoc position
that in same cases is illegal (leaves teh king under
capture). This is not a problem for the material key,
but rises an assert when SF is run in debug mode with
'testKingCapture' set in pos_is_ok().

So rewrite the code to always produce legal positions.

No functional change.
2014-03-14 09:57:34 +01:00
Chris Cain
df201175c6 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
2014-01-18 17:22:54 +01:00
Marco Costalba
3d58092ec1 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
2014-01-12 22:32:41 +01:00
Marco Costalba
a646f74e6a Assorted grammar fixes
Mainly from Lyudmil Antonov and
one from Henri Wiechers and Louis Zulli.

No functional change.
2014-01-07 14:30:41 +09:00
Marco Costalba
c9dcda6ac4 Update copyright year
No functional change.
2014-01-02 01:49:18 +01:00
Arjun Temurnikar
431c3ac485 Even more spelling fixes
No functional change.
2013-12-06 09:03:24 +01:00
Richard Lloyd
13a73f67c0 Big assorted spelling fixes
No functional change.
2013-12-02 20:29:35 +01:00
Marco Costalba
48f38f3092 Retire mirror()
Inline the only caller site.

No functional change.
2013-10-24 20:40:26 +02:00
Marco Costalba
67b0da83da Further smplify pawn endgames
Dumb down a bit the code and trade some possible
speed (but this is far from hot path anyhow) for
some added readability for the layman.

No functional change.
2013-10-23 19:56:35 +02:00
Chris Caino
3674f18b97 Use flip_sq idea in endgame.cpp
The normalising transformation is computed all at
once by the helper function get_flip_sq and then
applied immediately to the relevant squares as soon
as they are loaded from the position class.

bench: 8350690
2013-10-23 16:00:49 +02:00
Chris Caino
3cddb0c076 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
2013-10-15 07:36:01 +02:00
Chris Caino
2bf18bfc63 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>
2013-10-15 07:34:29 +02:00
Chris Caino
0c68971c13 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
2013-10-14 19:55:07 +02:00