pinned pieces in eval

[Pierre Bokma]

Hi Friends,

I am about to include a pinned and attacked piece term in my evaluation function. I have a question about this feature because i doubt if it is usefull. Therefor maybe some one can tell me if this a usefull feature. I would expect this evaluation never to take place as captures are handled by qsearch. Hence pinnend pieces will be captured before the position will be evaluated. On the other had, this feature might help improve tree ordening?

any toughts on this issue much appreciated

Pierre

[Evert]

I am about to include a pinned and attacked piece term in my evaluation function. I have a question about this feature because i doubt if it is usefull. Therefor maybe some one can tell me if this a usefull feature. I would expect this evaluation never to take place as captures are handled by qsearch. Hence pinnend pieces will be captured before the position will be evaluated. On the other had, this feature might help improve tree ordening?

There may be reasons to call the static evaluation outside the quiescence search. If you do that, then there may be hanging pieces that you should perhaps deal with in the static evaluation. Whether that's not more hassle than it's worth I can't say.
Aside from that, yes, hanging pieces should be dealt with by the quiescence search. Even so, it may pay to give a piece a penalty for being under attack (especially if it has to be defended by a more valuable piece) because it restricts move options for that side and could be considered a (minor) weakness.
The same holds for pinned pieces, which I might just not score for mobility (or for reduced mobility) rather than giving them an explicit penalty.

[hgm]

The side that does not have the move can pin pieces, while the side thathas the move has no captures. And what of the position below?
[d]k2q4/p7/4p3/3r4/4QB2/8/2P3PP/5K2 w

If white is to move, QxR is losing. c2-c4 is a non-capture, and thus not searched in QS. So white will stand pat, and return eval. It would be nice if this position was preferred over those where the Rook was not pinned.

With black to move there is nothing to capture, and we also return eval. But it would be better if black could see from it that had better avoid this position...

[jhaglund]

The side that does not have the move can pin pieces, while the side thathas the move has no captures. And what of the position below?
[d]k2q4/p7/4p3/3r4/4QB2/8/2P3PP/5K2 w

If white is to move, QxR is losing. c2-c4 is a non-capture, and thus not searched in QS. So white will stand pat, and return eval. It would be nice if this position was preferred over those where the Rook was not pinned.

With black to move there is nothing to capture, and we also return eval. But it would be better if black could see from it that had better avoid this position...

The white's queen on e4 is already pinning black's rook on d5, because of the king on the same diagonal. c2-c4 is the preferred move because it's a minor for major piece value exchange (P X R) vs. (Q x R). The queen on e4 pinned the rook to the king and c4 is the killing blow in the initial pin plan. This makes it a support attacker of a pin or blockade.

With Black to move instead, the object would be to avoid or remove the pin on Rd5. In my eyes, moving black's queen to Qa5 would enable more attacking draw chances and able to create a pin or try to keep check+ on white's king... rather than to pin on white's c4 pawn if it were to move there. Drawish game, but it will be hard to defend against white's BPP on the king's side

I wouldn't reinvent the wheel (QS), but come up with something different like levitation. Forget what is already invented and come up with some new innovation.

Adding 100+ conditions statements for your root move selection would be a way better use of evaluations... faced with another neutral position?! Add another condition... there's only so many different situations you can cover. They're rather easy if you understand chess & what progress is to be made.

Code: Select all

c2c4 
[00101011101111011101101010101011010101110111010101]
31 good conditions met
18 good conditions not met

c2c4
[0000000000001001010110001100000000000001]
08 bad conditions met
32 bad conditions not met
-----
89 total conditions

c2c4 &#91;31,18,08,32&#93; <most positive conditions met>
...
c2c3 &#91;...,...,...,...&#93;
f1e2 &#91;...,...,...,...&#93;
f1g1 &#91;...,...,...,...&#93;
...
e4d5&#91;04,45,38,02&#93; <most negative conditions met>

"If everyone stuck with DOS, where would Linux or Windows be?"

Joshua D. Haglund

[Evert]

The side that does not have the move can pin pieces, while the side thathas the move has no captures. And what of the position below?
[d]k2q4/p7/4p3/3r4/4QB2/8/2P3PP/5K2 w

If white is to move, QxR is losing. c2-c4 is a non-capture, and thus not searched in QS. So white will stand pat, and return eval. It would be nice if this position was preferred over those where the Rook was not pinned.

With black to move there is nothing to capture, and we also return eval. But it would be better if black could see from it that had better avoid this position...

This is true. But at some point you have to draw the line between leaving things to the search and doing static detection of dynamical threats. I would think that "false positives" could be a real problem too, if you're not careful.

[hgm]

Well, you should not assume that a pinned Rook will be lost, for sure. But having pinned piece is definitely a weakness, and it will pay to avoid it all other things being equal. So it will definitely be worth some eval points.

[Michel]

Well, you should not assume that a pinned Rook will be lost, for sure. But having pinned piece is definitely a weakness, and it will pay to avoid it all other things being equal. So it will definitely be worth some eval points.

I can confirm this in GNU Chess. Removing the pinned pieces detection made it weaker.

On the other hand removing the hanging pieces detection made it stronger!

[Pierre Bokma]

Thanks Harm,

You convinced me with your example. Pinned pieces will be added this weekend.

Pierre

[Evert]

I can confirm this in GNU Chess. Removing the pinned pieces detection made it weaker.

I don't remember it did much when I tried it in Jazz, but that was a while ago when there were still more things missing in the evaluation, so it could be that it was irrelevant at that point.
Out of curiosity (I know, I could look at the source), do you give a penalty, or do you simply omit mobility information for that piece?

[zamar]

Hi Friends,

I am about to include a pinned and attacked piece term in my evaluation function. I have a question about this feature because i doubt if it is usefull. Therefor maybe some one can tell me if this a usefull feature. I would expect this evaluation never to take place as captures are handled by qsearch. Hence pinnend pieces will be captured before the position will be evaluated. On the other had, this feature might help improve tree ordening?

any toughts on this issue much appreciated

Pierre

Well, I think we should apply a penalty for pinned pieces. But the problem is of course the slowdown of evaluation function, so it likely doesn't pay off.