I would say implementing 50-move acts like a work-around. Why would you not want your engine to make any progress if the FIDE would decide to drop the 50-move rule?
I like to solve the problem where it actually lies (except in uMax, where I like to solve a problem with anything that helps and takes few characters. ) A good engine makes progress when in a won position. If it does not see any way to make progress, even when making progress is rewarded more than might in general be optimal (after 20 reversible moves), I should trust the engine, and accept that I am in a mis-evaluated drawn position. The fact that there was no progress in 50 moves, is a better indication for this than the score: the score is usually not derived from a 100-ply search!
There are other ways to implement the 50-move rule. One doesn't have to just slam the door at move 50 and return draw. You can start to drag the score toward draw after some arbitrary number of moves, so that if you are behind, you notice that not capturing or pushing a pawn causes the score to marginally rise move by move. Or if you are ahead, you notice that if you don't capture or push a pawn, the score marginally drops after each move.
That gives a program a sense of "making progress" and avoids stumbling into a local maximum with their eval and just shuffling there forever until the game suddenly ends as an unexpected draw...
Again it depends on how you implement it. It should not be a "monostable" idea, that is either on or off. That doesn't help much at all as often by the time you get to the point where you can see that the 50 move rule is going to kick in, it can be too late to try a push or capture because it now is not winning because choices are limited.
hgm wrote:I would say implementing 50-move acts like a work-around. Why would you not want your engine to make any progress if the FIDE would decide to drop the 50-move rule?
I like to solve the problem where it actually lies (except in uMax, where I like to solve a problem with anything that helps and takes few characters. ) A good engine makes progress when in a won position. If it does not see any way to make progress, even when making progress is rewarded more than might in general be optimal (after 20 reversible moves), I should trust the engine, and accept that I am in a mis-evaluated drawn position. The fact that there was no progress in 50 moves, is a better indication for this than the score: the score is usually not derived from a 100-ply search!
I would do it _exactly_ as I do it today, which does cause my program to want to either make progress or settle toward a draw...
bob wrote:Again it depends on how you implement it. It should not be a "monostable" idea, that is either on or off. That doesn't help much at all as often by the time you get to the point where you can see that the 50 move rule is going to kick in, it can be too late to try a push or capture because it now is not winning because choices are limited.
Yes, I would make the score converge gradually towards zero.
bob wrote:Again it depends on how you implement it. It should not be a "monostable" idea, that is either on or off. That doesn't help much at all as often by the time you get to the point where you can see that the 50 move rule is going to kick in, it can be too late to try a push or capture because it now is not winning because choices are limited.
Yes, I would make the score converge gradually towards zero.
I do this for quite a few cases besides 50 move rule. As material comes off, particularly pawns, you can also do this. Or with bishops of opposite color you can do this as material comes off. Etc...
bob wrote:Again it depends on how you implement it. It should not be a "monostable" idea, that is either on or off. That doesn't help much at all as often by the time you get to the point where you can see that the 50 move rule is going to kick in, it can be too late to try a push or capture because it now is not winning because choices are limited.
Yes, I would make the score converge gradually towards zero.
I do this for quite a few cases besides 50 move rule. As material comes off, particularly pawns, you can also do this. Or with bishops of opposite color you can do this as material comes off. Etc...
Makes a lot of sense. My engine doesn't need it yet, but when it gets into more endgames and I have implemented more of the basics (without tablebases; I will have fun in devising actual algorithms to handle different cases; only when I run out of those I will add TB or BB support).
It would also make sense to go in the other direction; to converge towards a mate score when the material advantage is overwhelming, so that it doesn't try to squeeze the last centipawn out of the position, but simply trade everything until only the one rook is left over. This is the way humans play, particularly in blitz games: Even when a rook ahead, when you have a pawn you could even sacrifice the rook to get a queen a bit later, because pushing the pawn is easy under time pressure, and mating with the queen is also much faster.
I drag my score towards 0 in my engine as the 50 move rule approaches, but when I watch the games I have a sneaking suspicion that my hash table is having an odd interaction with this. This happens because my score is dragged toward 0 in my eval function, is hashed, and then transposition ignores the fact that it might have taken many more moves to get to that same hashed position (standard hash problem with "path related" eval).
Bob, do you do anything to counter this, such as dragging the value toward 0 after extracting it from hash (a little slower but more accurate I think)? Or have you concluded it isn't a big deal?
BubbaTough wrote:I drag my score towards 0 in my engine as the 50 move rule approaches, but when I watch the games I have a sneaking suspicion that my hash table is having an odd interaction with this. This happens because my score is dragged toward 0 in my eval function, is hashed, and then transposition ignores the fact that it might have taken many more moves to get to that same hashed position (standard hash problem with "path related" eval).
Bob, do you do anything to counter this, such as dragging the value toward 0 after extracting it from hash (a little slower but more accurate I think)? Or have you concluded it isn't a big deal?
-Sam
All you can do is invalidate the hash scores. I do this as the 50 move rule approaches to make sure there is no strange stuff going on. I think I start marking the scores invalid (I don't clear the entries to keep the move ordering info since this is an endgame) once I get within 20 plies of bumping into the 50-move rule. I saw strange things a few years back as in these kinds of endings, you can go very deep and keep hash scores across multiple searches, which can wreck any 50-move rule score dependencies.
I have not tried to muck around with the scores as they are retrieved. We did this in Cray Blitz by opening a "draw-score window" in the scoring range. Real scores were in the range:
-inf <= score < 0 else score > 100. Effectively, every positive (or even 0) score gets .1 pawns added to it. That gave us a range of scores we _knew_ were draw scores. But for 50 move draws, there was little we could do since the original score could be +3.0 and you want to drag that down, without knowing whether it was dragged down before hand or not... I suppose you could store the "non-dragged" score if you know what it was supposed to be, but we did not try that. And I don't do it today but looking at options about this is on my to-do list for some point.
bob wrote:The answer is yes. I have seen multiple programs lose tournament games due to this trivially fixable oversight. The most amusing was a program "LaChex" at an ACM event where we had a long discussion about this and Burton Wendroff left going back to his home in Los Alamos (the event was in Albuquerque) and since he didn't do underpromotions, he told Tony Warnock as he left "if this is ever a problem, call me". Before Burton got back to Los Alamos (about 80 miles or so away) Tony called him on his cell phone and said "OK, it's a problem. We just lost the game we were winning because we overlooked a knight fork that led to a forced mate, even though we were a queen+ ahead". By the next round lachex was doing underpromotions...
I see no reason to omit them. Null-move makes them go quickly, and often the hash table cuts the trees off since any promotion gets ripped off the board instantly...
Thanks for your input Bob. You make a very good point about hash cuts. Also, I had realized after seeing the other responses that knight promotions really do need to be searched or the engine will likely stumble into a few too many unnecessary knight forks.
Searching bishop and rook promotions however doesn't seem necessary to me most of the time, but would be useful if a queen promotion returns a draw score. It would be trivial to generate them only in that case. Do you know of any other case where I would need to search them?
) A good engine makes progress when in a won position. If it does not see any way to make progress, even when making progress is rewarded more than might in general be optimal (after 20 reversible moves), I should trust the engine, and accept that I am in a mis-evaluated drawn position. The fact that there was no progress in 50 moves, is a better indication for this than the score: the score is usually not derived from a 100-ply search!
