SINGULAR in IvanHoe

Code, algorithms, languages, construction...
Post Reply
BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

SINGULAR in IvanHoe

Post by BB+ » Mon Aug 02, 2010 11:36 pm

I tried to quantify the ELO gain from singular extensions in IvanHoe. My code perusal implies that there are 4 places these come into play, twice in cut_node.c, and twice in pv_node.c. I eliminated 3 of these, both the SINGULAR computations for CUT nodes (both in-check and not), and the not in-check one at PV nodes. The only SINGULAR extensions still left seem to be those from forced moves when in check at a PV node (the main reason these were left in is simply that I was simply sloppy in doing this). However, there are still "extensions" based upon passed pawns and other features.

Results: a bit over 5000 games head-to-head games at 15s plus 0.25s increment on 1 cpu. The no-SINGULAR version searched an average of 3/4 ply deeper, but performed a tad over 20 ELO worse (around 5-6 sigma).

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: SINGULAR in IvanHoe

Post by BB+ » Mon Aug 02, 2010 11:49 pm

I should make it more clear: I put an "#if 0" around all the code used in computing the SINGULAR condition.

benstoker
Posts: 110
Joined: Thu Jun 10, 2010 7:32 pm
Real Name: Ben Stoker

Re: SINGULAR in IvanHoe

Post by benstoker » Tue Aug 03, 2010 12:01 am

BB+ wrote:I tried to quantify the ELO gain from singular extensions in IvanHoe. My code perusal implies that there are 4 places these come into play, twice in cut_node.c, and twice in pv_node.c. I eliminated 3 of these, both the SINGULAR computations for CUT nodes (both in-check and not), and the not in-check one at PV nodes. The only SINGULAR extensions still left seem to be those from forced moves when in check at a PV node (the main reason these were left in is simply that I was simply sloppy in doing this). However, there are still "extensions" based upon passed pawns and other features.

Results: a bit over 5000 games head-to-head games at 15s plus 0.25s increment on 1 cpu. The no-SINGULAR version searched an average of 3/4 ply deeper, but performed a tad over 20 ELO worse (around 5-6 sigma).
That result seems to be close to what Hyatt's tests are showing on the other forum.

Do you mind posting a diff?

BB+
Posts: 1484
Joined: Thu Jun 10, 2010 4:26 am

Re: SINGULAR in IvanHoe

Post by BB+ » Tue Aug 03, 2010 12:19 am

Do you mind posting a diff?
The computer is at home (with no Internet access) and I am at work. I think the changes are: eliminate lines 146-167 and 379-400 of cut_node.c; and lines 205-229 of pv_node.c

Code: Select all

  if (depth >= 16 && trans_move && MyOK (POSITION, trans_move)) // cut_node.c:146
    {
      v = MyExclude (POSITION, VALUE - VALUE_RED1, depth - DEPTH_RED,
                     trans_move & 0x7fff);
      CHECK_HALT ();
      if (v < VALUE - VALUE_RED1)
        {
          SINGULAR++;
          height = HEIGHT (POSITION);
          if (height * 4 <= depth)
            SINGULAR++;
          v = MyExclude (POSITION, VALUE - VALUE_RED2,
                         depth - DEPTH_RED, trans_move & 0x7fff);
          CHECK_HALT ();
          if (v < VALUE - VALUE_RED2)
            {
              SINGULAR++;
              if (height * 8 <= depth)
                SINGULAR++;
            }
        }
    }

Code: Select all

  if (depth >= 16 && trans_move) // line 379 of cut_node.c
    {
      v = MyExcludeCheck (POSITION, VALUE - depth,
                          depth - MIN (12, depth / 2), trans_move & 0x7fff);
      CHECK_HALT ();
      if (v < VALUE - depth)
        {
          SINGULAR++;
          height = HEIGHT (POSITION);
          if (height * 4 <= depth)
            SINGULAR++;
          v = MyExcludeCheck (POSITION, VALUE - 2 * depth,
                              depth - MIN (12, depth / 2), trans_move & 0x7fff)\
;
          CHECK_HALT ();
          if (v < VALUE - 2 * depth)
            {
              SINGULAR++;
              if (height * 8 <= depth)
                SINGULAR++;
            }
        }
    }

Code: Select all

  if (depth >= 16 && NextMove->trans_move && SINGULAR < 2 // pv_node.c:205
      && MyOK (POSITION, NextMove->trans_move))
    {
      move = NextMove->trans_move;
      if (check)
        v = MyExcludeCheck (POSITION, ALPHA - VALUE_RED1,
                            depth - DEPTH_RED, move & 0x7fff);
      else
        v = MyExclude (POSITION, ALPHA - VALUE_RED1,
                       depth - DEPTH_RED, move & 0x7fff);
      CHECK_HALT ();
      if (v < ALPHA - VALUE_RED1)
        {
          SINGULAR = 1;
          if (check)
            v = MyExcludeCheck (POSITION, ALPHA - VALUE_RED2,
                                depth - DEPTH_RED, move & 0x7fff);
          else
            v = MyExclude (POSITION, ALPHA - VALUE_RED2,
                           depth - DEPTH_RED, move & 0x7fff);
          CHECK_HALT ();
          if (v < ALPHA - VALUE_RED2)
            SINGULAR = 2;
        }
    }

benstoker
Posts: 110
Joined: Thu Jun 10, 2010 7:32 pm
Real Name: Ben Stoker

Re: SINGULAR in IvanHoe

Post by benstoker » Fri Aug 06, 2010 6:56 pm

BB+ wrote:I tried to quantify the ELO gain from singular extensions in IvanHoe. My code perusal implies that there are 4 places these come into play, twice in cut_node.c, and twice in pv_node.c. I eliminated 3 of these, both the SINGULAR computations for CUT nodes (both in-check and not), and the not in-check one at PV nodes. The only SINGULAR extensions still left seem to be those from forced moves when in check at a PV node (the main reason these were left in is simply that I was simply sloppy in doing this). However, there are still "extensions" based upon passed pawns and other features.

Results: a bit over 5000 games head-to-head games at 15s plus 0.25s increment on 1 cpu. The no-SINGULAR version searched an average of 3/4 ply deeper, but performed a tad over 20 ELO worse (around 5-6 sigma).
20 ELO is not insignificant, but can one conclude from this that SE in ivan is NOT its holy grail? Kaufman said somewhere, I think, that ivan's unique SE is similar to rybka's and is the source of its strength.

Post Reply