🚀 go-pugleaf

Dr Michael J. White (mwhite@osiris.cso.uiuc.edu) wrote:

: Here are some observations on pl68 and a few questions:

: It seems that pl68 runs slower for a given depth of evaluation than did pl65.
: At a depth of 6, I evaluated about 1000 positions on a Sparc IPX with pl65.
: Typical run times were about 4 min per position with about 8500 nodes/s.
: With pl68, run times are averaging 16 min per postion with about 7000 nodes/s.
: These are all positions from openings and early middlegames from ECO's, etc.,
: with no particular theme (other than their appeal to me -- a way-below-average
: player :) This wasn't intended to be a rigorous test, or even a *test*, I'm
: just trying to understand some (!) and (?) lines.

There are a few reasons for this.  The differences between pl65 and pl68 are
1.  More search extensions which make the program stronger, but it needs to
    search deeper for a given depth, i.e more nodes.

2.  A new DEEPNULL algorithm.  Unfortunately, due to a slight bug, it is
    never activated and consequently pl68 is running without any null move
    heuristics if DEEPNULL is defined.  I have posted a fix for this some
    time back, but I'll post it again a little further down.  Since null
    move gives about 25-50% less nodes, this is not being realized in pl68.

3.  A third difference is that pl68 uses Principle Variation Search or PVS.
    This does reduce the number of nodes search, but is probably being offset
    by 1 & 2 above.

Okay, here is the fix to get DEEPNULL working properly.
    In search.c lines 1153, 1313 and 1323, replace

#ifdef NULLMOVE

    with

#if defined NULLMOVE || defined DEEPNULL

For an additional tip, trying using -DKILLT instead of -DHISTORY.  You 
will get better move ordering as the history heuristic isn't well 
implemented.


: Now, pl68 finds and evaluates draws (especially repetiton of position)
: correctly, where pl65 did not.  This is great -- I was about to post some
: drawing lines that earlier gnuchess pl's, didn't score correctly.

: Now I'm wondering about several concepts dealing with draws:
: (1) Bob Hyatt's program Cray Blitz uses the ply distance to draw as bonus
:     in the evaluation, with a 100 point "free window" around draw score.
:     100 points = 0.1 pawn in Cray Blitz, I think.
: It looks like gnuchess does something similar, but it also seems to score
: a materially and positionally balanced game with a score of zero, also.
: Is there an advantage to having a drawing window like Cray Blitz?
: Sometimes in a long sequence of half-pawn advantage or disadvantage lines
: there's a zero score in pl68.  Not 1, or 2 or 5 or 6 but 0 and as far as I
: can tell there's no draw there!
: Surely there's some difference between a known draw and a balanced game...

Gnuchess doesn't handle draws too cleanly.  It does not use the free window
idea of Cray Blitz, nor the ply distance as a score.  Instead, it sets a 
flag at the node to indicate that an exact score (draw or mate) has 
been seen and sets the score to 0.  This doesn't work quite right in my 
opinion, but I'm unsure as to how it should work.  Perhaps someone could 
figure out a better algorithm to handle draws (its hard to use CB idea as 
he uses 100 points = 0.1 pawn whereas gnu uses 10 points = 0,1 pawn).


: (3) Are there many drawing sequences where pieces just shuffle around and
:     achieve three repetitions of position (wait-- three repetitions or THE
:     THIRD REPETITION-- whatever!)?
: Maybe evaluating all of these "shuffling draws" is slowing down the evaluation
: in pl68 -- not a bad thing if one wants draws to be correctly evaluated.
: Thanks!

Unless the draw is forcing, most of these would tend to be pruned away.


Kong Sian