Is it impossible to make fast recapture to Stockfish?

[Jouni]

[D]2rq2k1/p2nRppp/1p6/2np4/3B4/1N3P2/PPP3PP/R2Q2K1 b - - 0 18

In first Nakamura game SF as black used about one minute here to obvious -Qxe7 capture. Ridiculous to ELO 3400 engine! There was again a patch in framework, but it was rejected, why?

[ernest]

In first Nakamura game SF as black used about one minute here to obvious -Qxe7 capture.

???
In infinite analysis SF immediately wants to capture the Rook...

[syzygy]

In first Nakamura game SF as black used about one minute here to obvious -Qxe7 capture.

???
In infinite analysis SF immediately wants to capture the Rook...

In infinite analysis SF never actually gets to play the recapture move.

Jouni's point is that in normal game play SF spends the "normal" amount of time on recaptures even if it is clear to the human eye that no other move would make sense. There were some TCEC games where SF spent 15-20 minutes on something like PxQ.

The answer to Jouni is that it is certainly possible to implement fast recapture (or "easy move"), but so far no implementation has proven to be worth any Elo.

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.

If there is only one legal move then obviously there is no excuse for not playing it immediately. But once there are at least 2 legal moves things stop being trivial.

Personally I'm pretty sure there must be some way of getting some Elo out of the "easy move" idea, but it is certainly not easy to get right or SF would have had it already.

(One thing more needs to be said, though. The SF testing framework runs SF without pondering, which might decrease the benefit of easy move implementations.)

[Dirt]

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.

No, only on moves where there is a week piece that can take a strong piece. I'm surprised it is so hard.

[lucasart]

SF already has a mechanism to dynamically adapt the time allocation, based on a "PV instability" measure. This is far more general than recapture.

Perhaps there is an extra elo gain in playing recaptures, or "easy moves" quicker, but despite the zillion useless tests that fishtest has endured on this subject, there is still zero evidence of it.

If you think you're smarter than we are, by all means, prove us wrong and put your code where your mouth is. But I must warn you: it's not as easy as you think…

[bob]

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.

No, only on moves where there is a week piece that can take a strong piece. I'm surprised it is so hard.

It is not as easy as you think. I've seen several positions over the years where the opponent left a piece hanging. If you take it you lose. But to shallow searches it appears to be hanging. If you used the "easy move" logic you move too quickly, before searching deep enough to see it is a trap, and you lose.

So the issue becomes two question:

(a) is it worth moving quickly which might lead to blunders, just to save a minute or two?

(b) is it REALLY going to matter to a super-strong engine whether it has an extra 1-2 minutes for the rest of the game?

The answer to (b) is "not at all" which means the answer to (a) is "no" since any blunder loses a game, yet saving that extra couple of minutes won't add an Elo.

I've got a pretty good "easy move" scheme in Crafty, but I have some refinements on tap to test. Right now a move gets easier and easier (up to some threshold limit) as it remains best after each iteration. Any "change of mind" or "fail low" and it is back to the normal time at least. As it changes its mind, the time ramps up. If it changes every iteration, it can ramp up significantly.

I've been toying with a second-level easy concept. Do as I do now only allowing the target time to be reduced to 60% of original value, unless the move is a recapture that maintains material balance, in which case it might be safely searched with a smaller time limit. But it is tricky and it is easy to drop elo here, with very little gain if it works flawlessly. It is mainly an issue of aesthetics rather than Elo.

[Uri Blass]

SF already has a mechanism to dynamically adapt the time allocation, based on a "PV instability" measure. This is far more general than recapture.

Perhaps there is an extra elo gain in playing recaptures, or "easy moves" quicker, but despite the zillion useless tests that fishtest has endured on this subject, there is still zero evidence of it.

If you think you're smarter than we are, by all means, prove us wrong and put your code where your mouth is. But I must warn you: it's not as easy as you think…

I think that there are 2 cases:
case 1:the opponent played earlier the expected move
case 2:the opponent played earlier non expected move.

I guess that in case 2 stockfish will play relatively fast the recapture move and the main problem is case 1 because in this case stockfish may finish the first 40 iterations very fast thanks to hash tables and get stuck for a long time in iteration 41.

I think that stockfish needs some code to play faster also in the middle of the iteration in case of easy move and it is the main problem.

Note that I see some tests with positive result for fast recapture but I do not like code that is specific only for recaptures and it deals with the symptom and not with the problem.

http://tests.stockfishchess.org/tests/v ... 2cb12275c4

With obvious recapture the program does not change its mind so it should play faster without special code for recaptures if stockfish is allowed to stop in the middle of the iteration when it get big depth after the opponent played the expected move.

I did not learn the stockfish code in order to write a code that check if the opponent played the expected move and maybe somebody who knows the stockfish code better than me can write the relevant code in order to test it.

Edit:note that 1 minute when the average time is more than 1 minute is not really a problem and the problem that I talk about is using 15-20 minutes for obvious moves in TCEC games.

[Dirt]

I'm surprised it is so hard.

It is not as easy as you think.

I know, that is what makes it surprising.

Thanks for your explanation.

[mcostalba]

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.

[hgm]

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).

This virtually takes no time at all. Usually the root move is not singular, so that margin gets reset in the 1-ply iteration, and the only cost would have been that you had to do a 1-ply research with open window that you might not have had to do when you had used the normal PVS null window. Proving the score below alpha-margin is not any harder in singular positions than it is to prove below alpha in a typical position. (Of course in the singular case you could have afforded to be very sloppy with your refutation w.r.t. the normal PVS window, saving you some time there, but this is not a very effective way to save time.)

In the singular situation the margin will remain until the final iteration, and the decision to stop searching takes into account whether margin is still non-zero or not. With non-zero marging it will divide the nominal time by 10 or thereabouts.

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.

Of course the system could be refined by reducing the margin in steps, and applying more time reduction when the margin has remained larger (e.g. a factor 30 for 700cP, a factor 10 for 350 cP, a factor 4 for 200 cP and a factor 2 for 60cP). In mini-Shogi the loss of any piece means a certain loss of the game, however, so I never made that refinement in Shokidoki.

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.