Side to Move Bonus---does it help?

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

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.

You can try it, however the side to move bonus is doing this:

In roughly 70% of cases qsearch nullmove will give a cutoff.
Let's assume we give 10 points bonus for side to move.

What happens in such positions P is this:

1. P (side) ==> [alpha,alpha+1]
2. nullmove in P going to qsearch
3. P' (xside) ==> [-alpha-1,-alpha]
if we now consider static evaluation E which gets raised 10 points:
if( E+10 >= -alpha ) then cutoff

This is equivalent with E >= -alpha-10

Or with negamax that's alpha+10 in position P(side)

In short for the first and most important call to qsearch in that qsearch 'root' it's similar to nullmove with a window in position P of [alpha+10,alpha+11]

Now it is of course HARDER to get a cutoff with a nullmove of alpha+10 than trying to find a cutoff above alpha.

In short giving a side to move bonus main effect is making it positional a tad harder for your nullmove to cutoff.

As i explained before i'm already using that for a long period of time. Sometimes i turn it off sometimes i turn it on. There is advantages and there is disadvantages.

At short time controls it has advantages doing it for sure. At longer time controls i'm not so sure.

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

You can try it, however the side to move bonus is doing this:

In roughly 70% of cases qsearch nullmove will give a cutoff.
Let's assume we give 10 points bonus for side to move.

What happens in such positions P is this:

1. P (side) ==> [alpha,alpha+1]
2. nullmove in P going to qsearch
3. P' (xside) ==> [-alpha-1,-alpha]
if we now consider static evaluation E which gets raised 10 points:
if( E+10 >= -alpha ) then cutoff

This is equivalent with E >= -alpha-10

Or with negamax that's alpha+10 in position P(side)

In short for the first and most important call to qsearch in that qsearch 'root' it's similar to nullmove with a window in position P of [alpha+10,alpha+11]

Now it is of course HARDER to get a cutoff with a nullmove of alpha+10 than trying to find a cutoff above alpha.

In short giving a side to move bonus main effect is making it positional a tad harder for your nullmove to cutoff.

As i explained before i'm already using that for a long period of time. Sometimes i turn it off sometimes i turn it on. There is advantages and there is disadvantages.

At short time controls it has advantages doing it for sure. At longer time controls i'm not so sure.

I am not sure I buy that description. First, only key endpoint values get backed up to make the null-move fail high. How can we know whether those endpoints are all wtm, all btm, or some mixture? If it is a mixture, then the score is getting offset up and down depending on this. I am not sure how that equates to a pure null-move search with a window that has been artificially lowered (fails high more often) or artificially raised (fails high less often). Since the window will affect every search done below the null-move, in the same way, while the STM bonus is erratic in which positions get +5 or -5...

[mcostalba]

You can try it, however the side to move bonus is doing this:

In roughly 70% of cases qsearch nullmove will give a cutoff.
Let's assume we give 10 points bonus for side to move.

What happens in such positions P is this:

1. P (side) ==> [alpha,alpha+1]
2. nullmove in P going to qsearch
3. P' (xside) ==> [-alpha-1,-alpha]
if we now consider static evaluation E which gets raised 10 points:
if( E+10 >= -alpha ) then cutoff

This is equivalent with E >= -alpha-10

Or with negamax that's alpha+10 in position P(side)

In short for the first and most important call to qsearch in that qsearch 'root' it's similar to nullmove with a window in position P of [alpha+10,alpha+11]

Now it is of course HARDER to get a cutoff with a nullmove of alpha+10 than trying to find a cutoff above alpha.

I think in your explanation there is a bit of ambiguity, you say cutoff, but actually we have two cutoffs: P (side) cutoff and P' (side) cutoff.

so disambiguating the above we have

if( E+10 >= -alpha ) then P' (side) cutoff

Instead the next sentence can be rewritten as:

Now it is of course HARDER to get a P (side) cutoff with a nullmove of alpha+10 than trying to find a cutoff above alpha.

So your claim is : because is easier for P' (side) to reach a cut off it implicates that it is harder for P (side) to reach a cut off. But I don't think is the case, at least is not so evident.

The point is that when you write:

This is equivalent with E >= -alpha-10

It should be instead written

This is LOCALLY equivalent with E >= -alpha-10


This interpretation of stm bonus as a modified alpha value is valid only locally, in the current ply, but cannot be propagated at the below or upper nodes: alpha is always alpha, it does not change, it is only easier for P' to reach a cut off because stm gives an extra kick, but this is local to P' (side) ply, it does not imply that is harder for P (side) to reach a totally unrelated cutoff on a different move played at a different ply....actually it is easier ALSO for P (side) to reach a cut off because at the next ply we will have:

if( E+10 >= -alpha ) then P (side) cutoff

So stm bonus helps to reach a cut off indipendentley (it means on different moves played at diferent plies) to BOTH sides. This is completly different than changing in ONE direction (as example increasing) the value of alpha.

I don't know if I have been clear, please correct me if I am wrong.

Thanks
Marco

[bob]

You can try it, however the side to move bonus is doing this:

In roughly 70% of cases qsearch nullmove will give a cutoff.
Let's assume we give 10 points bonus for side to move.

What happens in such positions P is this:

1. P (side) ==> [alpha,alpha+1]
2. nullmove in P going to qsearch
3. P' (xside) ==> [-alpha-1,-alpha]
if we now consider static evaluation E which gets raised 10 points:
if( E+10 >= -alpha ) then cutoff

This is equivalent with E >= -alpha-10

Or with negamax that's alpha+10 in position P(side)

In short for the first and most important call to qsearch in that qsearch 'root' it's similar to nullmove with a window in position P of [alpha+10,alpha+11]

Now it is of course HARDER to get a cutoff with a nullmove of alpha+10 than trying to find a cutoff above alpha.

I think in your explanation there is a bit of ambiguity, you say cutoff, but actually we have two cutoffs: P (side) cutoff and P' (side) cutoff.

so disambiguating the above we have

if( E+10 >= -alpha ) then P' (side) cutoff

Instead the next sentence can be rewritten as:

Now it is of course HARDER to get a P (side) cutoff with a nullmove of alpha+10 than trying to find a cutoff above alpha.

So your claim is : because is easier for P' (side) to reach a cut off it implicates that it is harder for P (side) to reach a cut off. But I don't think is the case, at least is not so evident.

The point is that when you write:

This is equivalent with E >= -alpha-10

It should be instead written

This is LOCALLY equivalent with E >= -alpha-10


This interpretation of stm bonus as a modified alpha value is valid only locally, in the current ply, but cannot be propagated at the below or upper nodes: alpha is always alpha, it does not change, it is only easier for P' to reach a cut off because stm gives an extra kick, but this is local to P' (side) ply, it does not imply that is harder for P (side) to reach a totally unrelated cutoff on a different move played at a different ply....actually it is easier ALSO for P (side) to reach a cut off because at the next ply we will have:

if( E+10 >= -alpha ) then P (side) cutoff

So stm bonus helps to reach a cut off indipendentley (it means on different moves played at diferent plies) to BOTH sides. This is completly different than changing in ONE direction (as example increasing) the value of alpha.

I don't know if I have been clear, please correct me if I am wrong.

Thanks
Marco

I believe conceptually you are on the right track. The offset NM window is a different animal from a STM bonus unless you do no extensions or reductions at all to have a consistent depth.

I have been running an offset NM experiment so that we would have some real data for discussion. Here's what I have so far:

Code: Select all

   3 Crafty-23.1R05-0    2611    4    5 31128   51%  2601   25% 
   4 Crafty-23.1-1       2608    5    5 31128   51%  2601   25% 
   5 Crafty-23.1R05-5    2607    4    4 31128   51%  2601   25% 
   6 Crafty-23.1R05--5   2605    4    4 31128   50%  2601   25% 
   7 Crafty-23.1R05-10   2603    5    4 31128   50%  2601   25% 
   8 Crafty-23.1R05--10  2601    4    4 31128   50%  2601   25% 
   9 Crafty-23.0-1       2595    4    4 31128   50%  2601   24% 
  10 Crafty-23.1R05      2596   10   10  3342   49%  2600   25% 
  11 Crafty-23.1R05--20  2590    4    4 31128   48%  2601   24% 
  12 Crafty-23.1R05--30  2574    4    4 31128   46%  2601   25% 

Crafty-23.0-1 is the released version of 23.0. Crafty-23.1-1 is the latest 23.1 version. The R05 versions are 23.1, but with the change to make the null-move window offset work. The number after the R05 is the offset. So 23.1R05-0 is no offset at all, 23.1R05-10 offsets the NM window 10 centipawns upward, while 23.1R05--20 offsets the NM window -20, downward. the +20 and +30 are still running (the Crafty-23.1R05 without the -nn is an "in progress" test where the name will be changed in all the PGN files after the test completes).

Offsetting up or down by an equal amount seems to change the skill by the same amount. The + offsets make it harder for the NM search to fail high, the - offsets make it easier or more likely...

More when this is finished.

[Don]

Where is your mathematical proof that mobility works? Most programs use mobility because it seems to work well with their programs as decided by emperical tests. But mobility is just like every other evaluation feature, it's only a crude approximation of the goodness of some aspect of the position. Which means it is wrong sometimes.

I'm also not sure how mobility tells you that it's better to be on the move than not on the move. You are evaluating the same position, unless of course your evaluation takes into consideration who's turn to move it is, in which case you pretty much have implemented the side to move bonus via a different mechanism.

I think almost every strong program has a small side to move bonus including Rybka, a program much stronger than yours.

In simple terms mobility works because the more squares a piece can get to the more likely it is to be useful. The piece values we give pieces are very close in ratio to the long term mobility of the pieces. The long term mobility having a close ratio to the piece values should have been common sense but I went the rout of several gigs of log files to figure it out instead. The data from the log files is evidence, to me at least, on why mobility works. The thousands of games people have played with many engines using mobility is proof that it does work. The side to move bonus is an assumption that is somewhat right more often than not. It is a short term tempo fix waiting for a better solution.

I have no doubt that mobility "works", I'm not arguing against it. I'm just pointing out there is no formal proof of it in answer to Vincent. It's just like the stand pat bonus, sometimes the mobility of a piece is totally irelevant, such as when you are getting checkmated so like any other evaluation feature it's a an approximation of something.

[MattieShoes]

Where is your mathematical proof that mobility works? Most programs use mobility because it seems to work well with their programs as decided by emperical tests. But mobility is just like every other evaluation feature, it's only a crude approximation of the goodness of some aspect of the position. Which means it is wrong sometimes.

I'm also not sure how mobility tells you that it's better to be on the move than not on the move. You are evaluating the same position, unless of course your evaluation takes into consideration who's turn to move it is, in which case you pretty much have implemented the side to move bonus via a different mechanism.

I think almost every strong program has a small side to move bonus including Rybka, a program much stronger than yours.

In simple terms mobility works because the more squares a piece can get to the more likely it is to be useful. The piece values we give pieces are very close in ratio to the long term mobility of the pieces. The long term mobility having a close ratio to the piece values should have been common sense but I went the rout of several gigs of log files to figure it out instead. The data from the log files is evidence, to me at least, on why mobility works. The thousands of games people have played with many engines using mobility is proof that it does work. The side to move bonus is an assumption that is somewhat right more often than not. It is a short term tempo fix waiting for a better solution.

I have no doubt that mobility "works", I'm not arguing against it. I'm just pointing out there is no formal proof of it in answer to Vincent. It's just like the stand pat bonus, sometimes the mobility of a piece is totally irelevant, such as when you are getting checkmated so like any other evaluation feature it's a an approximation of something.

All of eval other than mate or draw are heuristics, yes? I understand what you're saying though, it's a heuristic that works more often than not but sometimes it doesn't -- just like everything else. Depending on how one looks at it, all terms should be -inf, 0, or inf, just some infinities are bigger than other ones

[Don]

If white makes 4 moves from openings position and the only form of evaluation you have is the side to move bonus at the leaf:

e4 Qh5 Bc4 Qxf7 mate, then you evaluate that leaf as side to move bonus +0.05 for black, as black has the move.

I'm evaluating it as ugly bad for black as he has no more mobility as it is a mate.

So side to move bonus messes up here, as it can't distinguish a near mate position between the position after 1.d4 which also is +0.05 for black.

Note that the claimed bonuses here are just very tiny. 0.05 of a pawn i saw circulate here up to 0.09, whereas mobility is doing the same thing yet a lot better and gives a much larger bonus/penalty and more accurate.

Vincent

Vincent,

You just gave a convincing argument that mobility is a more useful evaluation feature than stand pat bonus.

How is that relevant to our discussion?

- Don

[diep]

You can try it, however the side to move bonus is doing this:

In roughly 70% of cases qsearch nullmove will give a cutoff.
Let's assume we give 10 points bonus for side to move.

What happens in such positions P is this:

1. P (side) ==> [alpha,alpha+1]
2. nullmove in P going to qsearch
3. P' (xside) ==> [-alpha-1,-alpha]
if we now consider static evaluation E which gets raised 10 points:
if( E+10 >= -alpha ) then cutoff

This is equivalent with E >= -alpha-10

Or with negamax that's alpha+10 in position P(side)

In short for the first and most important call to qsearch in that qsearch 'root' it's similar to nullmove with a window in position P of [alpha+10,alpha+11]

Now it is of course HARDER to get a cutoff with a nullmove of alpha+10 than trying to find a cutoff above alpha.

I think in your explanation there is a bit of ambiguity, you say cutoff, but actually we have two cutoffs: P (side) cutoff and P' (side) cutoff.

so disambiguating the above we have

if( E+10 >= -alpha ) then P' (side) cutoff

Instead the next sentence can be rewritten as:

Now it is of course HARDER to get a P (side) cutoff with a nullmove of alpha+10 than trying to find a cutoff above alpha.

So your claim is : because is easier for P' (side) to reach a cut off it implicates that it is harder for P (side) to reach a cut off. But I don't think is the case, at least is not so evident.

The point is that when you write:

This is equivalent with E >= -alpha-10

It should be instead written

This is LOCALLY equivalent with E >= -alpha-10


This interpretation of stm bonus as a modified alpha value is valid only locally, in the current ply, but cannot be propagated at the below or upper nodes: alpha is always alpha, it does not change, it is only easier for P' to reach a cut off because stm gives an extra kick, but this is local to P' (side) ply, it does not imply that is harder for P (side) to reach a totally unrelated cutoff on a different move played at a different ply....actually it is easier ALSO for P (side) to reach a cut off because at the next ply we will have:

if( E+10 >= -alpha ) then P (side) cutoff

So stm bonus helps to reach a cut off indipendentley (it means on different moves played at diferent plies) to BOTH sides. This is completly different than changing in ONE direction (as example increasing) the value of alpha.

I don't know if I have been clear, please correct me if I am wrong.

Thanks
Marco

You're seeing the math how it is, but the conclusion is wrong.

You can namely simply test that conclusion by playing games.
It resulted in diep in using a nullmove window alfabeta dependant
and not mess with the evaluation.

The hard fact is that effectively last 3 plies of search vaste majority of positions the qsearch nullmove hammers that search away by means of a cutoff.

I feel i clearly have proven that THIS cutoff gets taken more tough. You definitely see this, but i'm not sure Bob and others see that.

Which is my main point.

Handwaving that away as irrelevant is wrong.

The rest you can just test for your own program whether it works or doesn't.

In case of Diep i'm requiring static eval to be up to half a pawn last plies to prune away with qsearch nullmove.

When doing that, the side to move bonus in diep didn't work at all.

Vincent

[diep]

If white makes 4 moves from openings position and the only form of evaluation you have is the side to move bonus at the leaf:

e4 Qh5 Bc4 Qxf7 mate, then you evaluate that leaf as side to move bonus +0.05 for black, as black has the move.

I'm evaluating it as ugly bad for black as he has no more mobility as it is a mate.

So side to move bonus messes up here, as it can't distinguish a near mate position between the position after 1.d4 which also is +0.05 for black.

Note that the claimed bonuses here are just very tiny. 0.05 of a pawn i saw circulate here up to 0.09, whereas mobility is doing the same thing yet a lot better and gives a much larger bonus/penalty and more accurate.

Vincent

Vincent,

You just gave a convincing argument that mobility is a more useful evaluation feature than stand pat bonus.

How is that relevant to our discussion?

- Don

People who confuse effects draw the wrong conclusion. In their case, like in mine, it was tempting to introduce the bonus and then in a lineair programming manner test it.

As if it would be independant. The effect it has upon search they completely forgot. If you prune that much, something has to pickup tactics and positional moves a tad more.

Nullmove is that effectively that the combination of it with hashtables mixed with forward pruning (reductions) everywhere, has a very nasty effect. That effect is so huge, that trying to measure 1 elopoint by means of a side to move bonus is total ballony.

Then my second argument is of course, which is the main objective in Diep against the bonus, that it is a weak form of mobility. A kind of 'heuristical' mobility that guesses wrong things a lot more than mobility does.

Now considering all they do at most is some sort of 'legal move count' added to their engines, it's not 100% clear whether that primitive definition of mobility is more primitive or less primitive than giving 5 points bonus for side to move.

Thing is that carried out correctly, a sense of activity (that's how Johan de Koning calls mobility) by means of a side to move bonus is not superior nor a good addition to well carried out mobility.

Yet the main confusion is the idea they have that it would be possible to measure 1 or 2 elopoints win by means of playing 10 second games single core in a lineair programming model and conclude based upon elowin there, which effect causes that.

Chess is however not lineair programming at all, giving a side to move bonus changes something dramatic in search that they overlooked (as usual).

Vincent

[bob]

If white makes 4 moves from openings position and the only form of evaluation you have is the side to move bonus at the leaf:

e4 Qh5 Bc4 Qxf7 mate, then you evaluate that leaf as side to move bonus +0.05 for black, as black has the move.

I'm evaluating it as ugly bad for black as he has no more mobility as it is a mate.

So side to move bonus messes up here, as it can't distinguish a near mate position between the position after 1.d4 which also is +0.05 for black.

Note that the claimed bonuses here are just very tiny. 0.05 of a pawn i saw circulate here up to 0.09, whereas mobility is doing the same thing yet a lot better and gives a much larger bonus/penalty and more accurate.

Vincent

Vincent,

You just gave a convincing argument that mobility is a more useful evaluation feature than stand pat bonus.

How is that relevant to our discussion?

- Don

People who confuse effects draw the wrong conclusion. In their case, like in mine, it was tempting to introduce the bonus and then in a lineair programming manner test it.

As if it would be independant. The effect it has upon search they completely forgot. If you prune that much, something has to pickup tactics and positional moves a tad more.

Nullmove is that effectively that the combination of it with hashtables mixed with forward pruning (reductions) everywhere, has a very nasty effect. That effect is so huge, that trying to measure 1 elopoint by means of a side to move bonus is total ballony.

Then my second argument is of course, which is the main objective in Diep against the bonus, that it is a weak form of mobility. A kind of 'heuristical' mobility that guesses wrong things a lot more than mobility does.

Now considering all they do at most is some sort of 'legal move count' added to their engines, it's not 100% clear whether that primitive definition of mobility is more primitive or less primitive than giving 5 points bonus for side to move.

Thing is that carried out correctly, a sense of activity (that's how Johan de Koning calls mobility) by means of a side to move bonus is not superior nor a good addition to well carried out mobility.

Yet the main confusion is the idea they have that it would be possible to measure 1 or 2 elopoints win by means of playing 10 second games single core in a lineair programming model and conclude based upon elowin there, which effect causes that.

Chess is however not lineair programming at all, giving a side to move bonus changes something dramatic in search that they overlooked (as usual).

Vincent

Here is my problem with the above. I do mobility in Crafty, and I do something a little better than just counting the number of squares a piece can reach. Yet when I added the STM bonus, it _clearly_ improved play by a small amount. With enough games to confirm this was not a random result.