bob wrote: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.
Any decent program is 50-move aware.
The problem is that in your hypothetical example the program will be much more likely to sacrifice another Pawn, completely unrelated to the problem that was blocking progress. And then 49 moves later, another one.
This is why negative motivation will not work. It will drive the program away from the 50-move draw, sure enough, but you don't know in which direction. It will just induce a random sacrifice. And in Chess, randomly chosen moves are lmore likely to make the situation worse than to improve it.
What is needed is positive motivation, in the form of some goal.
hgm wrote:The problem is that in your hypothetical example the program will be much more likely to sacrifice another Pawn, completely unrelated to the problem that was blocking progress. And then 49 moves later, another one.
This is why negative motivation will not work. It will drive the program away from the 50-move draw, sure enough, but you don't know in which direction. It will just induce a random sacrifice. And in Chess, randomly chosen moves are lmore likely to make the situation worse than to improve it.
What is needed is positive motivation, in the form of some goal.
How exactly would you go about implementing this positive motivation?
How exactly would you go about implementing this positive motivation?
I guess that it means that program has to know what do i. e. has some understating of position. I am afraid nothing else can really help and if so then only by accident.
I have encountered many times that my engine does silly things only to avoid the repetition draw when it incorrectly feels standing better than opponent. 50 move rule of course can have the same negative effect.
And I have to add that I am little bit sceptical about usefulness of its implementation. In games I have watched the only effect was drop in the score just before the 50th move. Don't rember any case in which this actually kicked the engine to some usefull action.
Filip
I think most of you programmers are overlooking some pretty basic things. I would suggest:
Step 1. Build a "Generate Positive Action" function
Step 2. Build a "Detect Not Making Enough Progress" function
Step 3. Initialize and maintain an "Impatience" variable.
Simple Solution: Utilize the Detect Not Making Enough Progress function to help maintain the "Impatience" variable and trigger the "Generate Positive Action" function.
Once you are done with the simple solution, the majority of your problems will be solved and we can discuss more generalized approaches.
If you can't handle that simple task, I am not sure why you want to bother writing chess programs, but I guess you can go back and look at what Bob said about his horribly non-optimal approach.
Zach Wegner wrote:How exactly would you go about implementing this positive motivation?
What I do in Joker is increase the Pawn-push bonus (essentially switching to other piece-square tables for Pawns) after 50 reversible plies, especially for passers. The positive motivation then becomes to advance its Pawns. This allows me to be reluctant with Pawn moves in the normal evaluation. First it tries to make progress by moving pieces around, trying to win more material without doing something irreversible. Especially at short TC this has the advantage that it deepens the existing game tree in the hash table, as all nodes that are in there remain reachable, so that a way out of a stand-off that is beyond the horizon for a single search will eventually be discovered when the branch leading to the way out is search a number of times in succession, reached by a few different initial moves (as the root position is changing all the time). If that apparently does not work, it switches to 'plan B', which is to put emphasis on pushing Pawn in a responsible way. If neither of that works, it simply accepts that cannot make progres, and is happy with the draw.
I noticed that in just about all Your posts about 50-move rule You look at it from the perspective of the winning side. But what about the loser? The weaker player may actually need the negative reinforcement not to move its wretched last pawn, despite it being a passer. In the long run, assuming the oposition of similar strength, this effect might cancel out with the problems You wrote about. And to catch the opponent on a desperate sacrifice for the purpose of avoiding the draw, You need actually to come close to that draw.
My approach addressed that. As you begin to approach the 50 move rule, you begin to drag the score closer to zero. If you are winning, you will try to find a way to push a pawn or make a capture to keep the score from dropping. If you are behind, you will try to find a way to avoid pushing or capturing to cause the score to continue rising (getting closer to zero).
This way you don't care about the winning or losing circumstances because both are handled at one time.
I noticed that in just about all Your posts about 50-move rule You look at it from the perspective of the winning side. But what about the loser? The weaker player may actually need the negative reinforcement not to move its wretched last pawn, despite it being a passer. In the long run, assuming the oposition of similar strength, this effect might cancel out with the problems You wrote about. And to catch the opponent on a desperate sacrifice for the purpose of avoiding the draw, You need actually to come close to that draw.
Good point. Of course ignoring one, does not mean you have to ignore the other.
In fact I do react to the 50-move counter in Joker, but in a more emotional way: If the count gets above 50 ply, Pawn pushes are awarded more for the side that is ahead. I guess I should really penalize them foo\r the side that is behind, in that case. The main reason I have not done that is that I never perceived the problem. If Joker did refrain from moving a Pawn for 45 moves, it is very unlikely that it would suddenly do it in the last 5 moves.
If you play enough games, this becomes an issue. Programs handled this in the 80's in fact, because many of us saw these identical problems, most notably in human games where the human would try to use superior knowledge to reach draws that 50-move-rule-unaware programs would not see, I used to have an answer for "how many games does this affect?" but I have not run such a test in a long time. I probably could (now) just break the 50 move draw code and run a cluster match to see what happens elo-wise, for fun. I want to do several such runs since EGTBs are not precisely rated, and then there are the usual "what is pondering worth?" and "what is SMP search actually worth?" I can answer each of those without much effort.
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.
Now you are onto a different topic. For example, should a program offer a draw and accept them? For play against computers, it is not needed at all as the computers don't mind playing on for however long it takes. Against humans, it becomes a different issue.
So yes, recognizing such would be nice, but it would probably make the evaluation so incredibly slow that the program would not play very well. Now what we see is a game where for 30 moves the programs will waffle around, then over the next 20, Crafty has to find a way to push a pawn to avoid the draw. Which it does, and then immediately waffles again for 30 moves, etc. For the most part, the evaluation avoids this because advancing pawns is a good idea in endgames. But for actually giving one up, that is a different matter.
bob wrote: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.
Any decent program is 50-move aware.
The problem is that in your hypothetical example the program will be much more likely to sacrifice another Pawn, completely unrelated to the problem that was blocking progress. And then 49 moves later, another one.
This is why negative motivation will not work. It will drive the program away from the 50-move draw, sure enough, but you don't know in which direction. It will just induce a random sacrifice. And in Chess, randomly chosen moves are lmore likely to make the situation worse than to improve it.
What is needed is positive motivation, in the form of some goal.
A good evaluation will deal with this most of the time. For example if I have a king and 3 pawns, and have to give up one, which one? In most endings there is only one choice, the distant passed pawn. At today's speed, by the time you give up your distant passer, you probably see a forced win anyway in K+P endings. In more complex cases, you have to hope your evaluation can correctly determine which pawn loss retains the greatest winning chances, otherwise nothing is going to help the program, 50 move rule or not.
My program would not "randomly" toss a pawn. But I am certain I coupld probably construct a position where it has two choices and the evaluation is wrong, although I have not seen this happen.
