changing the 50 move rule to 5 move rule

[Uri Blass]

AB engines ignore the 50 move rules in their hash.

I wonder what could happen in case that there was a 5 move rule or 10 move rule.

I guess in this case it was better not to ignore the rule in the hash.
Did people investigate this problem?

Maybe it is possible to learn from it also about better handling of the 50 move rule in games (for example maybe it is better not to ignore the 50 move rule in the hash in part of the cases(for example you can decide that you usually ignore the 50 move rule in the hash but not when there are already at least 80 plies with no capture or a pawn move).

[Hanamuke]

The problem has been investigated, it's called the Graph History Interaction (GHI) problem if you want to look it up. We don't have a good solution.

[Uri Blass]

The problem has been investigated, it's called the Graph History Interaction (GHI) problem if you want to look it up. We don't have a good solution.

The problem is that in most chess games there is no problem of the 50 move rule so even if there is a good solution it is not going to give a lot of elo.

First step should be to change the rules so solving the problem give a lot of elo and try to find an optimal solution.
A possible idea except changing the 50 number is to have the same rules of chess except the fact that draws are not draws but win for one side and you need all the history of the game to calculate the winner.

For example you can decide that an external program calculate the winner and has a cheap way to calculate the winner based on the path but
you do not know how the external program calculate the winner(it can be simply the side who played the last capture but if you know it in advance you can change your evaluation function to give a bonus for the side who made the last capture and I do not want you to do it).

I wonder how many elo points you can get in this type of game by different using of hash tables and how many elo points you lose in normal chess from it.

Note that a solution that lose most games in normal chess will also lose most games with the no draw rules because the rules change the result only if the result is a draw.

[IanO]

This is a legitimate problem in other chess variants. For example Makruk (Thai chess) has more demanding draw counting rules which go into effect when the final pawn is captured or a king is bared. These rules penalize having too high of a material imbalance since remaining material reduces the move count and the count depends on the strongest piece remaining. For example, if two rooks are remaining, you have four or fewer moves to achieve checkmate.

I would like to see a LeelaZero Makruk offshoot with knowledge of these counting rules, to see whether the extra endgame pressure would improve early training endgame play. On the other hand, this might instead pressure Leela to simply avoid endgames or to not invoke the counting rules by avoiding capture of the last pawn.

[Ovyron]

Huh, I've played many "chessy" games with long maneuvres of pieces without pawn moves and captures and I'd find absurd if they were called draws just because the draw rule was in your face and you were forced to move a pawn or capture to avoid it. What about 20 move rule?

AFAIK, this was investigated by Robert Houdart for Houdini (the engine allows the user to set FiftyMoveDistance to numbers lower than 50), setting it to 50 made the engine strongest (so... lowering it would have made the engine make silly moves to avoid it when it wasn't necessary making it weaker.)

[carldaman]

Lowering Houdini's FiftyMoveDistance too much would also cause it to walk into sudden losses where it assumed a checkmate was 'safely' beyond the draw threshold when it actually wasn't.

However, it was a still a good feature if you lowered it to a more reasonable number, as it enabled Houdini to make progress instead of shuffling aimlessly in positions where it had the advantage.

[Ovyron]

Yeah, though I found out that if Houdini was shuffling aimlessly around the positions and needed to have FiftyMoveDistance tweaked to improve, that it was the wrong engine to use to analyze those positions, to begin with (on games you can't really change it on the fly and it seems 50 is best in most cases, so...)