ChessBase 17 - Mega package - Edition 2024
It is the program of choice for anyone who loves the game and wants to know more about it. Start your personal success story with ChessBase and enjoy the game even more.
OK, I shouldn't be singing, especially because I told myself that I wasn't going to reply to mail in this column for a while. But I've since received a few things that were either interesting or funny. And I just spent the weekend writing four chess articles and I'm getting punchy, so there's no point in trying to write anything altogether instructive at this point -- I'd just botch it.
I won't be "naming names" this time around either. In one case there were too many, while in another the e-mail (a funny one) came in anonymously. Anyway, on to the mail!
Several friends, cronies, and a few low-lifes that I push pawns with have pointed out that my series on maintaining a playbook can (mostly) be done automatically using the Repertoire database features of ChessBase. Yes, that's true and yes, I knew that. Don't believe me? Check out my column for October 4, 1998 -- I've known about it for a looonnnnnnng time.
However, the specific article request involved Mig Greengard's piece on how Garry Kasparov maintains his "playbook" -- I was asked to describe how Garry does it. Since all I had to go on was Mig's piece and it appeared therein that Garry was doing it manually, I decided to focus on that aspect. Personally I think that it's more instructive for the user to do it manually rather than rely on the automatic function (and I myself maintain my personal repertoire databases manually rather than automatically).
So that's why I took the proverbial "long way around the barn". There is a method to my madness.
I received a really interesting e-mail forwarded to me and written by a fellow in Belgium. It too centered on the "playbook" series and read, in part:
Getting the best variations in is one thing. Evaluating them is another. If you can I'd like you to show if it is possible how to evaluate, store and display the evaluations of each move in the stored playbook lines.
In other words say I only had 2 lines in the same opening. An evaluation should show they are the same for each move up until the point of divergence. At the point of divergence there may be a difference that I would like to know.
I guess in the end what I'm trying to do put ECO in chessbase and evaluate each position after each move.
OK, I'll admit it -- that e-mail really freaked me out. I hope you didn't mean all of ECO??!!?? Man, it would take eons to do all of it!
But I think I understand what you're after. And it is (theoretically) possible...
I set out to write a "how to" for ChessBase/Fritz in response to this e-mail. But, after reflecting for a while on the e-mailer's request, I began to realize that there's fodder for a larger discussion here.
How do we decide what to play in the opening? I don't necessarily mean while we're at the board; what I really mean is "How do we decide on a repertoire and/or specific moves and variations therein?" I was able to come up with four separate methods and, after still further reflection, realized that all of them are imperfect for various reasons.
Let's list the methods we use for determining what variations we add to our repertoires:
Some of these methods are interrelated. And, as I stated a moment ago, none of these methods are perfectly foolproof.
Sometimes we select a particular opening, variation, or move based on our personal preferences. For example, I'm a gambit freak; it's really hard to stop me from giving up a pawn in the opening. Some of the gambits I play aren't terribly sound, so simple logic dictates that I should probably play something more traditional or "solid". But there are times when I can practically see Morphy and Anderssen hovering over my shoulders like buzzards, screaming "DO IT!!!!!" into both my ears -- so, like Pavlov's dog, I pitch a pawn over the side. However, I do have one mitigating circumstance in my favor: I don't play a particular gambit unless I understand the idea behind it. I don't just indiscriminately chuck a pawn -- I make sure I understand beforehand what I'm supposed to be accomplishing with the sacrifice.
The key word here is understanding (and it's a word I harp on over and over again in my columns here). It's better to understand the purpose behind a "substandard" move than to play a move just because ECO/BCO/MCO/NCO says it's what you're "supposed to play" but have no idea what that move's supposed to accomplish. Keep this in mind -- we'll come back to it shortly.
The possible pitfall with this method lies in the fact that we might think we understand the idea behind a chosen move, but we really don't. How do we really know? Usually it's because we've read up on the variation (hopefully in a variety of sources) and decided that the move is at least OK to play (if not necessarily "good"). In theory, at least, the better your home prep, the better off you'll be. But if you get lazy or start shortcutting you might wind up with a nasty surprise. That's why "Intangibles/personal preferences" is imperfect -- the results will only be as good as your research and "home work" make them.
We also rely on recommendations by writers and other chessplayers. There are more "complete repertoire" books and CDs on the market than you can shake a stick at. Many of them are pretty good, at least as starting points for building your own repertoire. A stronger player has looked at a lot of openings and offered his reasoned advice as to what you should play. This is a good thing -- he's done a lot of the "grunt work" for you.
The pitfall to this method goes back to personal preference. I like a lot of tactics in my games. If an author is recommending primarily closed games that utilize a slow buildup, his suggestions aren't likely to mesh well with my particular style of play. So here again we see an imperfection in the method.
We can always look at statistical analysis based on practical play, that is, based on games played in actual tournaments (preferably by top players). You grab a batch of games in a particular opening, merge them into a game tree, and then look at the numbers to see what scored well in real games and what didn't. Easy enough, right? But there are a couple of immediate pitfalls with this approach.
One possible drawback is the ever-present possibility of a "bust" -- a move that negates the entire line of play. You might be researching a venerable opening that's been around for years. The "top" move has been played hundreds of times and scores a 75% success rate. You say "Hot diggedy! That's what I'm gonna play!" You step ahead in the tree to see the opponent's responses. All of them score badly, except for this one move at the bottom of the list that's been played just once and scores 100% for that player. Researching it further, you see that it's the newest game in that variation -- the variation has never appeared since that one game was played in a high-level event. Chances are decent that it's a "bust" -- a move that's so good that it hasn't (yet) been refuted and has deterred top level players from using that variation ever since.
To determine whether or not it's a true "bust" will require you to do some further research. What are top players saying about that variation/move? Has anyone written anything about it (pro or con) to indicate whether or not it's a bust and whether it's been (at least theoretically) refuted? You'll need to do the grunt research work to find out.
There's yet another pitfall to the "statistical" approach. Let's go back to that "hot diggedy" move that scores 75%. Do you understand the purpose of that move? (There's that word again: understanding). Maybe it really is a good move, but it requires a certain amount of high-level skill/knowledge to be able to understand or to be able to play a proper set of followup moves. In other words, it might be a great move for grandmasters to play but if a Class C player tries it he'll soon find himself in over his head. That's why understanding is again the key.
There are other drawbacks to merely "playing by the numbers". I won't elaborate further (I've written about them in past columns) but will instead refer you to books such as How to Lie With Statistics. Note, also, that I am not suggesting that statistics aren't a valuable tool and should therefore be disregarded; you just need to be aware of the possible mathematical pitfalls and learn to use statistical results judiciously.
This brings us to computer analysis, e.g. letting a computer analyze a set of candidate moves to show you which move is the "best". Here's where I have to heave a deep sigh. Computer engines can give us a lot of valuable guideposts to help us improve our play (in fact I wrote an article back in 2000 offering suggestions on how to accomplish this; you'll find it as the March 26, 2000 issue of T-Notes, available on this very web site) but they're certainly not infallible. In fact, this approach alone has as many pitfalls as all of the other approaches combined.
The first one that springs to mind is what I call the "oracle on a disk" syndrome. Many players new to computer chess think that chess engines are infallible and don't make mistakes. That assumption's just dead wrong -- if that was so, nobody would ever beat a chess computer. When you consult a chess engine you're not consulting a perfect player -- you're consulting a better player (unless of course you're one of the world's top grandmasters; obviously, few of us qualify).
Chess engines are written by human beings and are programmed differently from each other; each brings something a little different to the table. Different engines may prefer different moves. It's akin to handing a quiescent position (one with no obvious immediate tactics or mate threats) to two top GM's, one of whom is a very positional player, the other of which is a master tactician, and asking them what's the best move in the position. You're likely to get two different answers depending on the personal preference (that again) and style of play of the player in question. The positional player might offer the suggestion of a quiet developing move while the tactician might want to push a pawn to offer a pawn break to blow the position wide open. The same thing applies to chess engines: a "solid" program like Shredder might look for a developing move while a "wild" program like Chess Tiger might try to blast open the position. Consequently they'd evaluate an opening position differently -- Shredder would likely give an evaluation closer to 0.00 than would Tiger.
And speaking of evaluations, a single engine might look at the candidate moves and evaluate them as being, say, 0.03 pawns apart. Is the move that scores 0.03 higher actually going to be "better" than the other move? Maybe just a bit -- for a computer. For a human player they're, for all intents and purposes, dead even.
I've given this one a name, too -- I call it the "ultimate truth" syndrome. More than a few players believe that every chess position has a single move that's objectively the "best" one. I beg to differ, and this too goes back to the scenario in which we handed two different payers/engines with different styles of play a position to evaluate. A Karpov might say that Move A is the "best" and it'd be true -- for Karpov -- while a Kasparov would prefer Move B, again because it'd be best for the way he plays chess.
So what's the "best" way to determine what move to play in a particular opening variation? I believe it to be a synthesis of multiple approaches: what's worked in prior play coupled with understanding why the moves were played -- then perhaps using a chess engine for a bit of guidance if you get stuck. If a move's worked well many times before and you understand the reason(s) why, you've got yourself a winner.
That's why I believe that the approach of having a chess engine (or engines) evaluate every candidate move and basing your choice on that information isn't the best way to go. For one thing it's massively time consuming and, for another, it's akin to playing blindly by rote using the numbers you'll find in a statistical game tree.
To understand part of the reason why, you have to remember a couple of points: a) all chess engines, even the positionally-oriented ones ("positionally-oriented" relative to other chess engines, that is), are still basically tactical beasts, and b) chess engines can only "see" so far ahead (even with a deeper selective search, there's still a theoretical limit to how far ahead they can look). As a hypothetical example, let's say that there are two good candidate moves in an opening position: one's a single-square pawn push and one's a Bishop move on the other side of the board. In this particular opening, the pawn push is the "better" move because it controls a square that's not going to become useful for another fifteen moves. But a chess engine can't "see" that far ahead; it's not going to know how important the control of that square is going to become (and, arguably, it might not "understand" such a positional motif even if it could see it). It's likely that the engine will prefer the Bishop move because, say, it pins the opponent's Knight and looks ahead to a possible material exchange in another five moves. But, because computers don't understand intangible or abstract ideas (e.g. "fuzzy logic"), it doesn't realize that the material swap goes against the core idea of the opening in question anyway and that the pawn push is way, way better. It's even more important that you understand the reasons why these candidate moves are good or bad, and that's not something that a computer will show you when it cranks out numerical positional evaluations.
All of that having been said, it's time to address the "nuts and bolts" of what my correspondent suggested in his e-mail. Yes, it can be done and yes, there are pitfalls here too.
Let's look at the "main line" moves for the A51 ECO code in ECO 2nd Edition. I've input them by hand, saved them, and used the "Table" view in ChessBase 9's notation pane to display them:
What we're looking at are four main variations with several branching points in the tree. I've ended each line with the Informant evaluation symbol showing ECO's evaluation of the variation.
What my e-mail correspondent is looking for is an evaluation of each branching point. Fire up Fritz (or one of its sister playing programs), load the game, and set up a "Blundercheck" analysis session with no opening book loaded (that's important because Fritz will stop analyzing when it hits a position from its opening book). Make sure you've checked both the boxes for analyzing main lines and analyzing variations. Make sure you've allowed a decent time per move for analysis -- five seconds a move just won't get it. The time you set will depend on your hardware, but you're looking to see a search depth in at least the mid-teens. Let 'er rip (probably overnight) and you'll get analysis for each move in the tree assuming that Fritz finds something better.
What you'll see for each move is an evaluation of the actual board position, a suggested line of play, and an evaluation at the end of that recommended variation. For your purposes you can forget the variations and their evaluations -- you're going to concentrate on the evaluations of the actual moves from ECO. This will show you an evaluation for each "break point" (places in which ECO shows two or more candidate moves) and should give you what you're looking for.
So what are the drawbacks? First, Fritz will only display evaluations for moves for which it found an improvement -- so if the engine finds that the ECO move is subjectively the "best", it won't provide numerical data for that position. The second doesn't apply to A51, but if you're going to try to analyze all of ECO (egad!) you'll run head on into the problem of transpositions. For example, you'll analyze a lot of English Opening positions from Volume A of ECO. But these can easily transpose to Queen's Gambit positions from Volume D -- and there's no easy way to catch these transpositions in a game database. You could merge these games into a ChessBase opening book, but the numerical evaluations (the whole point of the exercise) won't appear in the book itself.
Each of these problems has a remedy. For the first you can have Fritz evaluate the positions by hand (directly within ChessBase) by clicking the engine button, and then add the numerical evaluations yourself by typing them in an annotation window. Very labor-intensive, very time-consuming. But certainly possible.
The second problem has a remedy in a non-ChessBase product. You could use Mike Leahy's Bookup program to have a compatible chess engine evaluate the last move of each variation and then use Bookup's "Backsolving" feature to append the evaluations to each prior move in the variation. It's not quite the same thing as having an engine evaluate the "break point" candidates themselves (it's really evaluating the subsequent results), but it's close.
So there's no easy way to do what you want to do (at least not if I'm reading your e-mail query correctly). And I still maintain that you'll get farther by studying ideas rather than numbers. But it's certainly your choice as to how you want to study and proceed with your idea. In any case, I thank you sincerely for sending me a very interesting, thought-provoking question.
More from the mailbag the next time around. Until then, have fun!
