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.
I think the code might be ok. E.g.
nOppBack = -1 (bar), i = 5 (6 pt) gives: i + 1 - nOppBack = 7
now if instead nOppBack = 0 (1 pt) gives: nOppBack = 0 (1 pt), i = 5 (6 pt) gives: i + 1 - nOppBack = 6
and if instead nOppBack = 4 (5 pt) gives: nOppBack = 4 (5 pt), i = 5 (6 pt) gives: i + 1 - nOppBack = 2
It's a bit confusing though so perhaps I've misunderstood the problem.
Jon
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Bug-gnubg mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnubg
