Tuesday
Mar302010
A Pair of Smyslov Studies: Solution Time
Tuesday, March 30, 2010 at 9:50PM Here are the studies again, twins composed by the late World Chess Champion Vasily Smyslov in 1976. In the first it's White to win, in the second White to draw.
Figured it out? Confirm your conclusions here.
Reader Comments (10)
Just out of curiosity, what does Rybka think of these two studies? Rybka is more staunchly averse to the Historic Episcopate than anyone I've ever discussed it with...;-)
Hum. I must be missing something. If we do 1. Bb4 Kd3, and instead of 2. f7 we bring the king closer with 2. Ke1, does that not provent the 1...Kd3 2.f7 Bd2 3.Bxd2 exd2 4.f8Q d1Q+= line you mention in the solution?
estirodri, you are correct: you are missing something. :) Black draws there too, but I'd rather not spoil the fun you'll have solving it for yourself.
Ken, Yes, Rybka 3 seems incredibly dense here - it must be a bug. Not only does it not see the underpromotion coming beforehand, it can't even find it at move 4! Of course, the program no one is supposed to mention has no trouble with this, though that one doesn't have a clue that the final position of the second study is drawn. Btw, do you have any opinions on the Rybka vs. alleged clones controversy you'd care to share here?
Just a quick note: as a design decision, Vas Rajlich decided not to implement bishop underpromotions in Rybka. It will accept them if played, but will not enumerate them in the search. Apparently positions necessitating them are too rare (rarer than the other underpromotions, at least) for it to be worth searching every time it examines a promotion. This search 'improvement' allegedly gains roughly 1-2 Elo points.
I really like this pair of studies. Unfortunately, the second one looks to me not to be in perfectly healty condition. Let's see:
1. c6 bxc6 {this might be a cook} 2. Ke6 {what else?} cxd5 3. Kxd5 c2 4. Bd2 Bb2 5. Kc6 {At first sight it looks as if White now achieves the draw by eliminating the pawn on a6. However there is a nasty surprise.} Kd8 6. Kb6 Kd7 7. Kxa6 Kc6 -+ {according to 6-men tablebase}. The tablebase main line now locks in the white king in front of his pawn. Next Black manages to win the white pawn although the pawn has to be allowed to advance to a7. Finally Black queens his extra pawn on c2 after driving the white bishop away.
Of course, White can defend slightly different from move 6 on. He may postpone taking a6 for a while. But in the long run he cannot avoid the activation of the black king. Whenever White takes on a6 the position becomes subject to the 6-men tablebases. And with this little help by computers you always see black winning.
Very nice, Christoph: I believe you're correct. Too bad for Smyslov.
To augment Vladimir's response, the design decision to remove bishop underpromotion from the search involves the binary code for special moves. For a simpler example of what I mean, Rybka users note the frequent appearance of the evaluation "+5.09" or "-5.09" in winning positions. That number comes about because it is near 2 to the 9th power = 512. Including minuses, 10 bits of a "packed" representation are allocated to evaluations, for 1,024 possibilities. The evaluations +5.09 to -5.09 occupy 1,019 of them, leaving 5 more. My guess is that 2 of them are for +Mate and -Mate evaluations, 1 is for "invalid", and the other 2 are "escapes". An "escape" would say to exit the fast assembly-language routines that used the packed code, and re-evaluate the position using a longer code---which is what produces the higher evaluations. In general chess engines slow down as the game becomes more unbalanced, but Rybka slows particularly as the evaluation goes outside the packed range.
I forget the details of how the packed code works for promotions and castling, but my recollection is that removing "=B" from the former makes the latter more efficient. There is a trick by which one can have both cakes, which other chess programs have employed, but it would require a cumbersome rewrite to the innermost parts of Rybka's optimized low-level code.
I'd known about "IPPOLIT" and Robbolito but not the latest about "Firebird". My work would potentially be able to group chess engines by similarity of their evaluation functions, and anecdotally in some positions that cause a wide spectrum across engines I notice the similarity between Rybka and Fruit/Toga. Is it the case that "Stockfish 1.6" is free of accusation of being a Rybka knockoff? It's a successorby Tord Romstad to his Glaurung engine. If and when it gains EGTB and multi-PV capability, I intend to use it as a supplement to my work with Rybka, especially since its open-sourcedness will enable me to insert some extra search cutoffs. The most important new feature of Rybka 3 for my purposes is the ability to set a "cap" on multi-PV searches of how much inferior a move needs to be to be pruned. I have to set ti to 4.00 in order to leave enough room to avoid the 5.09 slowdown issue referenced above, but I suspect that this is low enough to cause notable distortion in my statistical model and would rather use 5.00 or 6.00 if I can.
To add a sentence to what I wrote, the higher incidence of "5.09" comes about because Rybka tries to avoid escaping if it can. The resulting distortion in evaluations is more minor than what I get from the 4.00 cutoff, but still there.
Hi, Kenneth.
Stockfish is open source and absolved from most 'knockoff' scrutiny. It already supports multi-PV, but one thing to note is that it will never support the Nalimov EGTBs because of the license incompatibility between the GPL and Eugene Nalimov's code. That fact notwithstanding, it is surprisingly strong in the endgame. Also, much recent work has been done to create different EGTBs under a non-restricted license, called the Gaviota tablebases. The probing code has been widely, freely released with support for on-the-fly bitbases (probing only Win/Loss/Draw information instead of depth-to-mate for speed reasons). Many engines may come to support it, but that remains to be seen and few do at the moment.
It's interesting what you say about Rybka and Fruit. When Rybka 1.0 was first released, many respected engine programmers came forward with evidence that it took code directly from Fruit 2.1. The significance being that if one uses code from a GPL program, they are required to release any subsequent code under the GPL so that it always remains open source. Of course, that never happened and nothing was really done about it. If there really was any Fruit code used in Rybka 1.0, it's unclear how much of it remains in Rybka 3.
To Dennis about the cloning: At first, Rybka was decompiled and merged with Fruit code into a clone called Strelka. It created a big stir, but people moved on after Rybka 3 was released. Afterward, the IPPOLIT site appeared with laughably machine-translated, anti-capitalist rants and source code that was obviously decompiled. The anonymous authors called themselves 'comrades' and alluded to revolution in its somewhat hyperbolic statements of surpassing Rybka. Most people assumed that it was clearly a shamelessly reverse-engineered Rybka, and Vas came out and denounced it, saying that the cloners had even been e-mailing him their progress along the way.
It indeed seemed strange that an engine roughly the strength of Rybka came out of nowhere, created by several anonymous authors in secrecy, and was released freely as open source. It was also strange that these gifted, selfless programmers couldn't even correctly implement the UCI protocol. Robbolito was the next to be released, and its code was readable but somewhat strange as well. It had no comments at all (which is unheard of in such a complicated program), and its variable names were in machine-translated Italian. Other roughly equivalent engines were released next: Igorrit, Ivanhoe, Firebird, etc. Of course, none of that constitutes any form of proof. And if someone decompiled Rybka, took all of the brilliant ideas, and then wrote everything from scratch, it would be shady but fully legal.
I've heard a lot of apologists' reasons for using Robbolito. Vas cloned Fruit before, so it's okay. Or Vas promised a free Rybka 3+ update with bug fixes and features but never delivered, so it's okay. Or Vas never released any conclusive evidence that it's a clone (tantamount to releasing his own source code), so it's okay. At any rate, the cat is out of the bag, and you can do with it what you will. Personally, other free engines are more than strong enough for my purposes, and I prefer to support those authors with names and faces over potentially getting my hands dirty. Other people may feel differently, and it doesn't really matter in the end. If you're undiscerning, it'll certainly make a strong analysis partner.
Dear Vladimir,
Thanks. I should also clarify that the Fruit-Rybka similarities I noted were over 3 years ago, for Rybka versions 1.x and 2.0, maybe not even 2.2n2. Rybka 3 gives a much different verdict on my most particular position, which is 8/1r2K3/8/3N4/8/2Q1B3/4q3/3k4 w - - 0 0, White (in check) to move. I've verified to my satisfaction that this is a draw (1. Kd6 Rb1! but not ...Qb2? which loses), but many engines---some only with particular hash-size settings---give White +6 or higher at certain depths. This position has many tricky features, most notably horizon effects associated to the line 1.Kd6 Rb1 2. Qd4+ Kc2 3.Qc5+ (Qa4+ is a dangerous attack) Kb3 4. Qb6+ Kc2 [now many other checks can intervene] 5.Qxb1+ Kxb1 6.Nc3+ Kc2 7. Nxe2 (2-ply quiescence, winning?) Kd3! drawing. One commercial engine gave a too-high eval because of over-aggressive pruning; its author thanked me for helping debug. I wonder about the same for Rybka 3, since its eval is "too high" (and in analysis scripted by Arena I see pruning that strikes me as stopping at too low a depth, even if you add 3 to the reported depth), but for Rybka 3 none dare call it a bug :-).
Thanks also for confirming that Stockfish is all-clear, as I expected. I share your opinion of the allegedly-decompiled ones and your reasons for avoiding them. Curious about the Nalimov bases---I'd wish that to be cleared up.