Jouni wrote: In first Nakamura game SF as black used about one minute here to obvious -Qxe7 capture.
Current testing framework cannot test under 'ponder on' condition (mainly because cutechess can't).
With 'ponder off' taking time on the obvious move is not really a weakness because TT table gets filled anyhow and, because move is obvious, the engine spends all his time on the 'correct' move, so TT is filled for good.
I think that 'easy move' kind of patches could give a result when testing with 'ponder on' but this is currently impossible, so without any test validation no 'easy move' patch can be committed.
Regarding the 'easy move' logic in itself, I think special casing on recaptures is a poor choice (typical of a poor programmer), much better to find a general case: in the original 'easy move' code (that later was simplified out) a singular search with very low beta was attempted and upon failing low easy move was assumed. It is a much better and elegant approach.
I do not agree that TT is filled for good with ponder off.
The move of you may be obvious but not the opponent move and in this case if you do not play obvious move faster you may spend a significant time on a move that the opponent does not play.
Stockfish may need a rule to play faster during the time of searching the first move only if the branching factor is high
because in earlier iterations it prunes based on hash tables when it does not need a rule to play faster if the branching factor is high not because of pruning based on hash tables so the question is how to detect if stockfish pruned based on hash tables in previous iteration.
I think that maybe
Rootnode&&tte->depth() >= depth is a condition that happen only if stockfish pruned based on hash tables in this iteration but I am not sure about it.
If it is the case stockfish should detect the first iteration when it does not happan.
mcostalba wrote:Regarding the 'easy move' logic in itself, I think special casing on recaptures is a poor choice (typical of a poor programmer), much better to find a general case: in the original 'easy move' code (that later was simplified out) a singular search with very low beta was attempted and upon failing low easy move was assumed. It is a much better and elegant approach.
Sure, it may be better to solve the general case, but if all attempts at this fail, which apparently they do, then it makes complete sense in my view to "temporarily" adopt a solution that only applies to recaptures. (If one is available, of course. I do not know if that is the case.)
This has nothing to do with bad programming practices. A chess engine is full of "not yet perfect" solutions. The recapture case may be a special case, but it is a very visible special case.
SF already addresses a special case: that of one legal move.
syzygy wrote:To understand why this might be so, just think of how a chess engine would have to determine with near certainty that only one move makes sense. It will take some time and it will take that time on every move. The shorter this time, the more often the supposedly "easy" move will in reality be a blunder. The longer this time, the less time is left for searching non-easy moves.
In Shokidoki I use a method that works quite satisfactorily:
In the root I don't set {alpha, beta} = {score, score+1} after the first move, but rather {score-margin, score-margin+1}, with a large margin. (In Chess I would have chosen something like 200cP.) As soon as any move fails high to this null window, margin is reset to 0 for the remainder of the search (all iterations).
That makes sense. I don't know if something like this has been tried for SF.
IMO the fear that you might miss a trap just behind the horizon is mainly paranoia. Yes, it is possible, and will occur now and then, but it is also possible when you think the nominal time in typical non-singular positions. In particular there is no reason for worry if the losing moves lose so much that the game would be lost anyway. You could also make the time reduction dependent on that.
Afaik the reason SF doesn't have easy move handling is not paranoia, but simply that all attempts so far have failed to show an improvement in testing.
Of course you benefit from this mainly in ponder-on games, where not doing it grants your opponent free ponder time with a guaranteed ponder hit. (So that he would likely move instantly, getting the lead in the 'ponder war' for as long as he can keep producing ponder hits; the effect can be felt for many moves, making you lose much more time than what you thought about the singular move!) Therefore it would be silly to be too dogmatic about this, and reject patches that do not increase Elo in ponder-off games. The rational approach would be to accept it when it can be shown not to lose any Elo in ponder-off games, as it will certainly reduce opponent effective ponder time. And playing equally strong against an opponent with less time must be considered an improvement.
Anyway a truly easy move should allow the search to reach the same search depth as a search having many plausible moves in a fraction of the time. Could a termination of search be based on this? It is such a simple idea it must have been tried before.
If you are on a sidewalk and the covid goes beep beep
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
Michael Sherwin wrote:Anyway a truly easy move should allow the search to reach the same search depth as a search having many plausible moves in a fraction of the time. Could a termination of search be based on this? It is such a simple idea it must have been tried before.
An easy move is a move that a human would not hesitate to play immediately, not because what follows after that move is so easy, but because all other moves are clearly far inferior.
There is no reason why such an easy move would allow the search to reach the same search depth in a fraction of the time.
What you could look at instead is the number of nodes needed to refute the other moves, but this seems rather risky.
Michael Sherwin wrote:Anyway a truly easy move should allow the search to reach the same search depth as a search having many plausible moves in a fraction of the time. Could a termination of search be based on this? It is such a simple idea it must have been tried before.
An easy move is a move that a human would not hesitate to play immediately, not because what follows after that move is so easy, but because all other moves are clearly far inferior.
There is no reason why such an easy move would allow the search to reach the same search depth in a fraction of the time.
What you could look at instead is the number of nodes needed to refute the other moves, but this seems rather risky.
The problem with many such schemes is that they don't work at all if you don't clear the transposition tables at the beginning of each search. You will often blast through depths 1, 2, ..., 19 and get stuck on depth 20 for a while. Then you have nothing to base your decision on.