Stand Pat penalty

[lucasart]

Here's an idea I'm experimenting with, that seems to work well in DiscoCheck:

1/ hanging pieces

I have a function that calculates hanging pieces (for the side to move), defined as:
* pieces or pawns that are attacked and not defended
* pieces that are attacked by pawns (regardless of defense)

2/ stand pat penalty

* if there are two or more hanging pieces
* take the lowest one and return half its value.

For example, if the hanging pieces are a Knight and a Rook, return value(Knight)/2. If a Bishop and a Pawn, return Value(Pawn)/2, etc.

=> The stand_pat_penalty() is, as the name suggests, used as a penalty for standing pat, both in the quiescent search, and for eval pruning (ie. when evel is much higher than beta, and we are near the leaves in the search).

The rationale is simple:
* if you have one piece hanging, you're probably fine, as it's your turn to play
* but if you have two, you will most likely need to find a tactical escape. this is exactly what this does, as it prevents the search from choosing the stand pat option, and incentivises it to solve the remaining tactics to choose a more quiet position a few plies later.

The definition of hanging pieces can be improved (that one just happenned to be easy to code and runs fast in DiscoCheck). As well as the definition of the stand pat penalty
- perhaps something could also be done for pinned pieces. For example, if the pinner is least valuable than the pinned piece, penalize by half the difference in value of the pieces to push solving the pin rather than standing pat.
- the half value of the lowest hanging piece is a pure guess. have made no attempt to optimize it.

[gladius]

Interesting idea! I've tried quite a few things with weak/hanging pieces in SF, without much success. It seems like there should be much that can be done, because the search does some really silly things. But finding the right recipe is tricky as usual .

[lucasart]

Interesting idea! I've tried quite a few things with weak/hanging pieces in SF, without much success. It seems like there should be much that can be done, because the search does some really silly things. But finding the right recipe is tricky as usual .

I've pushed it to my git repo, so here's the implementation as far as DiscoCheck is concerned:
https://github.com/lucasart/chess/blob/ ... /search.cc
It was a 9 ELO improvement, after 10000 games in 10"+0.1". And that's on top of the large ELO increase I already got from penalizing hanging pieces in the eval. Now I need to try to remove the hanging piece scoring in the eval, and if that passes, it would be really great! there's nothing better than gaining ELO by *removing* eval features.

[gladius]

Interesting idea! I've tried quite a few things with weak/hanging pieces in SF, without much success. It seems like there should be much that can be done, because the search does some really silly things. But finding the right recipe is tricky as usual .

I've pushed it to my git repo, so here's the implementation as far as DiscoCheck is concerned:
https://github.com/lucasart/chess/blob/ ... /search.cc
It was a 9 ELO improvement, after 10000 games in 10"+0.1". And that's on top of the large ELO increase I already got from penalizing hanging pieces in the eval. Now I need to try to remove the hanging piece scoring in the eval, and if that passes, it would be really great! there's nothing better than gaining ELO by *removing* eval features.

Nice gain! I've given it a shot here: http://tests.stockfishchess.org/tests/v ... 7dd8b5f3fa. We shall see how it goes .

[lucasart]

Interesting idea! I've tried quite a few things with weak/hanging pieces in SF, without much success. It seems like there should be much that can be done, because the search does some really silly things. But finding the right recipe is tricky as usual .

I've pushed it to my git repo, so here's the implementation as far as DiscoCheck is concerned:
https://github.com/lucasart/chess/blob/ ... /search.cc
It was a 9 ELO improvement, after 10000 games in 10"+0.1". And that's on top of the large ELO increase I already got from penalizing hanging pieces in the eval. Now I need to try to remove the hanging piece scoring in the eval, and if that passes, it would be really great! there's nothing better than gaining ELO by *removing* eval features.

Nice gain! I've given it a shot here: http://tests.stockfishchess.org/tests/v ... 7dd8b5f3fa. We shall see how it goes .

Something looks wrong in your patch: why do you exclude the case where tte != NULL ?

[Evert]

My initial thoughts are that this is a form of futility pruning/razoring, but I guess you would apply it at the same nodes where you also would do razoring (I know, I could check the code) and so you see the problem a ply or two earlier than you would if you had to resolve the ultimate fail-low of the move that landed you in this position in the first place. Do I understand this correctly?

What is the cause for the strength increase? A more efficient search where problems are spotted earlier? Or does it also help with the horizon effect (because spite-checks do nothing to resolve the penalty)?

Have you tried a search with adjusted alpha/beta window (basically a verification search against the expectation that the piece is lost)? On second thought, maybe that isn't such a sensible thing to try; if you expect the loss of the piece to drop you below alpha, just fail low. If you need something more accurate the search will come back here with a larger window...

[lucasart]

My initial thoughts are that this is a form of futility pruning/razoring, but I guess you would apply it at the same nodes where you also would do razoring (I know, I could check the code) and so you see the problem a ply or two earlier than you would if you had to resolve the ultimate fail-low of the move that landed you in this position in the first place. Do I understand this correctly?

No. It's, as the name suggests, a penalty for standing pat with several pieces hanging. The logic is that if you have a rook and a bishop hanging, then, as it is your turn to play, you will save the rook but lose the bishop. On the other hand that is a very imprecise assumption, so let's half it

What is the cause for the strength increase? A more efficient search where problems are spotted earlier? Or does it also help with the horizon effect (because spite-checks do nothing to resolve the penalty)?

Horizon effect much improved. Now the search (at low depth when eval is good) and the qsearch (when not in check) will not stand pat in stupid positions with several pieces hanging. I was surprised to note that 16% of QS stand pat evals are computed with 2 or more pieces hanging...

Have you tried a search with adjusted alpha/beta window (basically a verification search against the expectation that the piece is lost)? On second thought, maybe that isn't such a sensible thing to try; if you expect the loss of the piece to drop you below alpha, just fail low. If you need something more accurate the search will come back here with a larger window...

No, I haven't tried this. But it seems too costly.

[Evert]

No. It's, as the name suggests, a penalty for standing pat with several pieces hanging. The logic is that if you have a rook and a bishop hanging, then, as it is your turn to play, you will save the rook but lose the bishop. On the other hand that is a very imprecise assumption, so let's half it

But outside of the QS you don't stand pat, so I don't really understand the name then. Unless you only do it in QS, but then you don't generate all evasions anyway. If you just apply it as a correction to the stand-pat score, isn't it simply a side-to-move dependent term in the evaluation?

I would expect most of the (potential) gain from doing this at interior nodes just before the QS, but there you don't do stand pat. You do use razoring and futility pruning, and this sounded like a form of that.

Maybe I should just check the code to get a better idea of what this does...

[gladius]

Nice gain! I've given it a shot here: http://tests.stockfishchess.org/tests/v ... 7dd8b5f3fa. We shall see how it goes .

Something looks wrong in your patch: why do you exclude the case where tte != NULL ?

As we don't call the eval in that case, unless the score is VALUE_NONE, which is incredibly rare. For example, running sf bench, that eval call is never hit.

The stand pat idea didn't make it past stage 1, but adding a bonus to the side that is attacking multiple weak pieces has, which is very nice! With a straight up simple value of 60, 60 as well. Some good potential there for improvement it looks like.

[lucasart]

But outside of the QS you don't stand pat, so I don't really understand the name then.

Yes, I do stand pat in the search, when doing eval pruning near the leaves:

Code: Select all

// Eval pruning
if ( node_type != PV
	&& depth <= 3
	&& !in_check
	&& !is_mate_score(beta)
	&& ss->eval + TEMPO >= beta + EvalMargin[depth]
	&& B.st().piece_psq[B.get_turn()] ) {
	const int stand_pat = ss->eval + TEMPO - stand_pat_penalty(B) - EvalMargin[depth];
	if (stand_pat >= beta)
		return stand_pat;
}

If you just apply it as a correction to the stand-pat score, isn't it simply a side-to-move dependent term in the evaluation?

My eval must remain symmetric. That is why I do this outside the eval (side to move dependant), as well as the Tempo bonus (handled in the search). The reason is that after a null move I can just negate the eval of the parent node, and skip a call to the eval. This is a really big speed gain, and reduces quite significantly the number of eval calls.

EDIT: A couple of other areas where my search stands pat are
- move count pruning
- SEE pruning
I need to try to apply the stand pat penalty there too, and see if it works.