bug-gnubg
[Top][All Lists]

## [Bug-gnubg] Bug report (Documentation) & some doubts to CalculateHalfIn

 From: Marek Subject: [Bug-gnubg] Bug report (Documentation) & some doubts to CalculateHalfInputs Date: Tue, 8 Apr 2003 21:51:33 +0200

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

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

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 */

line 1125:
> if( anBoard[ j ] && !( j < 6 && anBoard[ j ] == 2 ) )

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

```