[Bug-gnubg] Small oddity in CalculateHalfInputs()

[Jim Segrave]

I've been looking at this function as I belive it can be recoded to
provide more efficient setup of the NN inputs. As a first step, I've
been going through the code looking at the sections that produce
various inputs. One of the very first ones is the routine to calculate
the number of pips needed to break contact:


  n = 0;
  for( i = nOppBack + 1; i < 25; i++ )
    if( anBoard[ i ] )
      n += ( i + 1 - nOppBack ) * anBoard[ i ];

here nOppBack is the point number (-1 = bar, 0..23) of the opponent's
chequer which is farthest back (and hence has to be passed before
contact is broken). The problem is, that when there is a piece on the
bar, this caluclation comes up with the pip count needed to bearoff
each chequer +1. For example, if the side being evaluated had only one
chequer on the 6 point, and the opponent had a chequer on the bar, the
correct break contact value is 6, but this routine comes up with
7. This can lead to a significant discrepancy of 15 when the side
being evaluated hasn't yet borne anything off. I don't know what the
overall effect would be, but I thought I'd point it out. I assume any
replacement for CalculateHalfInputs will need to replicate this
behaviour, as otherwise the nets would need retraining.

-- 
Jim Segrave           address@hidden