Mobility Evaluation ?

[MahmoudUthman]

I calculate mobility in evaluation function. Where did you calculate your mobility?

In Evaluation

If your qsearch would return with side in check you can add a small penalty, start at -5 cp. You can always tune this as you introduce some evaluation, reduction/pruning changes later.

qsearch doesn't call evaluation while the side to move is in check but it maybe giving check to the other side shouldn't this be scored as a bonus ?

[Sven]

I calculate mobility in evaluation function. Where did you calculate your mobility?

In Evaluation

If your qsearch would return with side in check you can add a small penalty, start at -5 cp. You can always tune this as you introduce some evaluation, reduction/pruning changes later.

qsearch doesn't call evaluation while the side to move is in check but it maybe giving check to the other side shouldn't this be scored as a bonus ?

Only the moving side can be in check. "Giving check" means making a move after which the opponent is in check. Since the evaluation function assigns a score to positions, not moves, there is no difference between possibly assigning a penalty for being in check and assigning a bonus for giving check. And both do not occur if the evaluation is not called when the moving side is in check.

In theory there may be one exception, though: the evaluation function may also be called at full-width nodes, for instance to support pruning decisions or similar. But I see no reason why this should be relevant in positions where the moving side is in check.

[Ferdy]

I calculate mobility in evaluation function. Where did you calculate your mobility?

In Evaluation

If your qsearch would return with side in check you can add a small penalty, start at -5 cp. You can always tune this as you introduce some evaluation, reduction/pruning changes later.

qsearch doesn't call evaluation while the side to move is in check but it maybe giving check to the other side shouldn't this be scored as a bonus ?

Deep into the qsearch (depth <= -2) you can rely in your eval even when you are in-check and may return as long as eval >= beta. As your iteration increases and with some extensions that may happen, whatever things that you might missed at depth <= -2 will be somewhat corrected. Generally strong engines have high iteration depth reached. qsearch is not really a good place to spend more time as it only searches captures and perhaps other important moves such as queen promotion and moves that are checks. It is always a goal to assist qsearch using the eval, an eval that can approximate closely the correct score of the position even if it is not searching the captures. Before a capture can happen it has to make a threat move first, adding threat bonus in the eval would already assist qsearch. Adding a penalty in the eval when your king is in check would make the eval aware that such position is not good and would try to avoid it as you increase the iteration depths.

[Sven]

I calculate mobility in evaluation function. Where did you calculate your mobility?

In Evaluation

If your qsearch would return with side in check you can add a small penalty, start at -5 cp. You can always tune this as you introduce some evaluation, reduction/pruning changes later.

qsearch doesn't call evaluation while the side to move is in check but it maybe giving check to the other side shouldn't this be scored as a bonus ?

Deep into the qsearch (depth <= -2) you can rely in your eval even when you are in-check and may return as long as eval >= beta. As your iteration increases and with some extensions that may happen, whatever things that you might missed at depth <= -2 will be somewhat corrected. Generally strong engines have high iteration depth reached. qsearch is not really a good place to spend more time as it only searches captures and perhaps other important moves such as queen promotion and moves that are checks. It is always a goal to assist qsearch using the eval, an eval that can approximate closely the correct score of the position even if it is not searching the captures. Before a capture can happen it has to make a threat move first, adding threat bonus in the eval would already assist qsearch. Adding a penalty in the eval when your king is in check would make the eval aware that such position is not good and would try to avoid it as you increase the iteration depths.

Are you sure that your qsearch even calls the static evaluation if the side to move is in check? Mine doesn't, it does a regular 1-ply search instead when being in check. Static eval is only used for "stand pat" which is impossible when being in check. And if eval isn't called then I do not need to think about any in-check bonus or penalty.

[Ferdy]

I calculate mobility in evaluation function. Where did you calculate your mobility?

In Evaluation

If your qsearch would return with side in check you can add a small penalty, start at -5 cp. You can always tune this as you introduce some evaluation, reduction/pruning changes later.

qsearch doesn't call evaluation while the side to move is in check but it maybe giving check to the other side shouldn't this be scored as a bonus ?

Deep into the qsearch (depth <= -2) you can rely in your eval even when you are in-check and may return as long as eval >= beta. As your iteration increases and with some extensions that may happen, whatever things that you might missed at depth <= -2 will be somewhat corrected. Generally strong engines have high iteration depth reached. qsearch is not really a good place to spend more time as it only searches captures and perhaps other important moves such as queen promotion and moves that are checks. It is always a goal to assist qsearch using the eval, an eval that can approximate closely the correct score of the position even if it is not searching the captures. Before a capture can happen it has to make a threat move first, adding threat bonus in the eval would already assist qsearch. Adding a penalty in the eval when your king is in check would make the eval aware that such position is not good and would try to avoid it as you increase the iteration depths.

Are you sure that your qsearch even calls the static evaluation if the side to move is in check?

Yes.

Sample code

Code: Select all

int qsearch(alpha, beta, depth, isCheck)
{
	assert&#40;depth <= 0&#41;;

	if&#40;isCheck&#41;
		genCheckEvasion&#40;);
	else&#123;
		evalValue = evaluate&#40;);

		if&#40;evalValue >= beta&#41;
			return beta;

		if&#40;evalValue > alpha&#41;
			alpha = evalValue;

		genCaptures&#40;);
	&#125;

	while&#40;moves&#41;
	&#123;
		makeMove&#40;);

		if&#40;depth == 0 && checkMove&#40;))
			searchValue = -qsearch&#40;-beta, -alpha, depth-1, true&#41;;
		else
			searchValue = -qsearch&#40;-beta, -alpha, depth-1, false&#41;; // Faking the check flag

		takeback&#40;)

		if&#40;searchValue >= beta&#41;
			return beta;
		if&#40;searchValue > alpha&#41;
			alpha = searchValue;
	&#125;
	return alpha;
&#125;

[Sven]

I calculate mobility in evaluation function. Where did you calculate your mobility?

In Evaluation

If your qsearch would return with side in check you can add a small penalty, start at -5 cp. You can always tune this as you introduce some evaluation, reduction/pruning changes later.

qsearch doesn't call evaluation while the side to move is in check but it maybe giving check to the other side shouldn't this be scored as a bonus ?

Deep into the qsearch (depth <= -2) you can rely in your eval even when you are in-check and may return as long as eval >= beta. As your iteration increases and with some extensions that may happen, whatever things that you might missed at depth <= -2 will be somewhat corrected. Generally strong engines have high iteration depth reached. qsearch is not really a good place to spend more time as it only searches captures and perhaps other important moves such as queen promotion and moves that are checks. It is always a goal to assist qsearch using the eval, an eval that can approximate closely the correct score of the position even if it is not searching the captures. Before a capture can happen it has to make a threat move first, adding threat bonus in the eval would already assist qsearch. Adding a penalty in the eval when your king is in check would make the eval aware that such position is not good and would try to avoid it as you increase the iteration depths.

Are you sure that your qsearch even calls the static evaluation if the side to move is in check?

Yes.

Sample code

Code: Select all

int qsearch(alpha, beta, depth, isCheck)
{
	assert&#40;depth <= 0&#41;;

	if&#40;isCheck&#41;
		genCheckEvasion&#40;);
	else&#123;
		evalValue = evaluate&#40;);

According to that sample code you wanted to reply "No", right? I see a call to evaluate() only if isCheck is false.

[Ferdy]

I calculate mobility in evaluation function. Where did you calculate your mobility?

In Evaluation

If your qsearch would return with side in check you can add a small penalty, start at -5 cp. You can always tune this as you introduce some evaluation, reduction/pruning changes later.

qsearch doesn't call evaluation while the side to move is in check but it maybe giving check to the other side shouldn't this be scored as a bonus ?

Deep into the qsearch (depth <= -2) you can rely in your eval even when you are in-check and may return as long as eval >= beta. As your iteration increases and with some extensions that may happen, whatever things that you might missed at depth <= -2 will be somewhat corrected. Generally strong engines have high iteration depth reached. qsearch is not really a good place to spend more time as it only searches captures and perhaps other important moves such as queen promotion and moves that are checks. It is always a goal to assist qsearch using the eval, an eval that can approximate closely the correct score of the position even if it is not searching the captures. Before a capture can happen it has to make a threat move first, adding threat bonus in the eval would already assist qsearch. Adding a penalty in the eval when your king is in check would make the eval aware that such position is not good and would try to avoid it as you increase the iteration depths.

Are you sure that your qsearch even calls the static evaluation if the side to move is in check?

Yes.

Sample code

Code: Select all

int qsearch(alpha, beta, depth, isCheck)
{
	assert&#40;depth <= 0&#41;;

	if&#40;isCheck&#41;
		genCheckEvasion&#40;);
	else&#123;
		evalValue = evaluate&#40;);

According to that sample code you wanted to reply "No", right? I see a call to evaluate() only if isCheck is false.

That is correct, but there is a fake check flag here.

Code: Select all

if(depth == 0 && checkMove()) 
    searchValue = -qsearch(-beta, -alpha, depth-1, true); 
else 
    searchValue = -qsearch(-beta, -alpha, depth-1, false); // Faking the check flag 

[Sven]

Are you sure that your qsearch even calls the static evaluation if the side to move is in check?

Yes.

Sample code

Code: Select all

int qsearch(alpha, beta, depth, isCheck)
{
	assert&#40;depth <= 0&#41;;

	if&#40;isCheck&#41;
		genCheckEvasion&#40;);
	else&#123;
		evalValue = evaluate&#40;);

According to that sample code you wanted to reply "No", right? I see a call to evaluate() only if isCheck is false.

That is correct, but there is a fake check flag here.

Code: Select all

if(depth == 0 && checkMove()) 
    searchValue = -qsearch(-beta, -alpha, depth-1, true); 
else 
    searchValue = -qsearch(-beta, -alpha, depth-1, false); // Faking the check flag 

I have seen that. However, if checkMove() returns true if and only if the current move gives check then how does this change anything? You replace the "isMyKingInCheck()" by "does this move give check" but you still do not call the static evaluation in qsearch if you know that the moving side is in check, so there is no "bonus/penalty" topic for being in check. And if the moving side is in check at depth < 0 you ignore that so even here you can't assign an in-check penalty since you are not aware of being in check.

[Ferdy]

Are you sure that your qsearch even calls the static evaluation if the side to move is in check?

Yes.

Sample code

Code: Select all

int qsearch(alpha, beta, depth, isCheck)
{
	assert&#40;depth <= 0&#41;;

	if&#40;isCheck&#41;
		genCheckEvasion&#40;);
	else&#123;
		evalValue = evaluate&#40;);

According to that sample code you wanted to reply "No", right? I see a call to evaluate() only if isCheck is false.

That is correct, but there is a fake check flag here.

Code: Select all

if(depth == 0 && checkMove()) 
    searchValue = -qsearch(-beta, -alpha, depth-1, true); 
else 
    searchValue = -qsearch(-beta, -alpha, depth-1, false); // Faking the check flag 

I have seen that. However, if checkMove() returns true if and only if the current move gives check then how does this change anything? You replace the "isMyKingInCheck()" by "does this move give check" but you still do not call the static evaluation in qsearch if you know that the moving side is in check, so there is no "bonus/penalty" topic for being in check.

Read the code again, there is a situation where the side is in check but was ignored at depth below 0.

And if the moving side is in check at depth < 0 you ignore that so even here you can't assign an in-check penalty since you are not aware of being in check.

The evaluation will detect if your king is under attack thru piece mobility calculation. The penalty will be added to the overall score of the evaluation.

[MahmoudUthman]

One last thing that I don't understand , Some "most?" engines don't count the mobility of the kings and pawns , shouldn't the mobility of pawns be important , for example for two position with the same mobility "based on non pawn material" , shouldn't the one with a higher mobility of pawns be regarded as better assuming they have the same pawn structure ?