[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 10:59:42 +1200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202

Marek wrote:

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

ok, I understand. Some of my thesis I defend once more. I hope you are
not very angry bothering with some user trying to understand your code.

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;

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.

Perhaps you are confused by GNU board representation. For both sides, home is points 0 - 5.

This line: 'for( j = 18; j <= i; ++j ) {' searches fields numbered 18+ -
that's our home, not "opp home"! 'Our home' is where we start, I hope
(language problem) and it's opponent's borneoff area. Our bar chequers
stay at field 24, 23 is the first field of our home (not the *opp
home*). Fields 23,22,21,20,19,18 are our home fields (meaning
arBoard[23] is the number of chequers at first field of our home). If
there is anchor there we take the one on the lowest numbered point
('break' statement breaks searching for the next one) - that's the point
farthest from our barfield (it's the advanced one, I agree). If there is
none we search the fields 17-12 for the first one (not 7-12!).

Summarise: If there is an anchor in *our home*, take the most advanced
one (the one farthest from the bar-field). If there is none, search for
the *first* anchor in points 17-12 (the one with the largest number,
meaning the closest to the bar-field).

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


22 and 23 (i.e. go up to 23), otherwise stop at 21

But 'board is strong' (nBoard > 2) doesn't mean we have at least 3
anchors (as description says). It means we have at least 3 fields (not
necessary an anchors!, it might be single checkers only).

Hmm, you are right. I am not sure if this was intentional (by Gary) or not.

line 1125:

if( anBoard[ j ] && !( j < 6 && anBoard[ j ] == 2 ) )

This is condition (2). If there is a checker at j, and NOT ( checker


home AND exactly 2 checker on point)

This condition is 'if there is a checker at j, and NOT ( checker in
borneoff area AND exactly 2 checker point)'. 'j<6' means we are in the
borneoff area (again, as in point 2: 24 is our bar-field,
23,22,21,20,19,18 are home fields, .5,4,3,2,1,0 are borneoff fields.
Another words it means 'checker in opp home', not 'in home' - which I
understand as 'in our home'.

Not sure what you are saying. Looks correct to me. Please give a board position, the value the code computes and the value you think is correct.

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.

I think you missed this paragraph, so I resend it (some modification
since last save - I've also made a few bugs here ;-)):

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 here. Why do we
multiply indexes by 2? We should just add approperiate index (as it's
added when calling CalculateHalfInputs. Probobly we should put there
"arInput[I_OFF1+4*25*2]" to get inputs corresponding with the first
CalculateHalfInputs call (calculating for 'our' side). The next lines
(I_OFF2,...) should be changed accoringly.

I think you are right. DumpContact has not been upgraded when the change to inputs was done. Also I have no idea why only one side is displayed.

Marek Turski

reply via email to

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