[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joseph Heled
Subject: Re: [Bug-gnubg] Bug report (Documentation) & some doubts to CalculateHalfInputs
Date: Thu, 10 Apr 2003 08:13:52 +1200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202

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


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;

if( n == 0 ) {
 for( j = 17; j >= 12 ; --j ) {
   if( anBoard[j] >= 2 ) {
     n = 24 - j;

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;

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 ] )

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

Marek Turski

Bug-gnubg mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]