Re: [Bug-gnubg] Bug report (Documentation) & some doubts to CalculateHalfInputs

[Joseph Heled]

The net inputs are 100% black magic. The only decision I can defend 
(i.e. am totally sure about) is the elimination of non contributing inputs.

Marek wrote:
> I've been analysing eval.c for some time and found some minor
> documentation bugs as well as some strange code fragments which may be
> bugs (but as the neuralnet is trained to work with such a strange
> inputs, it is ok).
>
> CalculateHalfInputs:
>
> 1) at line 1001:
>
> > afInput[ I_BREAK_CONTACT ] = n / (15 + 152.0);
>
>
> while at line 149:
>
> > Break Contact : (sum over x of C(x)) / 152
> > 152 is dgree of contact of start position.
>
>
> 152 as degree of contact of start position seems ok, so what is this 15
> for??? (BTW: spelling mistake at line 150, should "degree" there

I changed the contact computation to "one more", i.e. 2 pips are 
requited to "break contact" when checkers are next to each other, so 
value for initial position is up by 15. Remember this is cosmetic only, 
as a linear multiplier makes no difference at all.

> 2) line 1084: "forward anchor" input, {i = back anchor}
>
> > for( j = 18; j <= i; ++j ) {
> >  if( anBoard[j] >= 2 ) {
> >    n = 24 - j;
> >    break;
> >  }
> > }
> >
> > if( n == 0 ) {
> >  for( j = 17; j >= 12 ; --j ) {
> >    if( anBoard[j] >= 2 ) {
> >      n = 24 - j;
> >      break;
> >    }
> >  }
> > }
> >
> > afInput[ I_FORWARD_ANCHOR ] = n == 0 ? 2.0 : n / 6.0;
>
>
> whlie at line 165:
>
> > Normalized in the following way:  If there is an anchor in opponents
> > home at point k (1 <= k <= 6), value is k/6. Otherwise, if there is an
> > anchor in points (7 <= k <= 12), take k/6 as well. Otherwise set to 2.
>
>
> This description doesn't represent the code, although the input is
> called "forward anchor" so I suspect the description says what the
> author meant to do. This is what this code actually does (I think): it
> searches our home for the farthest anchor. If it doesn't find it it
> searches for the closest anchor at our half of the board (the one closer
> our home). If it finds something it takes its [distance_from_the_bar] /
> 6, otherwise it set to 2.
> In that case, why is this a "forward anchor"? I can't see the idea
> behind this input...

I think the code and description agree. If there is an anchor in *opp 
home*, take the most advanced one (the one on the highest point). If 
there is none, search for the *first* anchor in points 7-12.

> 3) line 1465: "backbone" input
>
> > for(np = 23; np > 0; --np) {
> >  if( anBoard[np] >= 2 ) {
> >    if( pa == -1 ) {
> >      pa = np;
> >      continue;
> >    }
>
>
> line 1482:
>
> > w += c * anBoard[pa];
> > tot += anBoard[pa];
>
>
> We're searching for some anchors. I have some doubts about it: a) why do
> we search for them everywhere except the last position (should be "np >=
> 0" at line 1465 I think).
>
> The first iterations of this loop just find "back anchor" again (we
> searched for it before). It would be faster to set this loop to "for(np
> = 'backanchor'; np >= 0; --np) {", of course this should be placed just
> after 'backanchor' counting (as is already done with 'forward anchor'
> counting), so we have this 'backanchor' value in the "i" variable (line
> 1103 is a nice place to put it, I think).
>
> Could You explain the idea of this input? This code (unexplained in
> documentation) searches for the backanchor and then for each anchor
> counts something that depends on its distance to backanchor and amount
> of chequers in the backanchor (not chequers in each anchor! index [pa]
> at lines 1482&1483 is backanchor index!}. Looks really strange. If this
> lines 1482&1483 had array indexes [np]... but this way? spooky ;-).
>
>
>
>
> 4) line 1107: "piploss" input
>
> > for( i = 0; i < 6; i++ )
> >  if( anBoard[ i ] )
> >    nBoard++;
>
>
> line 1116:
>
> > for( i = ( nBoard > 2 ) ? 23 : 21; i >= 0; i-- )
> >  /* if there's a blot there, then */
This is condition (1). If board is strong (nBoard > 2), consider points 
22 and 23 (i.e. go up to 23), otherwise stop at 21

> line 1125:
>
> > if( anBoard[ j ] && !( j < 6 && anBoard[ j ] == 2 ) )
This is condition (2). If there is a checker at j, and NOT ( checker in 
home AND exactly 2 checker on point)

> line 179:
>
> > 1. If board is weak (less than 3 anchors), don't consider hitting on
> >   points 22 and 23.
> > 2. Dont break anchors inside home to hit.
>
>
> This description again doesn't correspond to the code. What the code
> does (lines 1107&1116) is counting fields in our borneoff segment, where
> we have at least one chequer (nothing to do with anchors!). If we have 3
> fields there, we can hit points 22&23. Again, I wonder why such a filter
> is made? Hitting this fields is less danger (I think) than hitting other
> fields in borneoff area (smaller chance of being rehitted).

> Second point of description is also wrong. The code (line 1125) checks
> not to break a two chequers anchor inside borneoff area. That's very
> logical - breaking 2-chequers anchor leaves us with two
> 1-chequer-fields, each of which can be easly hit and send them a long
> way home. Though breaking achors inside home (as description says) is
> also a thing to avoid, so maybe we should add appropriate clause to the
> code - something like "if( anBoard[ j ] && !( j < 6 && anBoard[ j ] ==
> 2 ) && !(j >= 18 && anBoard[ j ] == 2) )".
>
>
>
> 5) DumpContact (line 3548):
>
> > arInput[ I_OFF1 << 1 ], ardEdI[ I_OFF1 << 1 ],
>
>
> Well, whole this DumpContact doesn't work well (at least at my
> version) - it doesn't write correct input values (most of them are
> zeros). Obviously this "<< 1" operations are strange. Why don't we just
> put there "arInput[I_OFF1]"? (I don't know if it should work with
> ardEdi - I didn't analyse this code fragments). Also it looks like this
> table is too short - it prints only one input as there are two of them
> (one for each side, one has index in arInput table [I_OFF1], the other
> one [I_OFF1+4*25*2], of course for other inputs it should be [I_OFF2]
> and such).
>
>
>
>
>
> That's it. Right now I'm trying to understand how "aHit" and "aRoll"
> values are counted... I've seen there some strange code fragments but
> I'm not sure yet if they're really wrong. When I'll be some more sure,
> I'll let you know. ;-)
>
>
>
> Sincerely,
> Marek Turski
>
>
>
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-gnubg