AylerKupp: <profK> And Black had to be alert to the very end. If 69...Nxa4 the game is a draw per the 6-man Nalimov tablebases after 70.Kc6 a6 71.Kb7 a5 72.Bc6 even though Black is 2 connected pawns up.
click for larger viewZugswang. Black's knight can't move without giving up the b-pawn, Black's king can't move without giving up the knight, and Black's b-pawn can't move without being captured by the bishop. Interestingly, Rybka 4.1 doesn't see this even though in my computer it has access to 5-man Nalimov tablebases, evaluating the position after 69...Nxa4 at [-1.87] (winning) at d=32. Spike 1.4, which also uses Nalimov tablebases, can't see this either, evaluating the position at [-1.64] (still winning) at d=33. Using Gaviota tablebases doesn't change things much. Houdini 1.5a evaluates the position using 5-man Gaviota tablebases at [-1.07] at d=25. Still advantageous to Black but not winning. And this is a fair assessment because Black clearly has all the winning chances, and it's possible for Black to win if White does not play precisely. Critter 1.4, which also uses Gaviota tablebases, made matters worse; it evaluated the position at [-1.51] (winning, but just barely) at d=29. That's indicative of a problem that engines have with endgames. Even though the position is simplified and they can get to a given search more quickly (since there are a smaller number of move possibilities), they often can't get to a sufficient search depth in a reasonable amount of time to make the correct evaluation of the position. You could say that the correct evaluation of an endgame position is beyond the engine's horizon, even with tablebases. And, of course, you have no way of knowing whether this is the case or not. And using tablebases greatly reduces an engine's calculation rate. Using Houdini 1.5a with a 256 MB hash table, it took Houdini 00:00:23 to reach d=23 with tablebases disabled and 00:23:58 to reach the same depth with Gaviota tablebases enabled and a 64 MB tablebase cache. Spike 1.4 showed a similar behavior but not as dramatic; 00:07:04 to reach d=30 with tablebases disabled, 00:07:51 to reach d=30 with Nalimov tablebases enabled and a 64 MB tablebase cache, and 00:12:41 to reach d=30 with Nalimov tablebases enabled and a 64 MB tablebase cache. And, no, I don't know why it took longer to reach the same depth with a 4X larger tablebase cache and everything else being equal. And the evals never changed more than 10 centipawns between runs. Has anyone else seen similar behavior when using tablebases? | 
Kibitzing
sac: 40...Rxh7
