Djinn 1.006

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

Tom Likens
Posts: 303
Joined: Sat Apr 28, 2012 6:18 pm
Location: Austin, TX

Djinn 1.006

Post by Tom Likens »

Djinn 1.006 is now available at:

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

Don't make to much out of the transition to 1.xxx, since the numbering for Djinn is a little odd. Basically, I use the changes in the history file to set the version number (I have a python script that parses it). So the transition to 1.xxx basically means I need to go outside more!

As with 0.992 this is mainly a bug fix with a small strength increase (approx. 20 elo I would estiimate from my testing). Here are the changes since the last version was released:

Code: Select all

17-DEC-2013 (ver. 1.006)
 ------------------------
 E  o Modified the way the penalty/bonus for a Queen vs. 2 Rooks trade
      was being scored.  I also ran this under CLOP to get optimal (or
      at least not "sub-optimal") scaling values.

 16-DEC-2013
 -----------
 E  o I changed the way the pawns were being scored in front of the king.
      Previously, the pawns occupying the six squares in front of the 
      king's actual location were used to access a "Shelter[64]" array.  
      But using the king's actual position would occasionally cause the 
      program to move the king forward (in an unsafe manner) so that it 
      would be closer to any kingside pawns that had advanced.  Now the 
      program now uses the canonical kingside square, (either G1/G8 or 
      C1/C8).  This seems to result in less unsafe king forays.   

 07-DEC-2013
 -----------
 S  o Removed the "Botvinnik-Markoff" extension.  Extensive testing
      showed no real elo gain from it and removing it simplifies the code.
 E  o Clopped the rook mobility tables.

 04-DEC-2013
 -----------
 E  o Added safe king mobility to the evaluation function.  For some odd 
      reason this was left out when I added the mobility for all the
      other pieces to the evaluation function.  Clopped both the penalty
      and mobility multiplier portions.

 20-NOV-2013
 -----------
 S  o Changed the criteria for beta pruning, so that it is only applied
      if the hash move is empty.  It's also skipped if either alpha or 
      beta is a mate score, (worth about 5 elo).
 B  o Potential bug fix for the Windows version.  I realized that the
      "unsigned long" type on Windows is only 4 bytes, (under Linux it's
      8 bytes).  It's possible that some of my time management and node
      counting variables were under/overflowing.  So rather than worry
      about it I simply changed everything to "unsigned long long" 
      which is 8 bytes on both operating systems.

 17-NOV-2013
 -----------
 I  o Dusted off Andrei Fortuna's "Chant" utility and started making 
      modifications to both Djinn and the Chant viewer (Andrei was kind 
      enough to give me the source code) so that more information is 
      shown.  I'm also planning to speed up the loading of the database
      file so that the viewing of large files isn't so slow.

 13-NOV-2013
 -----------
 O  o Micro-Optimized to the swapoff routine that separates winning,
      even and losing captures. Since the captures are generated in
      MVV/LVA order and stable sorted, we don't need the full SEE score.  
      Instead, we only need to know if the SEE score is >= 0.  This is
      always satisfied if the piece capturing is of lesser or equal
      value to the piece being captured.  If that is true we skip the
      (relatively) expensive call to the full swapoff routine.

 05-NOV-2013
 -----------
 B  o Found a minor bug in the "toolbox::convert_string_to_double()"
      function which could actually cause an interface crash if the
      input was pathological.

 03-NOV-2013
 -----------
 B  o While going over the evaluation routines, I ran across a bug.
      Basically, the king attacks were being left out of the attack 
      bitmaps if the endgame evaluation function exited early,
      (specifically, if it was a king/pawn-only endgame).  Probably, 
      not a big elo hit, but certainly not the intent.
 E  o Added a new function that calculates the attack bitmaps from
      scratch.  This is a useful debug routine.  This is now used to
      restrict the definition of "safe" squares that the queen and
      rook can move to (i.e. their mobility).

 27-OCT-2013
 -----------
 B  o Fixed a memory overrun bug found by Valgrind in the hash routines. 
      It was possible for the slot pointers to read or write past the 
      end of the allocated memory if the initial hash value into the 
      table was the last (or 2nd to last) slot.
 B  o Fixed a buffer underflow read into "ThreatMove" array (found by
      the LLVM Clang compiler using the '-fsanitize=address' option).
regards,
--tom
tmokonen
Posts: 1296
Joined: Sun Mar 12, 2006 6:46 pm
Location: Kelowna
Full name: Tony Mokonen

Re: Djinn 1.006

Post by tmokonen »

Thank you for the Christmas present, Tom.
User avatar
Rebel
Posts: 6991
Joined: Thu Aug 18, 2011 12:04 pm

Re: Djinn 1.006

Post by Rebel »

Tom Likens wrote: 20-NOV-2013
-----------
S o Changed the criteria for beta pruning, so that it is only applied if the hash move is empty. It's also skipped if either alpha or beta is a mate score, (worth about 5 elo).
Congrats with the new version.

Question, what's beta pruning?

From what you describe it doesn't fit with normal A/B pruning.
Tom Likens
Posts: 303
Joined: Sat Apr 28, 2012 6:18 pm
Location: Austin, TX

Re: Djinn 1.006

Post by Tom Likens »

SzG wrote:Tom, is the 64-bit version intended for SSE4.2 capable processors only? It crashes on my Q6600 which it never did before.
Yes. Let me upload the 64-bit non-popcnt version. I wasn't sure if anyone was using it or not.
Now I know, :wink: (sorry for the confusion).
Tom Likens
Posts: 303
Joined: Sat Apr 28, 2012 6:18 pm
Location: Austin, TX

Re: Djinn 1.006

Post by Tom Likens »

Tom Likens wrote:
SzG wrote:Tom, is the 64-bit version intended for SSE4.2 capable processors only? It crashes on my Q6600 which it never did before.
Yes. Let me upload the 64-bit non-popcnt version. I wasn't sure if anyone was using it or not.
Now I know, :wink: (sorry for the confusion).
OK, I've updated the webpage so that both the Windows and Linux 64-bit non-popcnt versions are available. I've confused things a bit but this should be clearer in the long run. Here is the lay of the land of the various executables:

Code: Select all

Windows
----------
Djinn 1.006 (64-bit)             -- djinn1006_x64.exe
Djinn 1.006 (64-bit w/ popcnt)   -- djinn1006_x64_popcnt.exe
Djinn 1.006 (32-bit)             -- djinn1006_w32.exe

Linux
------
Djinn 1.006 (64-bit)             -- djinn1006_x64
Djinn 1.006 (64-bit w/ popcnt)   -- djinn1006_x64_popcnt
I'll keep this naming convention for all future releases. One thing to note, is that initially the "djinn1006_x64.exe" was the POPCNT-enabled version, so you should probably re-download it if that bothers you, (it's the same executable so you can just rename it if you like).

Hopefully, I didn't screw any of this up. And again my apologies for the mixup. :oops:

best,
--tom
Tom Likens
Posts: 303
Joined: Sat Apr 28, 2012 6:18 pm
Location: Austin, TX

Re: Djinn 1.006

Post by Tom Likens »

Rebel wrote:
Tom Likens wrote: 20-NOV-2013
-----------
S o Changed the criteria for beta pruning, so that it is only applied if the hash move is empty. It's also skipped if either alpha or beta is a mate score, (worth about 5 elo).
Congrats with the new version.

Question, what's beta pruning?

From what you describe it doesn't fit with normal A/B pruning.
Hello Ed,

I think it's pretty standard stuff, but my terminology may be bad. I added this after reading this post by Vincent.

http://talkchess.com/forum/viewtopic.ph ... 79&t=43165

I think this is what the Stockfish guys call "Static-Null Move Pruning".

Code: Select all

#define RAZOR_DEPTH  FIVE_PLY

static const int Razor[8] = {
    2000,  // 0 ply to the horizon
    3000,  // 1
    4000,  // 2
    5000,  // 3
    6000,  // 4
    7000,  // 5
    8000,  // 6
    9000,  // 7
};

/*----------------------------------------------------------------------*\
 | Beta razoring (i.e. pruning).  The idea here is that if our position |
 | is so good that even subtracting a large value from it still leaves  |
 | the score greater than or equal to beta, then cut this branch        |
 | since our opponent will never allow it.                              |
\*----------------------------------------------------------------------*/
if (null                 &&
    ply < RAZOR_DEPTH    &&
    !in_check            &&
    nodetype != PV_NODE  &&
    null_ok&#40;side&#41;        &&
    not_mate&#40;beta&#41;       &&
    hash_move == EmptyMove&#41; &#123;
    
    int fj = STD_MAX&#40;0, ply/ONE_PLY&#41;;

    if &#40;eval-Razor&#91;fj&#93; >= beta&#41; &#123;
        CHANT_SetUserNodetype&#40;CHANT_RAZOR_CUTOFF&#41;;
        return node_t&#40;eval-Razor&#91;fj&#93;, depth&#41;;
    &#125;
&#125;
A couple of things, my "ply" is everyone else's "depth". I've always done it that way, so it's natural for me but may be confusing to someone reading my code for the first time. It was too ensconced for me to change by the time everyone had defined the terminology. Also, I need to CLOP this to define the razor margins, but getting clop to converge for 4+ number of parameters is a slow tedious way to spend your life. It takes 40-50K games to get something useful. I still do it occasionally, but I usually limit CLOP to one or two parameters.

This code gave me a boost of about 20 elo, which isn't too bad for this number of lines. Interestingly though, it made the engine's score on the 300 WAC positions worst. I think there's room for a lot of improvement here, I just need to find the time to do it. Actually, that is one of the reasons I've dusted off "Chant". I intend to start walking through the search trees a bit more to try and understand why certain moves are either made or excluded. One thing I've already ascertained is that chess programs look at a lot of bizarre positions.

regards,
--tom
Tom Likens
Posts: 303
Joined: Sat Apr 28, 2012 6:18 pm
Location: Austin, TX

Re: Djinn 1.006

Post by Tom Likens »

tmokonen wrote:Thank you for the Christmas present, Tom.
Thank you Tony. Merry Christmas.
Tom Likens
Posts: 303
Joined: Sat Apr 28, 2012 6:18 pm
Location: Austin, TX

Re: Djinn 1.006

Post by Tom Likens »

SzG wrote: BTW, does Djinn still require the -xboard command line parameter to work correctly?

Gábor
Yes, it's required. I use it to turn on some things and turn off others, all specific to the Winboard interface.
tmokonen
Posts: 1296
Joined: Sun Mar 12, 2006 6:46 pm
Location: Kelowna
Full name: Tony Mokonen

Re: Djinn 1.006

Post by tmokonen »

Hi Tom, I was having a crashing issue with the 32 bit Windows version. It will play book moves, but crash as soon as it starts thinking. Perhaps it's something to do with SSE 4.2, as the non-SSE 64 bit compile works for me.
User avatar
Graham Banks
Posts: 41415
Joined: Sun Feb 26, 2006 10:52 am
Location: Auckland, NZ

Re: Djinn 1.006

Post by Graham Banks »

Tom Likens wrote:Djinn 1.006 is now available at:

http://webpages.charter.net/tlikens/index.html
Thanks Tom. :)
gbanksnz at gmail.com