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.

Moderator: Ras
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...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!
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.
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...nczempin wrote: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.
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).bob wrote: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...nczempin wrote: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.
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.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
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.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...