Evaluating attacked pieces

[Kempelen]

Does has sense to evaluate in eval function samething like this: (for a black piece being in sq):

Code: Select all

if (is_attacked[WHITE,sq] && !is_attacked[BLACK,sq]) { //Black piece attacked and not defended
   if (turn == BLACK) {
            evalBlack -= HANGING_PIECE_PENALTY / 2;
   } else {
            evalBlack -= HANGING_PIECE_PENALTY;
   }
}

As I understand, this kind of code is not necesary because the quiesce function search and evaluate this, but maybe the eval function can take into accound this. do you think this could be valuable?? is it in conflict with quiesce?

Thanks,
Fermin

P.S.: in my tests I have not seen any improvement, but that does not necesary mean it couldn't be valuabe for others....

[bob]

Does has sense to evaluate in eval function samething like this: (for a black piece being in sq):

Code: Select all

if (is_attacked[WHITE,sq] && !is_attacked[BLACK,sq]) { //Black piece attacked and not defended
   if (turn == BLACK) {
            evalBlack -= HANGING_PIECE_PENALTY / 2;
   } else {
            evalBlack -= HANGING_PIECE_PENALTY;
   }
}

As I understand, this kind of code is not necesary because the quiesce function search and evaluate this, but maybe the eval function can take into accound this. do you think this could be valuable?? is it in conflict with quiesce?

Thanks,
Fermin

P.S.: in my tests I have not seen any improvement, but that does not necesary mean it couldn't be valuabe for others....

It isn't "in conflict" but it is definitely redundant. And less accurate. Quiesce notices that the piece defending something is "overloaded" because once it participates in a capture over here, we can now make a winning capture over there somewhere. This simplistic hanging-piece term doesn't consider anything,such as is the defender or attacker pinned, overloaded, guarding a critical square, etc...

[Sven]

You might get "false positives" as well as "false negatives" with this approach. In addition to what Bob states, you might probably also miss a couple of cases where a defended piece is hanging since the attacker is a minor piece, or since you have more attackers than defenders, or for other reasons. So I also think this would be too inaccurate.

I have tried statically evaluating hanging pieces in the past, too, and I did not get any improvement from it. What I also tried, with the same kind of zero improvement, was to extend the full search at a horizon node when the side to move has at least two "really" hanging pieces. This failed for me since I did not find (at that time in the past) a satisfying and efficient way to safely determine hanging pieces, and since my non-satisfying way caused too many huge extensions which slowed down the search. So I skipped the approach. Maybe it is worth nothing even with an efficient implementation.

Today I think that one should rely mostly on qsearch with the help of SEE to analyze that kind of tactics.

Sven

[Kempelen]

I see. Due to this I was thinking about checks in quiesce. In Rodin, I limit the amount of checks the quiesce function can run. Becuase this I have seen my eval function evaluating check positions. Similar to a bonus for having the move, has any sense to give a malus to the checked side?

It looks to me that it could be a good idea, as a check position is forced and other considerations, like piece mobility, loss a little value.

what your opinion about check in evals?

best wishes
Fermin

[bob]

I see. Due to this I was thinking about checks in quiesce. In Rodin, I limit the amount of checks the quiesce function can run. Becuase this I have seen my eval function evaluating check positions. Similar to a bonus for having the move, has any sense to give a malus to the checked side?

It looks to me that it could be a good idea, as a check position is forced and other considerations, like piece mobility, loss a little value.

what your opinion about check in evals?

best wishes
Fermin

Not quite sure what you mean by "check in evals?" I currently do one layer of checks in the q-search at the frontier. I have not tried (yet) to tune this, as it was really intended as a defense to null-move failures where a null-move collapses the remainder of the search directly into the q-search where there is a strong mate-threat that will be overlooked... Clearly evaluating positions statically when one side is in check is an issue, but currently I ignore this and hope that the base search will work out enough tactics to make this work out...

[Kempelen]

I see. Due to this I was thinking about checks in quiesce. In Rodin, I limit the amount of checks the quiesce function can run. Becuase this I have seen my eval function evaluating check positions. Similar to a bonus for having the move, has any sense to give a malus to the checked side?

It looks to me that it could be a good idea, as a check position is forced and other considerations, like piece mobility, loss a little value.

what your opinion about check in evals?

best wishes
Fermin

Not quite sure what you mean by "check in evals?" I currently do one layer of checks in the q-search at the frontier. I have not tried (yet) to tune this, as it was really intended as a defense to null-move failures where a null-move collapses the remainder of the search directly into the q-search where there is a strong mate-threat that will be overlooked... Clearly evaluating positions statically when one side is in check is an issue, but currently I ignore this and hope that the base search will work out enough tactics to make this work out...

Not sure is a Null move issue. Let me explain again. When in quiesce, let say after 2 ply of frontier node, we look at a capture that lead to check. The first thing in the next quiesce call is to evaluate to see if stand-pat, so what I think is it could be useful to eval that position with a little plus becuase is a forced one. Don't know if this idea have been seen before.

[bob]

I see. Due to this I was thinking about checks in quiesce. In Rodin, I limit the amount of checks the quiesce function can run. Becuase this I have seen my eval function evaluating check positions. Similar to a bonus for having the move, has any sense to give a malus to the checked side?

It looks to me that it could be a good idea, as a check position is forced and other considerations, like piece mobility, loss a little value.

what your opinion about check in evals?

best wishes
Fermin

Not quite sure what you mean by "check in evals?" I currently do one layer of checks in the q-search at the frontier. I have not tried (yet) to tune this, as it was really intended as a defense to null-move failures where a null-move collapses the remainder of the search directly into the q-search where there is a strong mate-threat that will be overlooked... Clearly evaluating positions statically when one side is in check is an issue, but currently I ignore this and hope that the base search will work out enough tactics to make this work out...

Not sure is a Null move issue. Let me explain again. When in quiesce, let say after 2 ply of frontier node, we look at a capture that lead to check. The first thing in the next quiesce call is to evaluate to see if stand-pat, so what I think is it could be useful to eval that position with a little plus becuase is a forced one. Don't know if this idea have been seen before.

I have not tried that myself.

[Harald Johnsen]

Not sure is a Null move issue. Let me explain again. When in quiesce, let say after 2 ply of frontier node, we look at a capture that lead to check. The first thing in the next quiesce call is to evaluate to see if stand-pat, so what I think is it could be useful to eval that position with a little plus becuase is a forced one. Don't know if this idea have been seen before.

I think that we usually don't stand pat when in check. So the evaluation of a position with a king in check is never used.

HJ.

[bob]

Not sure is a Null move issue. Let me explain again. When in quiesce, let say after 2 ply of frontier node, we look at a capture that lead to check. The first thing in the next quiesce call is to evaluate to see if stand-pat, so what I think is it could be useful to eval that position with a little plus becuase is a forced one. Don't know if this idea have been seen before.

I think that we usually don't stand pat when in check. So the evaluation of a position with a king in check is never used.

HJ.

I suspect most engines do not know they are "in check" in the qsearch, beyond the first couple of plies...

[Kempelen]

I suspect most engines do not know they are "in check" in the qsearch, beyond the first couple of plies...

I have been reading a few engine's code and it confirms you that many engines do not know they are "in check" in that situations.