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.
Use a Weights[] array instead of named variables to
store evaluation weights.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Because exit_threads() references the global object TM, we
need to call the function when still inside main(), otherwise,
due to undefined global object initialization and destruction
we could end up with referencing an already destroyed object.
Actually this should not happen because Application singleton
is initialized _only_ after all the other globals due to how
Application::initialize() is defined, but this is very tricky
C++ and not easy to follow, even for me ;-)
Also rearranged a bit main() code flow.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Moved evaluation of unstoppable pawns out of
evauation of passed pawns because event frequency is
much lower. Added evaluate_unstoppable_pawns() that
is called very seldom and contains all the unstoppable
pawn logic.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
The idea is to reduce the score if we have many
pawns opposing an enemy pawn so that the draw
possibility increases.
Just introduced the logic, but no functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This is the world's fussiest compiler with +w1
Warnings reported by Richard Lloyd.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
No change in functionality signature
The only functional change is that when we reach PLY_MAX,
we now return VALUE_DRAW instead of evaluating position.
But we reach PLY_MAX only when position is dead drawn and
transposition table is filled with draw scores, so this
shouldn't matter at all.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Game phase is a strictly function of the material
combination so its natural place is MaterialInfo,
not position.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Move the code to the caller and also move mob_area
computation out of evaluate_pieces(). It is more clear
the code flow and it is also faster.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
