Re: [Bug-gnubg] Small oddity in CalculateHalfInputs()

[Jon Kinsey]

Jim Segrave wrote:
> 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