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

[Joseph Heled]

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
>
> inputs.
> 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;
> > > >   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;
>
>
> > 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 ] )
> > > >   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
>
>
> 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
>
> in
>
> > 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.


> Sincerely,
> Marek Turski