Zenmastur wrote: ↑Wed Mar 18, 2020 5:35 am
I think there is a solution that would allow the engine to find solutions to similar problems during tournament play without disabling the 50-move-rule.
In the meantime I think a UCI option to disable 50-move-rule checking is warranted.
When would one choose to disable it and when not?
There is no point disabling it if the search isn't long enough to reach the 100 ply limit. However, if the position your analyzing is already at something like 50 ply since the last capture or pawn push it's well with in the capabilities of most engines on good hardware to search past the 50 additional plies needed to break the 100 ply limit.
Mostly it would be used when engines like stockfish don't have a clue and start doing stupid crap like shuffling pieces back and forth. This makes the rest of their analysis (the part after the shuffling ends because they found something to do) almost worthless because by that time they have overstepped the 50 move-limit and anything they have found will be evaluated as 0.00 anyway.
I'm sure you've all seen stockfish and other programs start shuffling piece with no apparent goal or aim. If the 50-move rule is in play when they start doing this you might as well stop the search because in most cases the 50-move rule will keep them from ever finding anything they can use. The closer the position is to the 50-move limit when the shuffling starts the less likely you are to find anything BECAUSE of 50-move-rule enforcement.
Only 2 defining forces have ever offered to die for you.....Jesus Christ and the American Soldier. One died for your soul, the other for your freedom.
Zenmastur wrote: ↑Thu Mar 19, 2020 8:36 am
Mostly it would be used when engines like stockfish don't have a clue and start doing stupid crap like shuffling pieces back and forth. This makes the rest of their analysis (the part after the shuffling ends because they found something to do) almost worthless because by that time they have overstepped the 50 move-limit and anything they have found will be evaluated as 0.00 anyway.
I'm sure you've all seen stockfish and other programs start shuffling piece with no apparent goal or aim.
It's interesting how this might fit in with the fortress detection some flavors of SF have.
For our test position and anything like it, it's not so clear what's aimless shuffling. Neither human nor engine can tell what's progress and what's not. The fortress detection probably wrongly shows a draw. That's another thing to check.
If you set "Syzygy50MoveRule" to false, this will also switch it off for the search.
Thanks Joerg. Do you know when using “regular” Stockfish if you turn off the Syzygy50Moverule does the main program still enforce the 50-move-rule. It doesn't seem make sense that it would. I mean, what good would it do to switch it off for TB's and still have the program enforce the rule?
Look up the rules of correspondence chess.
This has absolutely nothing to do with correspondence chess.
Of course it does...
https://github.com/syzygy1/Cfish Syzygy50MoveRule
Disable to let fifty-move rule draws detected by Syzygy tablebase probes count as wins or losses. This is useful for ICCF correspondence games.
Inspired by a suggestion in the TCEC chat: Which changes to code must be done in order to have the player making the move ending the game by the 50 moves rule either win or lose, respectively (rather than draw)?