| View previous topic :: View next topic |
| Author |
Message |
Larry Kaufman
Joined: 10 Jan 2010
Posts: 1271
Location: Maryland USA
|
 Posted: Thu Mar 22, 2012 9:15 pm Post subject: stand pat or side to move bonus |
  |
|
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? |
|
| Back to top |
|
 |
Sam Hamilton
Joined: 23 Jun 2006
Posts: 1095
|
| Posted: Thu Mar 22, 2012 10:49 pm Post subject: Re: stand pat or side to move bonus |
|
|
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 |
|
| Back to top |
|
|
Daniel Shawul
Joined: 14 Mar 2006
Posts: 2282
Location: Ethiopia
|
| Posted: Thu Mar 22, 2012 11:27 pm Post subject: Re: stand pat or side to move bonus |
|
|
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.
_________________
https://sites.google.com/site/dshawul/
https://github.com/dshawul |
|
| Back to top |
|
|
Larry Kaufman
Joined: 10 Jan 2010
Posts: 1271
Location: Maryland USA
|
| Posted: Fri Mar 23, 2012 12:40 am Post subject: Re: stand pat or side to move bonus |
|
|
| Daniel Shawul wrote: |
| 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. |
|
| Back to top |
|
|
Daniel Shawul
Joined: 14 Mar 2006
Posts: 2282
Location: Ethiopia
|
| Posted: Fri Mar 23, 2012 1:27 am Post subject: Re: stand pat or side to move bonus |
|
|
| Quote: |
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.
_________________
https://sites.google.com/site/dshawul/
https://github.com/dshawul |
|
| Back to top |
|
|
Larry Kaufman
Joined: 10 Jan 2010
Posts: 1271
Location: Maryland USA
|
| Posted: Fri Mar 23, 2012 2:06 am Post subject: Re: stand pat or side to move bonus |
|
|
| Daniel Shawul wrote: |
| Quote: |
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. |
|
| Back to top |
|
|
Daniel Shawul
Joined: 14 Mar 2006
Posts: 2282
Location: Ethiopia
|
| Posted: Fri Mar 23, 2012 3:07 am Post subject: Re: stand pat or side to move bonus |
|
|
| Quote: |
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.
_________________
https://sites.google.com/site/dshawul/
https://github.com/dshawul |
|
| Back to top |
|
|
Larry Kaufman
Joined: 10 Jan 2010
Posts: 1271
Location: Maryland USA
|
| Posted: Fri Mar 23, 2012 3:26 am Post subject: Re: stand pat or side to move bonus |
|
|
| Daniel Shawul wrote: |
| Quote: |
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? |
|
| Back to top |
|
|
Richard Vida
Joined: 16 Apr 2009
Posts: 470
Location: Slovakia, EU
|
| Posted: Fri Mar 23, 2012 2:01 pm Post subject: Re: stand pat or side to move bonus |
|
|
| lkaufman wrote: |
| 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) |
|
| Back to top |
|
|
Richard Vida
Joined: 16 Apr 2009
Posts: 470
Location: Slovakia, EU
|
| Posted: Fri Mar 23, 2012 2:07 pm Post subject: Re: stand pat or side to move bonus |
|
|
| lkaufman wrote: |
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. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
