🚀 go-pugleaf

GNU Chess current CVS head (and presumably recent or all
versions of GNU Chess 5).


In SortMoves in sort.c during a capture the move score is a
weighted piece value minus the value of the capturing piece.

Where it is a KP v K ending, the K is 2000, the P is 100, WEIGHT
is 12.

So move score for capture is adjusted (12 * 100 - 2000) thats
-800, which will mean it is examined last!

I think this is a bug - an attempt below to fix it crudely
(+ValueK on captures) gave.

endgame.epd at default time controls Cyrix 166MHz

Program	Score	Nodes

original 12/46	11,137,948
modified 13/46  11,090,333

Which look promising - one extra endgame solved with less nodes
(~0.4%) - but is within the bounds of any chance modification to
the sorting code (and experimental error, although less nodes
suggests the machine did less work in the new case, rather than
stopping to do something more important than chess).

Since SortMoves is not used as extensively as it's name suggests
this doesn't have a huge impact on the programs search.

During debugging this change I noted SortMoves producing odd
move score values for spurious King moves to the center
(endgame.epd first position), but I can not reproduce this since
making this change. I can not account for these extra spurious
values disappearing, other than perhaps they were only occurring
in regions of the tree that are no longer generated, and that
they must have been from the move hash. 

I think for consistency with other sections of the code we
should probably use SwapOff rather than subtracting the
capturing pieces value in SortMoves captures, although given
when SortMoves is called this may be irrelevant.

All negative value captures receive a move value of -32768, this
seems to waste SwapOff effort, does anyone know why the SwapOff
value isn't used?

I assume the -32768 is so capture sequences that lose material
are looked at after any non-captures, but we could stop basing
the non-capture move score on -32768, and have 'move scores'
approximate to the change of value in the actual evaluation
score, i.e. Pawn capture +100, pawn loss -100, push passed pawn
+50, rather than the current (+100, -32738, -32768). Thus given
a choice of material losing capture sequences we'll pick the
lesser evil to examine first. This is probably more important
where SortMoves is mixing hashed values with ordinary move
scores, even if I couldn't reproduce this.

Whilst "successful" pawn promotions get SwapOff (Q, R, N, B
ordering other things being equal N=B, but N is generated
first), all doomed promotions gets -32768. Thus the code
examines doomed promotions in the order N, B, R, Q (Cause that
is how they are generated).

I was thinking it is always better to examine ALL pawn
promotions in the order Q, N, R, B, as even when the promoted
piece is doomed the Q promotion is more forcing, where as in the
"real world" (Not puzzles where the opposite is probably true)
underpromotions are incredibly rare, and underpromotions to
anything other than a Knight even more so.

Any thoughts on move ordering, or explanations of how the
current code actually works (PhasePick still has my brain juices
bubbling) welcome.

 Simon

PS: SortMove code snippet below

 else if (cboard[t] != 0 || p->move & PROMOTION)
      {
 
        /* ***** SRW My Interpretation of this code
*************
           * Captures normally in other places but.....        
*
           *                                                   
*
           * On capture we generally prefer to capture with the
*
           * with the lowest value piece so to chose between   
*
           * pieces we should subtract the piece value .... but
*
           *                                                   
*
           * The original code was looking at some captures    
*
           * last, especially where the piece was worth more   
*
           * than the piece captured - KP v K in endgame.epd   
*
           *                                                   
*
           * So code modified to prefer any capture by adding  
*  
           * ValueK                                            
*
          
****************************************************** */
 
//      tovalue = WEIGHT * (Value[cboard[t]] +
Value[PROMOTEPIECE (p->move)]);
//      p->score += tovalue - Value[cboard[f]];
        tovalue = (Value[cboard[t]] + Value[PROMOTEPIECE
(p->move)]);
        p->score += tovalue + ValueK - Value[cboard[f]];
  
-- 
"Don't get me started on intuitive. You know what's intuitive?
Fear of heights. Everything else we call intuitive, such as
walking or using a pencil took years of practice." - Don Norman