Currently are used by evaluation itself and the
whole EvalInfo will be removed from global visibility
by next patch, so no reason to use them.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It will be more clear when we will go to add stuff
apart from king danger itself.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
First accumulate the bonus for each pawn, then call the
not very fast apply_weight().
Should be no functional change apart from rounding issues.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Set manually to zero the few fields that are
optionally populated and that's enough.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Avoid one address lookup in a very critical time path.
Unified also outpost bonus tables for knights and bishops.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Another 100 lines of dubious and ad-hoc code.
After 7644 games on russian cluster:
Mod - Orig 1285 - 1249 - 5110 ELO +1 (+- 3.2)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Plus a bunch of other minor optimizations.
With this power pack we have an increase
of a whopping 1.4% :-)
...and it took 3 good hours of profiling + hacking to get it out !
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
One hundred lines of code should be compensated by an
important ELO increase, otherwise are candidate for removal...
...and is not the case. We are well within error margin, so
remove the code even if we lose a couple of elo points, but
semplification is huge.
After 6494 games on russian cluster
Orig vs Mod 1145 - 1107 - 4242 (-2 ELO)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
The one in evaluate_passed_pawns() is just a micro
optimization, the other in evaluate_unstoppable_pawns()
is indeed a fix, although almost unmeasurable in real
games.
Bugs report and fixes by Marek Kwiatkowski
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We don't need to pass side_to_move because we can get
it directly from the position object.
Note that in benchmark we always used to pass '0' and
it was a bug, but with no effect because was used only
in time[] and increment[], set always to 0 for both
colors.
Also additional small cleanup while there.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It happens that when d == 0 we calculate:
log(double(0 * 0) / 2)
Unfortunately, log(0) is "illegal" and can generate either a
floating point exception or return a nonsense "huge" value
depending on the platform.
This fixs in the proper way the GCC/ICC rounding difference,
bug was from our side, not in the intel compiler.
Also fixed some few other warnings.
Bug spotted by Richard Lloyd.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
When first condition is met then second one is
always true.
Spotted by Ralph Stoesser.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Due to rounding errors in apply_weight() where we divide
by 0x100 it is not possible to keep some functionality.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
A pawn is unstoppable also if enemy king can reach it
but path to queening is protected.
Original idea by Ralph Stoesser fixed by me.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Get it from the position instead.
A good semplification of function calling and a speedup too.
No functional change also with faked split.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
After 999 games at 1+0
Mod vs Orig +148 =712 -139 +3 ELO
The added complexity doesn't seems to pay off and could
even scale worst with longer TC. So revert.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
The tested square comes from a bitboard anded with
pos.pieces_of_color(Us), so assert is useless.
Another nitpick report by Marek Kwiatkowski ;-)
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
One of the most nitpicking patches I have ever seen.
Of course almost no functional change, but added just
becasue we are very pedantic ;-)
Spotted by Marek Kwiatkowski
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Increase threats score according to the number of
threats and to the side to move.
Constants have been balanced after ~34k iterations.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We already tested few lines before with:
assert(pos.pawn_is_passed(Us, s));
Spotted by Marek Kwiatkowski.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Does not help and it slows downs a bit because it
is not cheap to get the possible discovered checks
out of a position.
After 997 games at 1+0
Mod vs orig +153 =692 -152 +0 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
There is no reason for that since tr cannot become negative.
Spotted by Ralph Stoesser.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Final values for threath tuning (after ~30k iterations)
Verified to be equivalent with tuning branch.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Pass the color for which the square is to be
considered weak, not the opposite.
It is more natural and intuitive in this way.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Remove a lot of complex, obscure and useless code.
After 999 games at 1+0
Mod vs Orig +162 =673 -164 -1 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This is what actually is.
A standard naming convention suggests to name a variable
with someting resembling _what_ the variable is and not
_how_ the variable is used. This normally results
in easier to read code.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
A bigger "safety" value is actually a bigger
threat for the king, so it is a bigger "danger"
With this renaming "Cowardice" and "Aggressiveness"
UCI parameters become easier to understand.
It is also easier to understand why the once "safety"
value (that is a "danger") is subtracted from evaluation
instead of being added.
No functional change.
