bug-gnubg
[Top][All Lists]

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

 From: Jon Kinsey Subject: Re: [Bug-gnubg] Small oddity in CalculateHalfInputs() Date: Wed, 18 May 2005 08:06:14 +0100 User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7

```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