Side to Move Bonus---does it help?

[govert]

Please correct me if this is irrelevant, but is it not essential to consider whose side it is to move in the following position?

[D] 8/3k3r/8/8/8/8/R3K3/8 w - - 0 1

How does an engine handle this position if it is a leaf?

EDIT: symmetry

[MattieShoes]

If one looks for checks in q-search, it's not really a typical leaf node. If one doesn't, the score is going to be wildly off regardless of side-to-move bonus.

I'm not suggesting a stm bonus is invalid -- I use a small one myself. Just a thought.

[govert]

Sorry, just couldn't resist constructing another one, this time without a check.

[D] 2b5/2k5/1p1q4/8/8/5Q1P/6K1/6B1 b - - 0 1

No more. I promise!

[diep]

Sorry, just couldn't resist constructing another one, this time without a check.

[D] 2b5/2k5/1p1q4/8/8/5Q1P/6K1/6B1 b - - 0 1

No more. I promise!

You follow the nerd approach yes and find a position where
qsearch does not pick up a maximizing sequence. However
qsearch and eval already are total based upon maximizing
sequences.

Look at it from mercilious statistical viewpoint:

[D] 6b1/2k5/1p1q4/8/8/5Q1P/6KB/8 b - - 0 1

With pins that win for the side to move with the pin,
the qsearch will figure that out with its usual maximizing
sequence.

Yet if you don't evaluate pins (note diep does, so would have
no problems here seeing this as a win for white statically)
then there is a lot more positions where giving the bonus is
counterproductive.

It is a heuristic that at least for my evaluation function is too primitive as it is wrong too much.

This aside from the quiescencesearch error it introduces.

I see everyone skip that subject yet it is relevant.

Vincent

[Uri Blass]

I add side to move bonus, but with a limitation: Don't if in-check: Sometimes, quiesce end in a check position, so it is a kind of non-calm position.
Another idea to test is if in-check give the bonus to opponent.

side to move BONUS is too inaccurate as a heuristic to be used IMHO and it is contraproductive for quiscencesearch i feel.

During extensive tests a year or 10 ago performed it lost quite some elo. At that time i did give a 0.10 bonus in non-endgame positions and no bonus in endgame. In endgame giving bonus was losing that much elo that i very soon had to stop it. Note that being in check can never be a leaf in Diep so that's not a problem either.

There is a huge difference IMHO between chessknowledge that nearly always works, like a white bishop on d3 blocking a pawn on d2, versus heuristic that doesn't work in crucial positions where our form of qsearch already fails miserably. We increase in dramatic manner the mistake that qsearch already gives to our search.

Moreover, if we would replace the side to move bonus by mobility for the side to move, it already dramatically would improve the heuristic. Yet that still doesn't solve the fact that asymmetric bonus there is increasing the quiescencesearch error.

Claims that side to move bonus works in actual slower time controls would be amazing to me, as some years ago during tests i wasn't the only one concluding it didn't work for Diep.

As for the claim that it would compensate for the reduction effect, that is of course utter ballony, as you're also giving that bonus in non-reduced lines and transposition cutoffs would mess it up anyway. Additionally to that the bonus in reduced lines would increase the horizon effect that reductions cause.

So i assume that most claims here is by those who test in inaccurate manner or at too fast time controls (anything works then).

Vincent

I do not understand why side to move bonus
has to increase the quiescencesearch error.

If the problem is that you allow it in positions when the opponent has a fork at the end of the qsearch then you can have side to move bonus only in quiet positions when the opponent does not threat to make a good capture.

Note that I understand replacing side to move bonus by mobility as non constant side to move bonus.

I do not know what you do in diep but if null move can change the evaluation in diep then it means that you have side to move bonus in diep.

Every program who has code for king in the square of the pawn practically has a very big side to move bonus in some cases because the program is going to evaluate the following position by static evaluation as winning for the side to move

[D]4k3/pppp4/7P/8/8/8/8/7K w - - 0 1

Uri

[diep]

I add side to move bonus, but with a limitation: Don't if in-check: Sometimes, quiesce end in a check position, so it is a kind of non-calm position.
Another idea to test is if in-check give the bonus to opponent.

side to move BONUS is too inaccurate as a heuristic to be used IMHO and it is contraproductive for quiscencesearch i feel.

During extensive tests a year or 10 ago performed it lost quite some elo. At that time i did give a 0.10 bonus in non-endgame positions and no bonus in endgame. In endgame giving bonus was losing that much elo that i very soon had to stop it. Note that being in check can never be a leaf in Diep so that's not a problem either.

There is a huge difference IMHO between chessknowledge that nearly always works, like a white bishop on d3 blocking a pawn on d2, versus heuristic that doesn't work in crucial positions where our form of qsearch already fails miserably. We increase in dramatic manner the mistake that qsearch already gives to our search.

Moreover, if we would replace the side to move bonus by mobility for the side to move, it already dramatically would improve the heuristic. Yet that still doesn't solve the fact that asymmetric bonus there is increasing the quiescencesearch error.

Claims that side to move bonus works in actual slower time controls would be amazing to me, as some years ago during tests i wasn't the only one concluding it didn't work for Diep.

As for the claim that it would compensate for the reduction effect, that is of course utter ballony, as you're also giving that bonus in non-reduced lines and transposition cutoffs would mess it up anyway. Additionally to that the bonus in reduced lines would increase the horizon effect that reductions cause.

So i assume that most claims here is by those who test in inaccurate manner or at too fast time controls (anything works then).

Vincent

I do not understand why side to move bonus
has to increase the quiescencesearch error.

If the problem is that you allow it in positions when the opponent has a fork at the end of the qsearch then you can have side to move bonus only in quiet positions when the opponent does not threat to make a good capture.

Note that I understand replacing side to move bonus by mobility as non constant side to move bonus.

I do not know what you do in diep but if null move can change the evaluation in diep then it means that you have side to move bonus in diep.

Every program who has code for king in the square of the pawn practically has a very big side to move bonus in some cases because the program is going to evaluate the following position by static evaluation as winning for the side to move

[D]4k3/pppp4/7P/8/8/8/8/7K w - - 0 1

Uri

i'm not sure why you show up with yet another endgame position or tactical examples.

a) in endgame it totally doesn't work
b) a 0.05 to 0.10 bonus for sure doesn't fall into the tactical domain, but rather positional domain.

It is very difficult to explain already to authors of their own engine why something works or doesn't work. Evaluation is a very complicated subject.

In your case i'd say that's why you wrote your own engine isn't it?

I mean of course to say: you can just test it in your case very well. Test using the same conditions and take care there is no booklearning used, so you can't use the fritz interface.

Vincent

[wgarvin]

Suppose the actual end of the game is N moves in the future. The player with the move gets to move ceil(N/2) times, while the player without the move only gets to move floor(N/2) more times. If you average this out over a lot of game positions in a lot of situations where all other things are about equal (e.g. no zugzwang, material and positional strength about equal, etc), then on average, the player with the move would have slightly more opportunity to positively affect the outcome of the game by his choice of moves. Or at least, a slightly better chance of preventing his opponent from getting an advantage.

I am convinced it works, because I tested it exhaustively. It is not a huge gain, but it is measurable. The values we use in Crafty were tuned on the cluster and made a measurable improvement. we are not talking +10 elo here, more like +4-5 max. But anything + is good if you get enough of them.

You mentioned a small value for the bonus in Crafty (somewhere between +5 in middlegame and +8 in the endgame, for the side to move).

Since on one ply you give this bonus to white, and on the next ply you give it to black, that means Crafty values having the move vs. not having it at something between 10 to 16 points.

If you play without this bonus, how big is the odd-even effect from standing pat? I bet that it averages out to something in the 10 to 16 range. If true, it seems that a well-tuned side-to-move bonus would mostly mitigate the odd-even effect, leading to the smaller tree sizes.

[Uri Blass]

I add side to move bonus, but with a limitation: Don't if in-check: Sometimes, quiesce end in a check position, so it is a kind of non-calm position.
Another idea to test is if in-check give the bonus to opponent.

side to move BONUS is too inaccurate as a heuristic to be used IMHO and it is contraproductive for quiscencesearch i feel.

During extensive tests a year or 10 ago performed it lost quite some elo. At that time i did give a 0.10 bonus in non-endgame positions and no bonus in endgame. In endgame giving bonus was losing that much elo that i very soon had to stop it. Note that being in check can never be a leaf in Diep so that's not a problem either.

There is a huge difference IMHO between chessknowledge that nearly always works, like a white bishop on d3 blocking a pawn on d2, versus heuristic that doesn't work in crucial positions where our form of qsearch already fails miserably. We increase in dramatic manner the mistake that qsearch already gives to our search.

Moreover, if we would replace the side to move bonus by mobility for the side to move, it already dramatically would improve the heuristic. Yet that still doesn't solve the fact that asymmetric bonus there is increasing the quiescencesearch error.

Claims that side to move bonus works in actual slower time controls would be amazing to me, as some years ago during tests i wasn't the only one concluding it didn't work for Diep.

As for the claim that it would compensate for the reduction effect, that is of course utter ballony, as you're also giving that bonus in non-reduced lines and transposition cutoffs would mess it up anyway. Additionally to that the bonus in reduced lines would increase the horizon effect that reductions cause.

So i assume that most claims here is by those who test in inaccurate manner or at too fast time controls (anything works then).

Vincent

I do not understand why side to move bonus
has to increase the quiescencesearch error.

If the problem is that you allow it in positions when the opponent has a fork at the end of the qsearch then you can have side to move bonus only in quiet positions when the opponent does not threat to make a good capture.

Note that I understand replacing side to move bonus by mobility as non constant side to move bonus.

I do not know what you do in diep but if null move can change the evaluation in diep then it means that you have side to move bonus in diep.

Every program who has code for king in the square of the pawn practically has a very big side to move bonus in some cases because the program is going to evaluate the following position by static evaluation as winning for the side to move

[D]4k3/pppp4/7P/8/8/8/8/7K w - - 0 1

Uri

i'm not sure why you show up with yet another endgame position or tactical examples.

a) in endgame it totally doesn't work
b) a 0.05 to 0.10 bonus for sure doesn't fall into the tactical domain, but rather positional domain.

It is very difficult to explain already to authors of their own engine why something works or doesn't work. Evaluation is a very complicated subject.

In your case i'd say that's why you wrote your own engine isn't it?

I mean of course to say: you can just test it in your case very well. Test using the same conditions and take care there is no booklearning used, so you can't use the fritz interface.

Vincent

Movei in most cases does not have bonus for the side to move(I say in most cases because movei has some evaluation for unstoppable passed pawn that is also based on the side to move so it is not in all cases)

I did not test adding a constant bonus for the side to move.
I clearly thought that simple constant bonus may be counter productive for the simple reasons that positions are not random(not sure about it) but even if it is counter productive it does not mean that a bonus is always counter productive.

The reason that the bonus may be counter productive is the fact that there is no symmetry in the position that are evaluated


[D]6k1/8/8/8/4r1r1/5P2/PPP5/2KR4 b - - 0 1

Let say that
White to move wins +4.2 pawns
black to move lose 3.8 pawns.

The average is 0.2 pawns if both positions can be evaluated as leaf nodes but the fact that white to move is never evaluated as leaf node reduce the average and if you include only leaf positions then I am not sure if the average is positive.

Of course if you evaluate the position as non quiet position then you can decide not to give it bonus for side to move in both cases and I suspect that in this case a bonus for the side to move may be more productive.

Uri

[bob]

Suppose the actual end of the game is N moves in the future. The player with the move gets to move ceil(N/2) times, while the player without the move only gets to move floor(N/2) more times. If you average this out over a lot of game positions in a lot of situations where all other things are about equal (e.g. no zugzwang, material and positional strength about equal, etc), then on average, the player with the move would have slightly more opportunity to positively affect the outcome of the game by his choice of moves. Or at least, a slightly better chance of preventing his opponent from getting an advantage.

I am convinced it works, because I tested it exhaustively. It is not a huge gain, but it is measurable. The values we use in Crafty were tuned on the cluster and made a measurable improvement. we are not talking +10 elo here, more like +4-5 max. But anything + is good if you get enough of them.

You mentioned a small value for the bonus in Crafty (somewhere between +5 in middlegame and +8 in the endgame, for the side to move).

Since on one ply you give this bonus to white, and on the next ply you give it to black, that means Crafty values having the move vs. not having it at something between 10 to 16 points.

If you play without this bonus, how big is the odd-even effect from standing pat? I bet that it averages out to something in the 10 to 16 range. If true, it seems that a well-tuned side-to-move bonus would mostly mitigate the odd-even effect, leading to the smaller tree sizes.

I don't believe this is an odd-even effect at all. By the time we get to the tips of the tree, we have extended and reduced any number of moves. The odd/even effect was seen when nominal search depth increased by 1 for most moves. Nowadays that seems to not be an issue that I can tell.

For example, In watching search output, I don't see the score for the best move jumping up and down iteration by iteration...

[bob]

I add side to move bonus, but with a limitation: Don't if in-check: Sometimes, quiesce end in a check position, so it is a kind of non-calm position.
Another idea to test is if in-check give the bonus to opponent.

side to move BONUS is too inaccurate as a heuristic to be used IMHO and it is contraproductive for quiscencesearch i feel.

During extensive tests a year or 10 ago performed it lost quite some elo. At that time i did give a 0.10 bonus in non-endgame positions and no bonus in endgame. In endgame giving bonus was losing that much elo that i very soon had to stop it. Note that being in check can never be a leaf in Diep so that's not a problem either.

There is a huge difference IMHO between chessknowledge that nearly always works, like a white bishop on d3 blocking a pawn on d2, versus heuristic that doesn't work in crucial positions where our form of qsearch already fails miserably. We increase in dramatic manner the mistake that qsearch already gives to our search.

Moreover, if we would replace the side to move bonus by mobility for the side to move, it already dramatically would improve the heuristic. Yet that still doesn't solve the fact that asymmetric bonus there is increasing the quiescencesearch error.

Claims that side to move bonus works in actual slower time controls would be amazing to me, as some years ago during tests i wasn't the only one concluding it didn't work for Diep.

As for the claim that it would compensate for the reduction effect, that is of course utter ballony, as you're also giving that bonus in non-reduced lines and transposition cutoffs would mess it up anyway. Additionally to that the bonus in reduced lines would increase the horizon effect that reductions cause.

So i assume that most claims here is by those who test in inaccurate manner or at too fast time controls (anything works then).

Vincent

When Tracy suggested doing the STM bonus in Crafty, I tested it at several time controls, up to 30+30 which is about as far as I go unless I really believe something is time/depth sensitive. It is not a big winner at all, but it was worth about +5 elo at all time controls we tested at. Going beyond 5 in the MG began to hurt a very small bit. And we zeroed in on +8 for the endgame (note that this is really a +10 and +16 bonus since one side of the other gets it depending on who is to move. That is, if it is wtm it gets +5, if btm, -5.