Djinn 1.021

[Tom Likens]

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).

http://webpages.charter.net/tlikens/index.html

From the changes log file,

Code: Select all

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.
 

enjoy,
--tom

[SzG]

Thank you, Tom.

[petero2]

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]

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)!

[michiguel]

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.

[michiguel]

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

[Tom Likens]

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

[Graham Banks]

Thanks Tom.

[Tom Likens]

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...

[Tom Likens]

Thanks Tom.

Hey Graham, I know I was going to leave it alone for while, but

• 1. It's addictive
  2. I *really* hate bugs.

regards,
--tom