There were two asserts.
The first was raised because is_ok() was called at the
beginning of do_castle_move() and this is wrong after
the last code reformatting because at that point the state
is already modified by the caller do_move().
The second, raised by debugIncrementalEval, was due to a
rounding error in compute_value() that occurs because
TempoValueEndgame was updated in an odd number by patch
"Merge Joona Kiiski evaluation tweaks" (3ed603cd) of 13/3/2009
This line in compute_value() is the guilty one:
result += (side_to_move() == WHITE)? TempoValue / 2 : -TempoValue / 2;
The fix is to increment TempoValueEndgame so to be even.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Unfortunatly this tweak does not give good results.
After 894 games at 1+0 we have:
Mod vs Orig +205/-236/=453 48.27% -12 ELO !!
Perhaps we should test again, but in the mean time
we are going to revert this.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This is the backport of tuned piece values.
We needed to change also the psqt tables so that their
values, that are relative to piece values, remain the same.
Amost no change after 999 games:
Mod vs Orig 594-495 + 2 ELO points so well within error bar
It was expected somehow given the very little change of the
parameters values.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
This also allow us to better track what is already
optimized and what still needs optimization.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of just drop evaluation score after stand pat
logic save it in TT so to be reused if the same position
occurs again.
Note that we NEVER use the cached value apart to avoid an
evaluation call, in particulary we never return to caller
after a succesful tt hit.
To accomodate this a new value type VALUE_TYPE_EVAL has been
introduced so that ok_to_use_TT() always returns false.
With this patch we cut about 15% of total evaluation calls.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
