After 999 games we are almost equal (+2 ELO),
but we have a good result against Rybka
Rybka 2.3.2a mp 32-bit vs Mod 254.5 - 242.5 +152/-140/=205 51.21%
Rybka 2.3.2a mp 32-bit vs Orig 259.5 - 236.5 +151/-128/=217 52.32%
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Now we always try to filter out moves, we will have
more wasted evaluation calls, but also more pruned
nodes.
After 786 games
Mod vs Orig +196 =413 -177 +8 ELO
Verified also against Rybka it increases score to 50-51%
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We might be asked to ponder mate or stalemate position.
This being the case, simply wait for stop or ponderhit.
Currently we crash.
UCI specs aren't clear on the issue, but it cost nothing to
add little check.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Problem is that
istream& operator>> (istream& is, char* str );
according to C++ documentation "Ends extraction when the
next character is either a valid whitespace or a null character,
or if the End-Of-File is reached."
So if the parameter value is a string with spaces the currently
used instruction 'ss >> ret;' copies the chars only up to the first
white space and not the whole string.
Use a specialization of get_option_value() to fix this corner case.
Bug reported by xiaozhi
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Now we use a formula to calculate margins on the fly.
Node count has changed because we fixed a leftover when
we still where using FutilityMargins to calculate futilityValue
in the case that we had the evaluation score in TT.
Also small indentation fix.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Increase pruning at low depths while tone downa bit at
higher depths (linearize a bit the logaritmic behaviour)
This goes togheter with IncrementalFutilityMargin decreased
to 4 compensate the bigger pruning effect.
Total pruned nodes are more or less the same. We go from 36%
of nodes after prune to 37% with this patch.
After 999 games at 1+0
Mod vs Orig +250 =526 -223 +9 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
If we arrive until the exclusion search call then
we know that move == ttMove == tte->move()
But using ttMove in search call while, during excluded search
conditions we have used tte->Move()could be a little bit suboptimal.
On the other side using tte->move() also in search call is a bit ugly
so opt for the third choice that is the most clean becasue from the
conditions the reader easily understands that we are talking of ttMove
and that we ant to exclude the move we are evaluating in that moment.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
If tte->move() != MOVE_NONE then tte->move() == ttMove
What could happen is that we have a ttMove without a tte, or,
we have a tte but tte->move() == MOVE_NONE
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Due to IID we could have a ttMove and not a tte, or,
even if we have a tte they could belong to different
searches so that the depth and type of tte don't
have the same origin of the ttMove.
To fix this we always use tte entry in excluded search
condition and, after an IID, we reprobe the TT table.
No functional change. Apart from possible crash fix.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
They gave bad results:
Mod - Orig: 361 - 404
Master is now verified to be functional equivalent with F_63
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Becasue we have a lot of zero scores (around 30% of moves)
it is a good idea to do a couple a presorting loops across
the move list and shuffle the moves a bit so that with a
small effort we end up with 3 groups of moves: positives
scores, zero scores and negative scores.
We have two advantages
1) We don't need to sort zero scores
2) Sort two small groups is faster then sort a single big one
Speed up is of about 2%
Because equal scored moves could be reordered in a different way
this is not a "no functional change" although I have verified
the output list is always correctly sorted.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We already reset loseOnTime flag at the beginning of
a new game, so we can simplify a bit the ligic there.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
* New version is documented and logic should be easier to follow
* Add extra check to not use LSN with x moves / y seconds time control
* New code fixes some rear cases where old code (still) causes program to lose on time at move 1.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
* The function is called only in one place
* It must not be called elsewhere
* The function call easily replaced with simple one line condition
No functional change (tested with usual set + 2000 random positions)
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
* First one is without any documentation, code is working just fine,
so there seems to be nothing that really should be fixed.
* Second one requesting emergency measures on aspiration fail low
when we are running out of time and we are without good move.
After very long time, I've come to conclusion that this is
impossible to fix, so remove request.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use an exponenital law instead of a linear one for
history pruning.
This should prune more at low depths and a bit less
at high depths.
After 965 games
Mod vs Orig +233 =504 -228 +2 ELO
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Correct beta by razor margin when callin qsearch
After 1019 games on Joona's QUAD
Mod - Orig: 524 - 495 (+10 elo)
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>
Call directly 'perft 6' to search up to depth 6*OnePly
instead of the old 'perft depth 6'.
It is more in line to what other engines do. Also a bit
of cleanup while there.
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>
When false (common case) we avoid to update checkers
bitboard that although not so costly slows down a bit
this very hot and critical path.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Avoid a 64 bit load using a pointer. It saves a couple of push/pop
instructions so advantage is only theorical, but anyway we use
pop_1st_bit() as a reference implementation for 32 bit systems so
we keep it more for documentation purposes then for other reasons.
Idea of pointer is of Eric Mullins.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
