Monday, December 16, 2013


Revisiting the question of whether you should trust your machine when it comes to rook endgames.

This was supposed to be the 52nd. I miscounted though, and it turns out I got there last week. 52 rook and pawn posts in one calendar year, a rare - probably unique in my case - example of a new year's resolution fulfilled. I'm not sure that I actually expected to do it when I started, but here we are. Job done.

Anyhoo, today we've got London Chess Classic winner Hikaru Nakamura, Emms' Survival Guide helping us out of a hole and Chessbase embarrassing themselves.  On with the show.

@Engines: You suck. There. I said it.

Well, not really. Not all of them. The one I've got running on my phone seems considerably better at rook endings than my old Novag - Super Things I, II, III - anyway.

Still, I don't fully trust them. Nalimov, if used with care, might be one of the greatest learning tools the chess world has ever seen, but the Bloody Iron Monsters? As a way to blunder check they're helpful, I suppose, but I'm wary about taking it  much further than that. Ironically it seems to be that the simpler the position, the less useful they are.

Amusingly enough, one of the best examples of what can go wrong when you let an engine have a crack at analysing a rook ending comes from the most prominent purveyor of electronic chess tat themselves. To whit: the screen shot above. It's part of a Chessbase report on last year’s Tal Memorial. Click on it and take a closer look if the mood takes you. You'll see its tits very much in an upward trajectory for our electronic friend.

We join McShane - Nakamura at move 70. The American having just blocked a check with his own rook, we have another demonstration of how understanding rook endings rests on a correct evaluation of the pawn endings that would result if the rooks fell off the board.

Clearly an exchange is not forced here, but Luke chose to trade anyway. Whatever engine Chessbase were running to do their auto-analysis didn’t like the swap, though. As you can see, it gives 71 Rxd4 a “?!” and concludes that the position after black recaptures is lost.

Then …

… few moves of king shuffling later the engine gives Nakamura’s 74 … Kd2 a “??” thinking McShane is drawing after 75 Kf2.

Perhaps strangest of all …

… is the “??” which is attached to 77 … h3. A horizon effect problem, I suspect, but still a bit weird given that the machine tells us that the position is still drawn after White’s reply. Which is to say that it thinks the ‘blunder’ has changed absolutely nothing.

Luke takes a peek at the Chessbase evaluation window

McShane and Nakamura have 5,500 elo points between them. What to make of the engine’s opinion of their play here? You’d think they’d know what they were doing in such a simple ending wouldn’t you?

Not that you have to be a Super-GM to see that, push his h-pawn on move 77 or otherwise, Black’s chances of winning are slim to none (and Don King would tell you that slim leaves town when White refrains from gxh3). Neither, for that matter, do you have to be 2700 to know that the rook ending was drawn all along. Even a modest sub-2000 fellow such as myself can see the computer’s ability to calculate a zillion variations a second and raise it a little knowledge mixed with a pinch of understanding.

I first saw the rook exchange/stalemate combo in John Emms’ Survival Guide to Rook Endings. On page 44 you’ll find Emms gives a game of his own from the mid 90s in which he failed to win with rook plus g&h pawns against rook plus a g pawn. A game which, as it happens, he played against … Luke McShane!

It's a trick well worth knowing. Maybe somebody should tell the Chessbase lads about it.

Rook and pawn Index

BitingtheHandThatFeeds Department: Luke from here
Herbie from here

No comments: