Mar-13-07 | | sheaf: no kibitz on this game !! nice shot Rxd4!.. |
|
Feb-29-08 | | VaselineTopLove: 31. Qf4!
Instead, had Anand played the obvious looking 31. Rd1?? then 31. ...Bxf3
32. Rxd6 Ra1+ followed by mate |
|
Aug-25-14 | | mchinitz: Hi,
The sack looks interesting. I'm confused why Black doesn't do 19... Rd8 (20. Qxf6 Qe5 or 20. Qxb4 Rb5)? Houdini even gives advantage to Black? |
|
Jan-03-21 | | Brenin: A very neat finish! I love how Anand's 38 Qg7+ forces Leko to lock his K in with f6, and he then quietly threatens mates on f4 and e3 with 38 Qh6. Black's 38 ... Ke4 would have been no better, allowing 39 Qd4+ Kf3 40 Rd3+ Ke2 41 Qe3 mate. |
|
Jan-03-21
 | | Messiah: In my younghood I tried for a very long time to understand this exact game, with limited success. It is not nice at all that I completely forgot it since then! Thank you very much for the (unintentional) reminder; it is really good trying to return into Anand's unmatchable brain. |
|
Jan-03-21 | | goodevans: The inconsistencies of SF annotations strike again: "32.Qb8+ <better is 32.Bxc6 Qxc6 33.Qb8+ Ke7 34.Rd1 Qe8 35.Qxb4+ Kf6 36.Qf4 +- +7.42 (27 ply)> 32...Ke7+- <+3.46 (29 ply)> 33.Bxc6 Qxc6". What was played was just a transposition of what SF gave as "better". There are only two possibilities: Either <33...Qxc6> was a serious error that cost black ~4 points evaluation <in which case why didn't SF call it out>; or <SF was just plain wrong> to call out 32.Qb8+ as a mistake. My money's on the latter. These fairly frequent issues make you lose faith in the SF annotations. Makes me wonder what the point is of publishing them without 'sense checking' them first. Still, at least today's little oddity isn't a patch on <labelling Nunn's winning move as a blunder> in Nunn vs J A Sutton, 1984! |
|
Jan-03-21 | | goodevans: Just to be clear, my gripe here is not that SF makes mistakes (we all know it's not perfect). It's that these mistakes get included in the annotation without any sort of check. If a patzer like me can pick up on them in seconds then surely that wouldn't be too hard to do. |
|
Jan-03-21 | | Ironmanth: Diabolical work by Vishy! Thanks, chessgames. Y'all stay safe, play hard, play often! |
|
Jan-03-21
 | | AylerKupp: <Stockfish observations>: (part 1 of 3) <<goodevans> The inconsistencies of SF annotations strike again"> A few observations:
1. Yes, you must definitely check <ALL> computer lines for reasonableness before you post them, not just Stockfish's. I try to do that before I post and, if I can't because of time constraints, I always indicate when I don't. Sort of a caveat emptor warning. Even better, everyone doing chess engine analysis who are below the GM level (and even then!) should take the opportunity to try to understand why the engine chose the move it chose as being the best move. That will likely help you improve your chess regardless of your playing strength. 2. d=29 is not a very deep analysis, particularly with Stockfish, you should generally continue the analysis until the mid 30's ply and preferably the low 40's in order to have equal confidence in its evaluations (or even lines and move rankings) as with other top-level search engines at much lower plies. Stockfish prunes its search tree more aggressively than other top engines and that's why it can reach deeper search depths in the same amount of time. But there is no such thing as a free lunch, as a result of its more aggressive search tree pruning it is more likely to miss the best lines than other top engines at the lower search plies. 3. The horizon effect is always a potential factor and more so for the early moves in a line at lower search depths. So, for the first 10 moves or so Stockfish at d=29 is potentially more affected by the horizon effect as other top engines. 4. Multi-core chess engines are greatly affected by non-determinism. If you run an analysis of the same position, on the same computer, with the same chess engine, and to the same search depth after clearing the hash table before each analysis you will get different results. Not <MAY> but <WILL>. Guaranteed, just try it and see. The differences might be slight such as slightly different evaluations but sometimes they may be drastic enough in complicated positions like this one where Stockfish's evaluation of 32.Qb8+ is very similar to that of 32.Bxc6 than its move rankings will vary every few plies or even every ply, particularly at low search depths. So you need to look at the history of ply-by-ply evaluations to see if they are changing and, if they are, the position is simply too complex for Stockfish or other chess engine to properly evaluate. Letting the engine analyze longer may allow one move to consistently "move ahead" of other moves and the move rankings will stabilize, but sometimes they just don't and you just have to accept the ambiguity. As an example, I ran 3 successive Stockfish 12 analysis runs on my computer. Here are the 3 sets of results both at d=29 and at whatever depth Stockfish reached when I stopped the analysis. First I'll present a summary and I'll follow it up with the details. 5. Non-determinism aside, transposition of moves may or may not be significant depending on whether one side or the other had other move options during the transposition that may significantly affect the evaluation. After 32.Bxc6, 32...Qxc6 is forced, and after 33.Qb8+ Black has the option of playing either 33...Ke7 or 33...Kd7 As far as move transpositions are concerned, in the game line after 32.Qb8+, Ke7 (forced) 33.Bxc6 Qxc6 is pretty much forced although, strictly speaking 33...Qxc6 is not forced. But after 32.Bxc6 Qxc6 (pretty much forced) 33.Qb8+ and now Black can legally play either 33...Ke7 or 33...Kd7. In this case the second option is of course no good because of 34.Rd1+ Ke7 (forced) 35.Qd8#, so it should not be a surprise that Stockfish selected 33...Ke7. But in other cases the situation may be different, particularly if the move transposition requires more moves to reach the same position. In chess, contrary to physics, the position (i.e. work) is NOT independent of path. That's an old joke from my college days. |
|
Jan-03-21
 | | AylerKupp: <Stockfish observations>: (part 2 of 3)> <Summary> The top 2 moves were 32.Qb8+ as played in the game and 32.Bxc6. In the 3 analysis runs at d=29 32.Bxc6 was ranked # 1 in all 3 runs and 32.Qb8+ (as played in the game) was not ranked #1 at all. At the higher search depths (d=33, 37, and 39 respectively) 32.Bxc6 was ranked # 1 one time and 32.Qb8+ was ranked #2 twice. So, overall, 32.Bxc6 was ranked #1 4 times and 32.Qb8+ was ranked #1 twice. At d=29 32.Bxc6's average evaluation was [+5.94] and 32.Qb8+'s average evaluation was [+5.58]. At higher search depths the evaluation of <both> 32.Bxc6 and 32.Qb8+ was the same, [+7.03], so it's not surprising that Stockfish's move rankings would vary over a small number of plies. Overall 32.Bxc6 had a slightly higher evaluation, [+6.49] to 32.Qb8+, [+6.31]. But not much importance should be attached to the rankings and evaluation in this and similar cases. First of all, they depend on the search depth; stopping the evaluations at a certain depth may change the conclusions regarding which move is "best" in that position. Second of all, from a practical perspective all evaluations for both moves, regardless of search depth, indicate that the position is theoretically winning for White irrespective of which move was played so it really doesn't matter which move is "best". <Details>
<Stockfish 12, Run 1:> 1. [+5.78], d=29: 32.Bxc6 Qxc6 33.Qb8+ Ke7 34.Rd1 Qd5 35.Qxb4+ Ke8 36.Qb8+ Ke7 37.Qc7+ Kf6 38.Rxd5 exd5 39.Qd6+ Kg7 40.Qe5+ Kg8 41.Qxf5 a5 42.c3 h6 43.Qg4+ Kf8 44.Qd4 Kg8 45.Kg2 Ra1 46.Qxd5 Ra3 47.Qd8+ Kg7 48.Qd1 Kg8 49.Qd5 Ra2 50.Qf5 Kg7 51.Qe5+ Kg8 52.Qf6 Rb2 53.Qd8+ Kg7 2. [+5.34], d=29: 32.Qb8+ Ke7 33.Bxc6 Qd2 34.Rf1 Rxc2 35.Bf3 f4 36.g4 h6 37.g5 hxg5 38.hxg5 Rc1 39.Rxc1 Qxc1+ 40.Kg2 a5 41.Qb6 Qd2 42.Qa7+ Kf8 43.Qb8+ Kg7 44.Qe5+ Kg8 45.g6 fxg6 46.Qxe6+ Kg7 47.Qe5+ Kh6 48.Qxa5 Qd4 49.Qc7 Qg7 50.Qxf4+ Kh7 51.Bd5 Qc3 52.Qd6 Kg7 53.Qe7+ Kh6
---
1. [+6.38], d=33: 32.Qb8+ Ke7 33.Bxc6 Qd2 34.Rf1 Rxc2 35.Qe8+ Kf6 36.Bf3 Rc1 37.Bh5 Rxf1+ 38.Kxf1 Qd5 39.Qxf7+ Ke5 40.Qg7+ Kd6 41.Qf8+ Ke5 42.Qb8+ Kf6 43.Kg1 Qxb3 44.Qh8+ Ke7 45.Qxh7+ Kd6 46.Qa7 Qc4 47.Qb8+ Ke7 48.Qe8+ Kd6 49.Qf8+ Ke5 50.Bd1 Qc1 51.Qb8+ Kf6 52.Qd8+ Kf7 53.Qd7+ Kf6 54.Kh2 b3 55.Bxb3 Qe1 56.Qd4+ Kg6 57.Bd1 2. [+6.25], d=33: 32.Bxc6 Qxc6 33.Qb8+ Ke7 34.Rd1 Qd5 35.Qxb4+ Kd7 36.Qb7+ Kd6 37.Qb6+ Ke7 38.Qc7+ Kf6 39.Rxd5 exd5 40.Qd6+ Kg7 41.Qe5+ Kg8 42.Qxf5 a5 43.c3 a4 44.Qg4+ Kf8 45.Qb4+ Kg7 46.Qxa4 Rb2 47.Qd4+ Kg8 48.Qxd5 Re2 49.Qg5+ Kf8 50.Kg2 Re8 51.Qb5 Re6 52.Qd7 h6 53.Qc8+ Re8 54.Qc5+ Kg7 55.Qd4+ Kg6 |
|
Jan-03-21
 | | AylerKupp: <Stockfish observations>: (part 3 of 3) <Stockfish 12, Run 2:> 1. [+5.86], d=29: 32.Bxc6 Qxc6 33.Qb8+ Ke7 34.Rd1 Qd5 35.Qxb4+ Kf6 36.Rxd5 exd5 37.Qd6+ Kg7 38.Qe5+ Kf8 39.Qxf5 h6 40.Qh7 Ke7 41.Kg2 a5 42.Qf5 Kf8 43.Kf3 a4 44.Qc8+ Kg7 45.bxa4 Ra3+ 46.c3 Ra1 47.Qa8 Rd1 48.Ke2 Rb1 49.Qxd5 h5 50.Qxh5 2. [+5.55], d=29: 32.Qb8+ Ke7 33.Bxc6 Qd2 34.Rf1 Rxc2 35.Bf3 f4 36.g4 h6 37.Qb7+ Qd7 38.Qxb4+ Qd6 39.Qb7+ Qc7 40.Qe4 Rc3 41.Kg2 Rxb3 42.Qd4 Qc3 43.Qa7+ Kf6 44.Qa8 Kg6 45.Rd1 Qxf3+ 46.Qxf3 Rxf3 47.Kxf3 f5 48.Kxf4 fxg4 49.Kxg4 a5 50.Ra1 h5+ 51.Kf4 Kf7 52.Rxa5
---
1. [+7.13], d=37: 32.Qb8+ Ke7 33.Bxc6 Qd2 34.Rf1 Rxc2 35.Qe8+ Kf6 36.Bf3 Rc1 37.Bh5 Rxf1+ 38.Kxf1 Qc1+ 39.Kg2 Qc7 40.Qh8+ Ke7 41.Qxh7 Qc6+ 42.Kg1 Qe8 43.Qg7 a5 44.Kh2 Qf8 45.Qg5+ Ke8 46.Qf6 Qe7 47.Qe5 Qd7 48.Qxa5 Qd4 49.Qa8+ Ke7 50.Qb7+ Kd6 51.Qb8+ Kd7 52.Kg2 f4 53.Qxf4 Qxf4 54.gxf4 f6 55.Kf3 Ke7 56.Ke4 Kf8 57.Bg4 Kg7 58.Bxe6 Kg6 59.h5+ Kg7 2. [+7.02], d=37: 32.Bxc6 Qxc6 33.Qb8+ Ke7 34.Rd1 Qe8 35.Qxb4+ Kf6 36.Qc3+ e5 37.Rd6+ Kg7 38.h5 h6 39.Qe3 f4 40.gxf4 Qe7 41.Rb6 Kh7 42.fxe5 Qg5+ 43.Qxg5 hxg5 44.Rc6 a5 45.Kg2 a4 46.bxa4 Rxa4 47.c4 Ra1 48.Rf6 Kg7 49.f4 gxf4 50.Kf3 Rf1+ 51.Kg4 f3 52.h6+ Kf8 53.Rxf3 Rg1+ 54.Rg3 Rc1 55.Kf5 Rxc4 56.h7 <Stockfish 12, Run 3:> 1. [+6.17], d=29: 32.Bxc6 Qxc6 33.Qb8+ Ke7 34.Rd1 f6 35.Qd8+ Kf7 36.Rd7+ Qxd7 37.Qxd7+ Kf8 38.Qxe6 Rxc2 39.Qxf6+ Ke8 40.Qe5+ Kd8 41.Qxf5 Rc1+ 42.Kg2 Rc7 43.Qa5 h5 44.Qb6 Kd7 45.Qxa6 Rc1 46.Qb7+ Kd8 47.Qd5+ Kc7 48.Qxh5 Rc6 49.Qe5+ Kb6 50.Qb8+ Kc5 51.Qa7+ Kd6 52.Qd4+ Kc7 53.Qxb4 Kd7 54.h5 Re6 55.g4 Re8 56.g5 Ke6 57.Qe4+ Kf7 2. [+5.84], d=29: 32.Qb8+ Ke7 33.Bxc6 Qd2 34.Rf1 Rxc2 35.Qe8+ Kf6 36.Bf3 Rc1 37.Bh5 Rxf1+ 38.Kxf1 Qd5 39.Qxf7+ Ke5 40.Kg1 Qxb3 41.Qxh7 Qb1+ 42.Kh2 Qe1 43.Qg7+ Ke4 44.Kg2 Kd3 45.Bf3 Qc3 46.Qd7+ Kc2 47.Qxe6 f4 48.g4 b3 49.h5
---
1. [+7.83], d=39: 32.Bxc6 Qxc6 33.Qb8+ Ke7 34.Rd1 Qe8 35.Qxb4+ Kf6 36.Qc3+ e5 37.Rd6+ Kg7 38.h5 h6 39.Qe3 f4 40.gxf4 Qe7 41.Rb6 Kh7 42.Qe4+ Kg7 43.Kg2 Qe8 44.fxe5 Ra5 45.Qg4+ Kh7 46.Qf4 Kg8 47.Rxh6 Qxe5 48.Qxe5 Rxe5 49.Rxa6 Rb5 50.Kh3 Rb7 51.c4 f5 52.Kh4 Rb8 53.Rf6 Kh7 54.Rd6 f4 55.Ra6 Kg7 56.Kg4 Kh7 2. [+7.59], d=39: 32.Qb8+ Ke7 33.Bxc6 Qd2 34.Rf1 Rxc2 35.Qe8+ Kf6 36.Bf3 Rc1 37.Bh5 Rxf1+ 38.Kxf1 Ke5 39.Qxf7 Qd5 40.Kg1 Kd4 41.Bd1 Ke5 42.Qc7+ Kf6 43.Bh5 Qxb3 44.Qf7+ Ke5 45.Qxh7 Kd6 46.Qh8 Qc4 47.Qf8+ Kd7 48.Be8+ Kc7 49.Qe7+ Kb8 50.Qd6+ Kb7 51.Ba4 Qc3 52.h5 f4 53.gxf4 Qa1+ 54.Bd1 Qg7+ 55.Kf1 a5 56.Qxe6 Qd4 57.Bf3+ Kc7 58.Qe7+ Kc8 59.Qb7+ Kd8 60.h6 b3 61.Qb8+ Ke7 62.Qxb3 Kf8 <Conclusion:> "Inconsistency" in Stockfish's, as well as other engines' evaluations, is not only not unreasonable but expected. When apparent aberrations are found, one must look deeper to find the reasons and not just assume that Stockfish, or any other engine, may have made a mistake. |
|
Jan-03-21 | | goodevans: <AylerKupp> Your extensive analysis is very much appreciated and there is stuff there that is new fodder for me to consider, thanks. How on earth outside of quantum computing can an engine come up with different answers when asked the same question twice? And whilst I would recommend others to read through your posts in full, it's one of your first statements that goes to the heart of my gripe: <Yes, you must definitely check <ALL> computer lines for reasonableness before you post them.>. That clearly isn't happening here. But your concluding passage was also most interesting. In my posts l often try to work out why humans err but doing the same for engines is a very different challenge. One last thought, I've noticed that the evaluation given to 'move X' can often be quite different to the evaluation of 'a two move repetition of position followed by move X'. Looks like sloppy programming to me. |
|
Jan-03-21 | | SChesshevsky: Might be Leko's principled play let him down here. 25...Bb5 looks logical but appears to then make both whites B and N really good with blacks king vulnerable at e8. Not that the move is losing but does seem to force black to push with initiative if he wants to maintain any advantage. Necessary to offset maybe weaker king and worse pawns. |
|
Jan-04-21
 | | AylerKupp: <<goodevans> That clearly isn't happening here.> You're absolutely right. I meant to add the remainder of my 1st observation, "I try to do that before I post and, if I can't because of time constraints, I always indicate when I don't. " Because, since I was rushed and had many other things to do, I didn't follow my own advice. It's a reversal of the usual saying "Do as I do, not as I say". Mea culpa. As far as to why outside of quantum computing can an engine come up with different answers when asked the same question twice (or more often), I have read that it has to do with (1) modern computers having multiple cores executing in parallel and (2) the alpha-beta search tree pruning algorithm whose performance is very sensitive to the proper ordering of moves to consider as candidates for expansion. But a warning, it's complicated. Typically what happens is that the calculations that the chess engine software needs to do is split up into execution units called "threads". So when one thread is, say, expanding one branch of the tree another thread is expanding another branch of the tree, as long as the expansions of the two branches can be done in parallel. Typically one thread is assigned to one core to execute unless your computer has an Intel chip, supports hyperthreading, and hyperthreading is enabled. In that case the software "sees" twice the number of physical cores although in reality these "phantom cores" can't execute computer instructions as fast as physical cores so twice the apparent number of cores don't speed up calculation by a factor of 2 but in reality by a factor of 1.1, 1.2, 1.3 etc. depending on the actual instructions being calculated. And sometimes it even runs slower because of the interference between the threads executing in the physical cores and the threads executing in the "phantom cores". What I've read is that while all these threads are executing the chess engine software in parallel they are interrupted by higher priority system processes. In my case it's even worse because I run my chess engine at lower priority than other applications so that I can run my chess software along with other applications such as a word processor, a spreadsheet, etc. and the performance of these applications is not notably impacted. Sure, the chess engine runs slower, but if it's a word processor in can run using one less core than you physically have available. At any rate, from what I've read, these other processes (and, in my case, other applications) interrupt the chess engine's threads so that the time required for the evaluation of different branches of the search is not the same from analysis run to analysis run, causes the threads to terminate at different time relative to the termination of a similar thread during a previous analysis run and causes a different ordering of the moves to be expanded into a subtree. And, since only a relatively small number of subtrees are evaluated, particularly if you're using Stockfish, the backtracking inherent in the minimax algorithm causes different evaluations to propagate to the root of the search tree. I don't know if I buy that but I haven't had the time to verify it by examining the Stockfish code. But I've observed this many times and so have others. I have also found that the non-determinism can be very greatly reduced (but apparently not entirely eliminated, which I don't understand) if you only use one core, and that the non-determinism can be seen if you use as few as two cores. Which I also don't understand, I would have thought that the amount of non-determinism, as determined by the number of differences in evaluations and move rankings would be proportional to the number of cores used but apparently that's not the case. So perhaps the start of this song is appropriate: https://www.youtube.com/watch?v=1eD.... ("Something's happening here, what it is ain't exactly clear.") A while back a version of Komodo offered an option to eliminate non-determinism but it made it run considerably slower so, understandably, it wasn't very popular. But of course, "sloppy programming" can never be ruled out. So I think that anyone that gets suspect results from using a chess engine, particularly Stockfish, needs to rerun the analysis, preferably twice more, and take an average of the evaluations. Fortunately Stockfish is relatively quick in reaching reasonable search depths so this can be done relatively quickly. Or, better yet, allocate only one core to your chess engine and let it run overnight so you put your sleep time to additional productive tasks. |
|
|
|
|