hgm wrote:Never make the program aware in its search of 50-move draws. That is just asking for trouble. If programs cannot make progress in a won situation without negative re-inforcement, there is something fundamentally wrong in their evaluation. Better solve the problem where it lies, in stead of using the 50-move rule as a work-around.
what on earth is this about? If the program doesn't understand 50 move draws, it will play inferior chess. Suppose you are 3 pawns ahead, but to win you have to give up one of the pawns. Without a 50-move awareness, you will not do this, and draw games you can win.
suppose your engine is ahead, but because of search it knows its opponent can force a draw, say, by repetition.
I have found that my engine sometimes goes ahead and makes a drawing move in that situation (since it knows best play be both sides is a draw anyway), instead of forcing the opponent to "earn" the draw.
Wouldn't it be nice that your program noticed in an early stage it can't make any progress without sacrificing a pawn. If you could solve this in eval that would be great. It would save a lot of moves, especially since with a three pawn advantage your program would sacrifice the pawn even if it can't win after that ( and probably repeated two more times ) which does your program look a bit stupid. I think this was HG's point.
Wouldn't it be nice that your program noticed in an early stage it can't make any progress without sacrificing a pawn. If you could solve this in eval that would be great.
Yah, that would be nice. In theory that is the way to go (you see human chess masters run up against the 50 move rule far less often than computers which says something meaningful I think). But in reality, it is very hard to do...which is why Bob is right about the computer needing the 50 move rule. A few of us also move the score toward a draw as the 50th move approaches so that the computer gets more and more motivated to do something before that point, but it gets tricky because the hashed moves are funky.
I have found that my engine sometimes goes ahead and makes a drawing move in that situation (since it knows best play be both sides is a draw anyway), instead of forcing the opponent to "earn" the draw.
How to avoid this?
Dr. Bob has some cool ways of doing this in theoretically known draw positions (from EGTB table) if I remember right, but it is an interesting and hard problem I have not seen anyone solve in its generality. A similar issue is that there are often "more risky" and "less risky" series of moves to end up transposing to the same position, and computers are bad at taking the better move order because they consider them identical. I have seen a few people try to solve this by taking into account the value of the nodes on they path from root to leaf, but nothing that looked like it would work well in my humble opinion.
Wouldn't it be nice that your program noticed in an early stage it can't make any progress without sacrificing a pawn. If you could solve this in eval that would be great.
Yah, that would be nice. In theory that is the way to go (you see human chess masters run up against the 50 move rule far less often than computers which says something meaningful I think). But in reality, it is very hard to do...
-Sam
Just value the position where the pawn is sacrified higher than the position with the pawn still on the board. Doesn't sound so hard.
Some of this is easy to program. Consider this example: the positional evaluator says the program is ahead at the root but the tablebase facility says the position is drawn. So, have the root move selector avoid picking simplifying moves among all drawing moves in the hope that the opponent will eventually blunder or run out of time.
Just value the position where the pawn is sacrified higher than the position with the pawn still on the board. Doesn't sound so hard.
Good idea! I will go code that up right now and let you know how it turns out after a 20,000,000 game test.
-Sam
Bob could do this test in five minutes on his cluster.
On a more serious note, I understand it's far from a trivial problem. However there's no reason to wait for the fifty move counter to kick in if you notice you can not make any progress. If a pawn sacrifice after 50 moves of shuffling is good or at least not bad, why would it be worse after 10 moves of shuffling or even 6 moves of shuffling?
henkf wrote:Wouldn't it be nice that your program noticed in an early stage it can't make any progress without sacrificing a pawn. If you could solve this in eval that would be great. It would save a lot of moves, especially since with a three pawn advantage your program would sacrifice the pawn even if it can't win after that ( and probably repeated two more times ) which does your program look a bit stupid. I think this was HG's point.
SImple. Don't wait until you get to 50 moves before you do something. At move 30 start to drag the score down toward draw. That gives you 20 moves to either make progress, or dump a pawn to avoid the draw... Has worked for me since the days of Cray Blitz. Slate did the same thing in Nuchess and called it "the weariness factor".
Wouldn't it be nice that your program noticed in an early stage it can't make any progress without sacrificing a pawn. If you could solve this in eval that would be great.
Yah, that would be nice. In theory that is the way to go (you see human chess masters run up against the 50 move rule far less often than computers which says something meaningful I think). But in reality, it is very hard to do...which is why Bob is right about the computer needing the 50 move rule. A few of us also move the score toward a draw as the 50th move approaches so that the computer gets more and more motivated to do something before that point, but it gets tricky because the hashed moves are funky.
I have found that my engine sometimes goes ahead and makes a drawing move in that situation (since it knows best play be both sides is a draw anyway), instead of forcing the opponent to "earn" the draw.
How to avoid this?
Dr. Bob has some cool ways of doing this in theoretically known draw positions (from EGTB table) if I remember right, but it is an interesting and hard problem I have not seen anyone solve in its generality. A similar issue is that there are often "more risky" and "less risky" series of moves to end up transposing to the same position, and computers are bad at taking the better move order because they consider them identical. I have seen a few people try to solve this by taking into account the value of the nodes on they path from root to leaf, but nothing that looked like it would work well in my humble opinion.
-Sam
THere are ideas that we use. For example, drawsore = 0.00 is a possibility. You can use drawscore = +.01 for draws where you are material ahead but still drawn, and drawscore - =.01 for draws where you are material behind but still drawn. Then in a drawn KRP vs KR you won't just toss the pawn, you will try to keep it, since 0.01 is > 0.00...
There are solutions to most problems, but they often take some thought.
