This is mostly a time management fix, with a few other things thrown in. Djinn's previous time management for standard time controls ('x' moves in 'y' minutes, repeating) was broken. It was especially bad when pondering was enabled. Fischer time management was OK. Anyway, I think this fixes most of those problems and it doesn't seem any weaker (it might even be a bit stronger).
03-APR-2014 (ver. 1.021)
------------------------
S o Djinn now uses the hash table score to augment the static evaluation
score. This makes the standpat score more accurate in both the
normal search and in the quiescence search.
29-MAR-2014
-----------
E o Improved the wrong-color bishop in the endgame code. Basically, if
we have a single bishop and a single A/H pawn -AND- the enemy king
is safely enscounced in the A/H corner -AND- our bishop can't give
check, (i.e. he's the wrong color) then we can't win. There is one
wrinkle though, if the enemy has a pawn on either the B/G files then
there is a chance that he could be forced to advance and lose his
pawn to our pawn, in which case the bishop could win.
B o Modified the ponder control logic to fix the time losses I (and others)
have been seeing in the traditional time control of 'x' number of
moves in 't' amount of time, repeating. Hopefully, this has killed
the many-headed Hydra. Time (pun intended) will tell.
15-FEB-2014
-----------
E o Removed the "W/BAttk_cnt" king safety variables as they were
redundant with the information conveyed in the "STable[]" attack
arrays. This simplified the logic a bit (always good) and sped
things up a bit, also always good if nothing else changes.
E o Removed squares that are protected by enemy pieces of lesser value
from the squares attacked around the enemy king logic. Essentially,
a penalty for unsafe piece attacks against the squares around the
enemy king.
E o Added a bonus for protected checks by the queen to the squares
around the enemy king.
10-FEB-2014
-----------
I o Modified/refactored the way the configuration file is read. It
is internally cleaner now on both Windows and Linux.
29-JAN-2014
-----------
B o Changed (debugged) some of the time managment routines and
algorithms for very short time controls.
24-JAN-2014
-----------
S o Fixed a bug in the search. Basically, in most calls to the qsearch
I was not starting the "ply" at 0 (note, Djinn's "ply" is other
engine's "depth"), but was instead passing in the reduction ply.
This was causing a number of problems, (for one the ply values
saved to the hash table were incorrect etc.).
S o Removed the LMR restriction that a move couldn't be reduced
if the previous ply was also reduced. This was a small elo gain.
I o Fixed a minor bug in the way the configuration file was read.
Tom Likens wrote:Improved the wrong-color bishop in the endgame code. Basically, if we have a single bishop and a single A/H pawn -AND- the enemy king is safely enscounced in the A/H corner -AND- our bishop can't give check, (i.e. he's the wrong color) then we can't win. There is one wrinkle though, if the enemy has a pawn on either the B/G files then there is a chance that he could be forced to advance and lose his pawn to our pawn, in which case the bishop could win.
Do you have an example where this exception makes a difference? The closest I can think of is this: [d]k7/8/Kp6/4B3/P7/8/8/8 b - - 0 1
White can indeed force the "a" pawn to become a "b" pawn, but it does not help because the position after the capture is a stalemate.
Tom Likens wrote:Improved the wrong-color bishop in the endgame code. Basically, if we have a single bishop and a single A/H pawn -AND- the enemy king is safely enscounced in the A/H corner -AND- our bishop can't give check, (i.e. he's the wrong color) then we can't win. There is one wrinkle though, if the enemy has a pawn on either the B/G files then there is a chance that he could be forced to advance and lose his pawn to our pawn, in which case the bishop could win.
Do you have an example where this exception makes a difference? The closest I can think of is this: [d]k7/8/Kp6/4B3/P7/8/8/8 b - - 0 1
White can indeed force the "a" pawn to become a "b" pawn, but it does not help because the position after the capture is a stalemate.
I actually had a position where this seemed to matter, which is why I modified it. I'll see if I can dig it up. Truthfully, though this can't be worth more than about 0.001 elo (if that)!
Tom Likens wrote:Improved the wrong-color bishop in the endgame code. Basically, if we have a single bishop and a single A/H pawn -AND- the enemy king is safely enscounced in the A/H corner -AND- our bishop can't give check, (i.e. he's the wrong color) then we can't win. There is one wrinkle though, if the enemy has a pawn on either the B/G files then there is a chance that he could be forced to advance and lose his pawn to our pawn, in which case the bishop could win.
Do you have an example where this exception makes a difference? The closest I can think of is this: [d]k7/8/Kp6/4B3/P7/8/8/8 b - - 0 1
White can indeed force the "a" pawn to become a "b" pawn, but it does not help because the position after the capture is a stalemate.
I actually had a position where this seemed to matter, which is why I modified it. I'll see if I can dig it up. Truthfully, though this can't be worth more than about 0.001 elo (if that)!
[d]2k5/1p6/3K4/P3B3/8/8/8/8 b - - 0 1
Ke7! winning.
Miguel
PS: Re-reading the post, this position does not qualify because the king is not in A, H.
Tom Likens wrote:Improved the wrong-color bishop in the endgame code. Basically, if we have a single bishop and a single A/H pawn -AND- the enemy king is safely enscounced in the A/H corner -AND- our bishop can't give check, (i.e. he's the wrong color) then we can't win. There is one wrinkle though, if the enemy has a pawn on either the B/G files then there is a chance that he could be forced to advance and lose his pawn to our pawn, in which case the bishop could win.
Do you have an example where this exception makes a difference? The closest I can think of is this: [d]k7/8/Kp6/4B3/P7/8/8/8 b - - 0 1
White can indeed force the "a" pawn to become a "b" pawn, but it does not help because the position after the capture is a stalemate.
I actually had a position where this seemed to matter, which is why I modified it. I'll see if I can dig it up. Truthfully, though this can't be worth more than about 0.001 elo (if that)!
[d]2k5/1p6/3K4/P3B3/8/8/8/8 b - - 0 1
Ke7! winning.
Miguel
PS: Re-reading the post, this position does not qualify because the king is not in A, H.
I cannot think of an exception if the king is in A8. If the king is not there, there are chances. For instance
Tom Likens wrote:Improved the wrong-color bishop in the endgame code. Basically, if we have a single bishop and a single A/H pawn -AND- the enemy king is safely enscounced in the A/H corner -AND- our bishop can't give check, (i.e. he's the wrong color) then we can't win. There is one wrinkle though, if the enemy has a pawn on either the B/G files then there is a chance that he could be forced to advance and lose his pawn to our pawn, in which case the bishop could win.
Do you have an example where this exception makes a difference? The closest I can think of is this: [d]k7/8/Kp6/4B3/P7/8/8/8 b - - 0 1
White can indeed force the "a" pawn to become a "b" pawn, but it does not help because the position after the capture is a stalemate.
I actually had a position where this seemed to matter, which is why I modified it. I'll see if I can dig it up. Truthfully, though this can't be worth more than about 0.001 elo (if that)!
[d]2k5/1p6/3K4/P3B3/8/8/8/8 b - - 0 1
Ke7! winning.
Miguel
PS: Re-reading the post, this position does not qualify because the king is not in A, H.
I cannot think of an exception if the king is in A8. If the king is not there, there are chances. For instance
[d]8/2K5/kB6/1p6/8/P7/8/8 b - - 0 1
Miguel
This is likely the case. Djinn has code to check that the king is either in the corner or that it can safely reach the corner. So my original post was somewhat, unintentionally misleading. I do remember, before I added this, that there were positions that Djinn thought were draws that were actually losses.
Tom Likens wrote:
This is likely the case. Djinn has code to check that the king is either in the corner or that it can safely reach the corner. So my original post was somewhat, unintentionally misleading. I do remember, before I added this, that there were positions that Djinn thought were draws that were actually losses.
Actually, thinking about this a bit more, it's very likely that I've over constrained this so that I'm now flagging positions that are draws as losses. Hmmm...
