stand pat or side to move bonus

[lkaufman]

In at least 99% of chess positions, it's better to be on move than not. Therefore all strong programs take this into consideration when evaluating positions or making decisions. There appear to be three possibilities:

A. Simply give the side to move a bonus when doing an evaluation, which can either be a constant or may depend on something else.
B. When reaching quies, if you are below beta but within for example 10 centipawns of beta allow the cutoff.
C. Do both of the above.

What are the pros and cons of the three methods? We currently use method A, but I notice that some strong programs appear to use B or C. Are there any other possibilities in use for handling this issue?

[BubbaTough]

Another option is to make some positional factors give side to move bonuses. King safety, and passed pawns are pretty simple ones, but you can do more complex things with development and such. In this fashion, you can try to try to give more appropriately sized toMove bonuses.

-Sam

[Daniel Shawul]

I tried to put a Tempo bonus in eval in the past (not sure if it is still there) and it works well for positions where the king is exposed and maybe to increase mobility as well. Downsides are GHI, null move problems, also you can't store the score that contains tempo bonus directly in eval cache if you have that. I also tried to give bonus to pin and fork opponent pieces or get yours pieces out of those situation. It seems this is similar in nature only it has greater significance.

[lkaufman]

I tried to put a Tempo bonus in eval in the past (not sure if it is still there) and it works well for positions where the king is exposed and maybe to increase mobility as well. Downsides are GHI, null move problems, also you can't store the score that contains tempo bonus directly in eval cache if you have that. I also tried to give bonus to pin and fork opponent pieces or get yours pieces out of those situation. It seems this is similar in nature only it has greater significance.

What "null move" problems exactly? Obviously the bonus is wrong in zugzwang positions, but it's easy enough to offset the nullmove bonus or adjust the score after a null move if you want to do so.

[Daniel Shawul]

What "null move" problems exactly? Obviously the bonus is wrong in zugzwang positions, but it's easy enough to offset the nullmove bonus or adjust the score after a null move if you want to do so.

Besides zugzwang, the bonus should be kept low not to have too many fail highs solely due to switching sides by null move. Detecting hanging pieces and taking off some score has the opposite effect of making us search deeper (rather than stand pat). You may need to shift up or down your beta when null moving if you want reliable cutoffs. Not exactly a problem with null move I see, but that is what I meant. Also you can have a serious odd-even effect depending on where the search terminated. This is really very clear in my engine which plays Go & reversi. There the side to move is surely going to get +100 extra points on his move (could even reach 600 if there are ataried stones). Without that bonus alpha-beta search is very badly screwed with alternating scores of +100 and 0 . But the tempo bonus in chess is that something that could easily evaporate so you can't reliably make it larger without having search problems. I tried to apply bigger margins in special cases when the king is badly exposed and or pieces are forked.

[lkaufman]

What "null move" problems exactly? Obviously the bonus is wrong in zugzwang positions, but it's easy enough to offset the nullmove bonus or adjust the score after a null move if you want to do so.

Besides zugzwang, the bonus should be kept low not to have too many fail highs solely due to switching sides by null move. Detecting hanging pieces and taking off some score has the opposite effect of making us search deeper (rather than stand pat). You may need to shift up or down your beta when null moving if you want reliable cutoffs. Not exactly a problem with null move I see, but that is what I meant. Also you can have a serious odd-even effect depending on where the search terminated. This is really very clear in my engine which plays Go & reversi. There the side to move is surely going to get +100 extra points on his move (could even reach 600 if there are ataried stones). Without that bonus alpha-beta search is very badly screwed with alternating scores of +100 and 0 . But the tempo bonus in chess is that something that could easily evaporate so you can't reliably make it larger without having search problems. I tried to apply bigger margins in special cases when the king is badly exposed and or pieces are forked.

If pieces are forked it's not obvious to me that a tempo will help in general, the damage is already done. Anyway the most critical use of an eval function is for quies, and in quies if you can capture something you just do it. So we can almost assume that the side under the more severe attack must be on move. If you have checks in quies this may also apply to "badly exposed king" though less clearly so. Stockfish bases the size of the bonus on game phase, as did Rybka 3, while I believe that Ippo, Ivanhoe, and Critter do not. In this (as in most other search issues where we have to choose between two options) we have found that Stockfish's approach works better for us than Ippo's. I'm sure that the engines that don't consider phase have a reason for this, but I can't guess what it might be.

[Daniel Shawul]

If pieces are forked it's not obvious to me that a tempo will help in general, the damage is already done. Anyway the most critical use of an eval function is for quies, and in quies if you can capture something you just do it. So we can almost assume that the side under the more severe attack must be on move. If you have checks in quies this may also apply to "badly exposed king" though less clearly so. Stockfish bases the size of the bonus on game phase, as did Rybka 3, while I believe that Ippo, Ivanhoe, and Critter do not. In this (as in most other search issues where we have to choose between two options) we have found that Stockfish's approach works better for us than Ippo's. I'm sure that the engines that don't consider phase have a reason for this, but I can't guess what it might be.

I think the magnitude of the tempo compared to other evaluation terms should be considered. In the endgame, wins and losses are decided by small details. So applying a big tempo bonus there is risky maybe even more than the danger of having a zugzwang. Tempo is obviously important during the opening so for me a gradually decreasing bonus may work better than a constant one.

As to your original question, I prefer (A) only because it allows to adjust the bonus depending on other situations on the board. Doing it at the search as you explained it forces you to use a constant bonus since you don't call eval() there usually. Maybe that is why Ippo don't use different bonuses. That is choosing implementation (B) forced them to use constant bonus. You never know. Either that or it is just a declaration that having the side to move is always equally good.

[lkaufman]

If pieces are forked it's not obvious to me that a tempo will help in general, the damage is already done. Anyway the most critical use of an eval function is for quies, and in quies if you can capture something you just do it. So we can almost assume that the side under the more severe attack must be on move. If you have checks in quies this may also apply to "badly exposed king" though less clearly so. Stockfish bases the size of the bonus on game phase, as did Rybka 3, while I believe that Ippo, Ivanhoe, and Critter do not. In this (as in most other search issues where we have to choose between two options) we have found that Stockfish's approach works better for us than Ippo's. I'm sure that the engines that don't consider phase have a reason for this, but I can't guess what it might be.

I think the magnitude of the tempo compared to other evaluation terms should be considered. In the endgame, wins and losses are decided by small details. So applying a big tempo bonus there is risky maybe even more than the danger of having a zugzwang. Tempo is obviously important during the opening so for me a gradually decreasing bonus may work better than a constant one.

As to your original question, I prefer (A) only because it allows to adjust the bonus depending on other situations on the board. Doing it at the search as you explained it forces you to use a constant bonus since you don't call eval() there usually.

Maybe that is why Ippo don't use different bonuses. That is choosing implementation (B) forced them to use constant bonus. You never know. Either that or it is just a declaration that having the side to move is always equally good.

Rybka, Stockfish, and Komodo all agree with you on your preference for (A), and for the reasons you give (at least speaking for Rybka and Komodo). I'm sure that the authors of Ippo, Critter, Ivanhoe etc. are aware of this argument. So they must see some compensating advantage in using method (B) or (C). But what could it be?

[rvida]

I'm sure that the engines that don't consider phase have a reason for this, but I can't guess what it might be.

Because it tested better. But there is nothing in my code that forces me to stick with a constant tempo value. In fact, the added bonus is not a literal constant, it comes from a member of StateInfo structure which is filled during evaluate(). (stand_pat = board.st->eval + board.st->tempo)

In some older versions I had tempo = 0 for dead drawn endgames, but now this is obsolete because I immediately return 0 in such branches (no matter what is the remaining depth)

[rvida]

Rybka, Stockfish, and Komodo all agree with you on your preference for (A), and for the reasons you give (at least speaking for Rybka and Komodo). I'm sure that the authors of Ippo, Critter, Ivanhoe etc. are aware of this argument. So they must see some compensating advantage in using method (B) or (C). But what could it be?

I don't really see a fundamental difference between (A) and (B). It should not matter if I grant the bonus inside evaluate() or add it after the call.

As for (C), it sounds like adding the bonus 2x which is again same as (A) or (B) just with 2x higher value.