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
pinned pieces in eval
Moderators: hgm, Rebel, chrisw
-
- Posts: 31
- Joined: Tue Dec 07, 2010 11:19 pm
- Location: Holland
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: pinned pieces in eval
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.Pierre Bokma wrote: 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?
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.
-
- Posts: 27796
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: pinned pieces in eval
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...
[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...
-
- Posts: 173
- Joined: Sun May 11, 2008 7:43 am
Re: pinned pieces in eval
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.hgm wrote: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...
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 [31,18,08,32] <most positive conditions met>
...
c2c3 [...,...,...,...]
f1e2 [...,...,...,...]
f1g1 [...,...,...,...]
...
e4d5[04,45,38,02] <most negative conditions met>
Joshua D. Haglund
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: pinned pieces in eval
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 wrote: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...
-
- Posts: 27796
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: pinned pieces in eval
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.
-
- Posts: 2272
- Joined: Mon Sep 29, 2008 1:50 am
Re: pinned pieces in eval
I can confirm this in GNU Chess. Removing the pinned pieces detection made it weaker.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.
On the other hand removing the hanging pieces detection made it stronger!
-
- Posts: 31
- Joined: Tue Dec 07, 2010 11:19 pm
- Location: Holland
Re: pinned pieces in eval
Thanks Harm,
You convinced me with your example. Pinned pieces will be added this weekend.
Pierre
You convinced me with your example. Pinned pieces will be added this weekend.
Pierre
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: pinned pieces in eval
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.Michel wrote: I can confirm this in GNU Chess. Removing the pinned pieces detection made it weaker.
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?
-
- Posts: 613
- Joined: Sun Jan 18, 2009 7:03 am
Re: pinned pieces in eval
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.Pierre Bokma wrote: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
Joona Kiiski