bob wrote: This might be a case of some aggressive check extension working, where I have found in real games that the give-check extension is good, the rest are either harmful or do not help.
I don't think so. Crafty extends checks far more aggressively than Stockfish, unless you have changed something recently. Stockfish extends checks by only half a ply, except at PV nodes.
I only extend checks, and by 1 ply everywhere. But i have no other extensions of any kind. No one-legal-move extensions, no passed pawn push extensions, etc... I thought you did some of those still???
Also note that the discussion is not only about stockfish. Some others find it very quickly, some strong programs take a long time to find the move. It has my attention because crafty quickly sees that if I play f5, it is losing with white, with a worse score than if I play Be8. But given the choice, it likes Be8 for a long time. I do not know when or if it will switch to f5. I am running it, but I am only using one CPU so that I can get repeatable results if I find something to test or debug...
bob wrote: This might be a case of some aggressive check extension working, where I have found in real games that the give-check extension is good, the rest are either harmful or do not help.
I don't think so. Crafty extends checks far more aggressively than Stockfish, unless you have changed something recently. Stockfish extends checks by only half a ply, except at PV nodes.
I only extend checks, and by 1 ply everywhere. But i have no other extensions of any kind. No one-legal-move extensions, no passed pawn push extensions, etc... I thought you did some of those still???
Yes, we do. You talked about "aggressive check extension" in particular, which is why I replied the way I did.
At non-PV nodes, Stockfish extends single replies and captures leading to a pawn endgame by 1 ply, and checks and pawn pushes to the 7th rank by half a ply.
I think zugzwang is the most likely reason why the results of different programs vary so much here, though. The position does look very zugzwang-ish.
bob wrote: This might be a case of some aggressive check extension working, where I have found in real games that the give-check extension is good, the rest are either harmful or do not help.
I don't think so. Crafty extends checks far more aggressively than Stockfish, unless you have changed something recently. Stockfish extends checks by only half a ply, except at PV nodes.
I only extend checks, and by 1 ply everywhere. But i have no other extensions of any kind. No one-legal-move extensions, no passed pawn push extensions, etc... I thought you did some of those still???
Yes, we do. You talked about "aggressive check extension" in particular, which is why I replied the way I did.
At non-PV nodes, Stockfish extends single replies and captures leading to a pawn endgame by 1 ply, and checks and pawn pushes to the 7th rank by half a ply.
I think zugzwang is the most likely reason why the results of different programs vary so much here, though. The position does look very zugzwang-ish.
I backed off the null-move stuff, all the way to zero for one run, and it doesn't seem to make any difference...
Tord Romstad wrote:I think zugzwang is the most likely reason why the results of different programs vary so much here, though. The position does look very zugzwang-ish.
I backed off the null-move stuff, all the way to zero for one run, and it doesn't seem to make any difference...
But this does not prove that zugzwang is not the issue! Disabling null move has another obvious effect besides allowing you to detect zugzwangs: It dramatically reduces your search depth. Assume that one critical line ends up in a zugzwang, while another critical line does not contain a zugzwang, but is very deep. In this case, disabling null move probably isn't going to help you to find the solution.
The right way to test is to run with and without zugzwang detection. I would have tested it myself if I could, but my computer is busy right now.
Tord Romstad wrote:I think zugzwang is the most likely reason why the results of different programs vary so much here, though. The position does look very zugzwang-ish.
I backed off the null-move stuff, all the way to zero for one run, and it doesn't seem to make any difference...
But this does not prove that zugzwang is not the issue! Disabling null move has another obvious effect besides allowing you to detect zugzwangs: It dramatically reduces your search depth.
Doesn't reduce mine. I just let it run longer.
Assume that one critical line ends up in a zugzwang, while another critical line does not contain a zugzwang, but is very deep. In this case, disabling null move probably isn't going to help you to find the solution.
The right way to test is to run with and without zugzwang detection. I would have tested it myself if I could, but my computer is busy right now.
Obviously Schola is a patzer compared to many of the engines taking a long time but finds it pretty early. It's search does a couple of extensions (check mostly) and has LMR but nothing special there. There's no zungwang detection and it's standard null move applied pretty much everywhere.
One suspicion is that it's one of the cases where a very basic evaluation is actually better than one that considers a lot of factors.
I just let it run longer.