question about symmertic evaluation

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Uri Blass
Posts: 8586
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

question about symmertic evaluation

Post by Uri Blass » Wed May 23, 2007 7:53 pm

I found that my evaluation is not symmetric for white and black.

one of the reason is that in some part of my evaluation I simply calculate score from white point of view and later divide by 8

now (14>>3)=1 and (-14>>3)=-2 so I can get a different number
for white and black.

My question is how do you solve that type of problem and if there is a way to solve it without doing the code slower(of course it is easy to solve it by doing the code slower and writing something like
if (score<0)
{
score=-score;
score=score>>3;
score=-score;
}
else
score=score>>3;

I thought also about using (score+4)>>3 but in that case (12+4)>>3=2
when (-12+4)>>3=-1

Uri

Uri Blass
Posts: 8586
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

Re: question about symmertic evaluation

Post by Uri Blass » Wed May 23, 2007 8:45 pm

The best thing that I can think about is something like this

Code: Select all

if &#40;score>0&#41;
			score+=4;
		else
			score+=3;
		return &#40;score>>3&#41;;
I wonder if you have better idea how to make it symmetric for score=X and score=-X

Maybe there is a simple library function of division that is faster

Gerd Isenberg
Posts: 2127
Joined: Wed Mar 08, 2006 7:47 pm
Location: Hattingen, Germany

Re: question about symmertic evaluation

Post by Gerd Isenberg » Wed May 23, 2007 8:46 pm

One idea is to avoid the asymmetrical arithmetical shift right 3 at all and to mul all other eval aspects by 8. You may add 7 if the value to shift arithmetical right 3 is negative, but this is of course more expensive.

Code: Select all

symmetrical arithmetical shift right 3 &#58;&#58;= &#40;x + (&#40;x>>31&#41;&7&#41;) >> 3
or with respect to the value range:

Code: Select all

symmetrical arithmetical shift right 3 &#58;&#58;= &#40;x + (&#40;unsigned&#41;x>>29&#41;) >> 3
The common approach seems to score and aggregate from white resp. black point of view and keep both values in evalScore[2] to divide both before the final difference for color's point of view:

Code: Select all

posEval = &#40;evalScore&#91;color&#93;>>3&#41; - &#40;evalScore&#91;color^1&#93;>>3&#41;;
Gerd

Uri Blass
Posts: 8586
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

Re: question about symmertic evaluation

Post by Uri Blass » Wed May 23, 2007 9:04 pm

Gerd Isenberg wrote:One idea is to avoid the asymmetrical arithmetical shift right 3 at all and to mul all other eval aspects by 8. You may add 7 if the value to shift arithmetical right 3 is negative, but this is of course more expensive.

Code: Select all

symmetrical arithmetical shift right 3 &#58;&#58;= &#40;x + (&#40;x>>31&#41;&7&#41;) >> 3
or with respect to the value range:

Code: Select all

symmetrical arithmetical shift right 3 &#58;&#58;= &#40;x + (&#40;unsigned&#41;x>>29&#41;) >> 3
The common approach seems to score and aggregate from white resp. black point of view and keep both values in evalScore[2] to divide both before the final difference for color's point of view:

Code: Select all

posEval = &#40;evalScore&#91;color&#93;>>3&#41; - &#40;evalScore&#91;color^1&#93;>>3&#41;;
Gerd
Thanks

Here is the full code that caused the problem and is about prefering pawns in the endgame

Code: Select all

static int evalpawnrelative&#40;void&#41;
&#123;
	int score=0;
	if &#40;numpawns&#91;LIGHT&#93;!=numpawns&#91;DARK&#93;)
	&#123;
		score=&#40;24-valuepieces&#41;*&#40;numpawns&#91;LIGHT&#93;-numpawns&#91;DARK&#93;);
 		return &#40;score>>3&#41;*prefer_pawns_in_end_games;
	&#125;
	return 0;

&#125;
valuepieces can be bigger than 24 in the opening or smaller than 24 in the endgame.
The default value of prefer_pawns_in_the end_games is 1

practically the score that it returns is between -0.0475 per pawn advantage in the opening and 0.03 per pawn advantage in pawn endgames.


I can make 2 tables for pawns in the endgame and in the opening but I am not sure if it is a good idea because in many positions the number of pawns of both sides is equal so calculating 2 piece square tables when the difference between them is constant seems to be a waste of time.

Maybe I care too much about small speed change that is not very important and it is not that I really care about speed but simply that I do not like my program to be slower because of fixing a bug.

Uri

bob
Posts: 20555
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: question about symmertic evaluation

Post by bob » Wed May 23, 2007 9:50 pm

just don't use shift as it is not correct for positive and negative numbers.

bob
Posts: 20555
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: question about symmertic evaluation

Post by bob » Wed May 23, 2007 9:51 pm

Gerd Isenberg wrote:One idea is to avoid the asymmetrical arithmetical shift right 3 at all and to mul all other eval aspects by 8. You may add 7 if the value to shift arithmetical right 3 is negative, but this is of course more expensive.

Code: Select all

symmetrical arithmetical shift right 3 &#58;&#58;= &#40;x + (&#40;x>>31&#41;&7&#41;) >> 3
or with respect to the value range:

Code: Select all

symmetrical arithmetical shift right 3 &#58;&#58;= &#40;x + (&#40;unsigned&#41;x>>29&#41;) >> 3
The common approach seems to score and aggregate from white resp. black point of view and keep both values in evalScore[2] to divide both before the final difference for color's point of view:

Code: Select all

posEval = &#40;evalScore&#91;color&#93;>>3&#41; - &#40;evalScore&#91;color^1&#93;>>3&#41;;
Gerd
I'd be willing to bet that a plain divide will not noticably affect his overall search speed. And it will solve this correctly.

Uri Blass
Posts: 8586
Joined: Wed Mar 08, 2006 11:37 pm
Location: Tel-Aviv Israel

Re: question about symmertic evaluation

Post by Uri Blass » Wed May 23, 2007 10:04 pm

bob wrote:
Gerd Isenberg wrote:One idea is to avoid the asymmetrical arithmetical shift right 3 at all and to mul all other eval aspects by 8. You may add 7 if the value to shift arithmetical right 3 is negative, but this is of course more expensive.

Code: Select all

symmetrical arithmetical shift right 3 &#58;&#58;= &#40;x + (&#40;x>>31&#41;&7&#41;) >> 3
or with respect to the value range:

Code: Select all

symmetrical arithmetical shift right 3 &#58;&#58;= &#40;x + (&#40;unsigned&#41;x>>29&#41;) >> 3
The common approach seems to score and aggregate from white resp. black point of view and keep both values in evalScore[2] to divide both before the final difference for color's point of view:

Code: Select all

posEval = &#40;evalScore&#91;color&#93;>>3&#41; - &#40;evalScore&#91;color^1&#93;>>3&#41;;
Gerd
I'd be willing to bet that a plain divide will not noticably affect his overall search speed. And it will solve this correctly.
thanks

It seems that replacing some >> by / solves the problem
of anti-symmetric evaluation and now at least for the wac positions my evaluation is symmetric between white and black(did not check symmetry between left and right)

Uri

Gerd Isenberg
Posts: 2127
Joined: Wed Mar 08, 2006 7:47 pm
Location: Hattingen, Germany

Re: question about symmertic evaluation

Post by Gerd Isenberg » Wed May 23, 2007 10:09 pm

bob wrote: I'd be willing to bet that a plain divide will not noticably affect his overall search speed. And it will solve this correctly.
Idiv is still quite expensive (idiv r32/imm ~18-42 cycles on core2 duo) - but if seldomly used it does not hurt. Anyway, vc2005 seems aware of that trick:

Code: Select all

int idiv8&#40;int x&#41;
&#123;
   return x / 8;
&#125;

  mov  eax, ecx
  cdq
  and  edx, 7
  add  eax, edx
  sar  eax, 3

bob
Posts: 20555
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: question about symmertic evaluation

Post by bob » Thu May 24, 2007 12:01 am

Gerd Isenberg wrote:
bob wrote: I'd be willing to bet that a plain divide will not noticably affect his overall search speed. And it will solve this correctly.
Idiv is still quite expensive (idiv r32/imm ~18-42 cycles on core2 duo) - but if seldomly used it does not hurt. Anyway, vc2005 seems aware of that trick:

Code: Select all

int idiv8&#40;int x&#41;
&#123;
   return x / 8;
&#125;

  mov  eax, ecx
  cdq
  and  edx, 7
  add  eax, edx
  sar  eax, 3
The thing is it interlaces nicely with other instructions around it... I have been using several divides in my code to scale parts of the evaluation, and it made absolutely no difference in my NPS...

User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 6:43 pm

Re: question about symmertic evaluation

Post by sje » Thu May 24, 2007 3:42 am

bob wrote:I'd be willing to bet that a plain divide will not noticably affect his overall search speed. And it will solve this correctly.
Agreed. Furthermore, a decent optimizing compiler will code a power of two division as a right shift where it is possible (and correct) to do so.

Post Reply