Side to Move Bonus---does it help?

[MattieShoes]

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

Do you look at the low plies? Crafty hides the first several ply if I remember right... In my own engine, I see the odd-even score effect very clearly in the first 4-6 plies (particularly in the opening), but it disappears by the time it gets to normal search depths of 8+ ply.

Not that it makes any difference for this discussion, I was just curious.

[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

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.

Maybe there is a confusion of effects.

Last 3 ply nullmove gives a cutoff in roughly 70% of the cases (depending upon position of course).

So the vaste majority of leaves you now make it 10 points harder in majority of cases to cutoff.

That limits the effect of the supernullmove created by massive reductions a little bit.

Maybe retest with a normal search and just that nullmove by qsearch demand a window of 10 points above beta to cutoff and see how that plays.

Vincent

[jarkkop]

put at Crafty's console

noise 1

and you see all

[bob]

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

Do you look at the low plies? Crafty hides the first several ply if I remember right... In my own engine, I see the odd-even score effect very clearly in the first 4-6 plies (particularly in the opening), but it disappears by the time it gets to normal search depths of 8+ ply.

Not that it makes any difference for this discussion, I was just curious.

I always see those because my development .craftyrc has "noise 0" in it so that I can see everything from ply 1 on.

Early plies might show this behavior since there are fewer opportunities for extensions and reductions. But the later iterations are the ones that count the most, of course.

[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.

Maybe there is a confusion of effects.

Last 3 ply nullmove gives a cutoff in roughly 70% of the cases (depending upon position of course).

So the vaste majority of leaves you now make it 10 points harder in majority of cases to cutoff.

That limits the effect of the supernullmove created by massive reductions a little bit.

Maybe retest with a normal search and just that nullmove by qsearch demand a window of 10 points above beta to cutoff and see how that plays.

Vincent

Why would I care? If the STM bonus improves play, when added to the complete program, then it seems obvious that it should be kept. Whether it is helping because of aggressive null-move or whatever doesn't matter. I'm not testing on positons, I'm testing on games, which gives this change a chance to fail somewhere between the opening and the endgame (and we use no books in the testing either)...

[MattieShoes]

Why would I care? If the STM bonus improves play, when added to the complete program, then it seems obvious that it should be kept. Whether it is helping because of aggressive null-move or whatever doesn't matter. I'm not testing on positons, I'm testing on games, which gives this change a chance to fail somewhere between the opening and the endgame (and we use no books in the testing either)...

That's an interesting idea though -- if it's playing stronger because it's effectively doing a more aggressive null move scheme, would simply searching for nulls with a shifted window and removing the STM bonus get the same result? Have you ever run a test shifting the null window around to see if perhaps beta-1, beta isn't ideal?

[bob]

Why would I care? If the STM bonus improves play, when added to the complete program, then it seems obvious that it should be kept. Whether it is helping because of aggressive null-move or whatever doesn't matter. I'm not testing on positons, I'm testing on games, which gives this change a chance to fail somewhere between the opening and the endgame (and we use no books in the testing either)...

That's an interesting idea though -- if it's playing stronger because it's effectively doing a more aggressive null move scheme, would simply searching for nulls with a shifted window and removing the STM bonus get the same result? Have you ever run a test shifting the null window around to see if perhaps beta-1, beta isn't ideal?

Yes, although I have not done this in any cluster testing. I can certainly test it easily enough. Might prove to be interesting. Stand by.

[michiguel]

Why would I care? If the STM bonus improves play, when added to the complete program, then it seems obvious that it should be kept. Whether it is helping because of aggressive null-move or whatever doesn't matter. I'm not testing on positons, I'm testing on games, which gives this change a chance to fail somewhere between the opening and the endgame (and we use no books in the testing either)...

That's an interesting idea though -- if it's playing stronger because it's effectively doing a more aggressive null move scheme, would simply searching for nulls with a shifted window and removing the STM bonus get the same result? Have you ever run a test shifting the null window around to see if perhaps beta-1, beta isn't ideal?

I tested exactly this some time ago and it did not work for me. However, this may be very dependent on the program.

Miguel

[diep]

Why would I care? If the STM bonus improves play, when added to the complete program, then it seems obvious that it should be kept. Whether it is helping because of aggressive null-move or whatever doesn't matter. I'm not testing on positons, I'm testing on games, which gives this change a chance to fail somewhere between the opening and the endgame (and we use no books in the testing either)...

That's an interesting idea though -- if it's playing stronger because it's effectively doing a more aggressive null move scheme, would simply searching for nulls with a shifted window and removing the STM bonus get the same result? Have you ever run a test shifting the null window around to see if perhaps beta-1, beta isn't ideal?

it's searching with a LESS agressive nullmove.

It is in most nodes similar to nullmove with window [eval+S,eval+S+1]
Might you have a move yourself after that obviously the window reverses.

Note this is nothing new. In diep i'm using up to half a pawn margin sometimes for nullmove with qsearch for S. I'm not giving a side to move bonus though (of course).

[bob]

Why would I care? If the STM bonus improves play, when added to the complete program, then it seems obvious that it should be kept. Whether it is helping because of aggressive null-move or whatever doesn't matter. I'm not testing on positons, I'm testing on games, which gives this change a chance to fail somewhere between the opening and the endgame (and we use no books in the testing either)...

That's an interesting idea though -- if it's playing stronger because it's effectively doing a more aggressive null move scheme, would simply searching for nulls with a shifted window and removing the STM bonus get the same result? Have you ever run a test shifting the null window around to see if perhaps beta-1, beta isn't ideal?

it's searching with a LESS agressive nullmove.

It is in most nodes similar to nullmove with window [eval+S,eval+S+1]
Might you have a move yourself after that obviously the window reverses.

Note this is nothing new. In diep i'm using up to half a pawn margin sometimes for nullmove with qsearch for S. I'm not giving a side to move bonus though (of course).

Could be more aggressive if you search with b-N-1 and b-N. I am testing several values of N right now from 50 to 0 just to see what the effect is.