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

[Jim Segrave]

On Wed 18 May 2005 (18:26 +0100), Jon Kinsey wrote:
> Jim Segrave wrote:
> >On Wed 18 May 2005 (08:06 +0100), Jon Kinsey wrote:
> >
> >>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:
> [snip]
> >No, 6 points breaks contact - you don't have to go any further than
> >off.
> 
> I was confused - and thought it was the piece on the bar that was being
> counted not the other way around.
> 
> >
> >>now if instead nOppBack = 0 (1 pt) gives:
> >>nOppBack = 0 (1 pt), i = 5 (6 pt) gives:
> >>i + 1 - nOppBack = 6
> >
> >
> >Breaking contact with a man on the 1 is no different than with the man
> >on the bar, you only break contact by bearing off
> 
> You're right, but is that all the code is doing?  Or more specifically
> there is a difference (in the position) so perhaps the different values
> help distinguish these positions in some way?
> 
> I really don't know much about the NN code, out of interest if this was
> changed would it likely have any effect?  If so does that mean that
> gnubg is slightly mis-trained for this specific circumstance?

Well, it's been trained with inputs that work that way. It's possible,
but not certain by any means that this slight discontinuity in the way
this input behaves for chequers off vs. chequers on the low points
might make a difference, but it's equally possible that the training
has already made that difference negligible. (It's also interesting to
note that the comments say the initial position needs 152 pips to bear
off (and presumably that accounts for the later division of the count
by 152, but the initial count to break contact is 167, not 152). 

Unless someone can assure me that making this input follow the
comments rather than the actual calculation, I will endevour to insure
any attempt to rewrite CalculateHalfInputs follows the current actual
behaviour



-- 
Jim Segrave           address@hidden