• Home

Rybka 4 In-Depth Report

Rybka 4 In-Depth Report - Part One

Introduction

by Steve Lopez

The chess engine everybody's been talking about - Rybka - is now part of the Fritz "family" of playing programs. The ChessBase-distributed version of Rybka 4 comes in the familiar "wrapper" of the Fritz family (the ChessProgram12 GUI), so it shares the features of the Fritz interface, including playing and analysis modes. But Rybka possesses several twists all its own, and we'll be exploring these in this special series.

. The first distinction is between the two Rybka packages which ChessBase offers. Rybka 4 is the standard GUI and engine package, while Deep Rybka 4 is designed for multiprocessor machines.

Both packages each contain a further set of engines - 32-bit and 64-bit engines. The 64-bit engines run only under Windows versions which support 64-bit processing, while the 32-bit engines run under either 32-bit Windows or 64-bit Windows. You don't need to make any kind of purchasing or installation choice here - whichever version of Rybka 4 you purchase and install, the proper engines will be installed automatically.

Don't pass up your chance to get Steve Lopez's Guide to Computer Chess. The CD is a complete step-by-step tutorial on how to use Fritz Family of chess software programs (and other chess playing programs, such as Shredder) to improve your chess game. While the bulk of the CD consists of explanations of Fritz' features and how they work. Click here to learn more

Rybka 4 In-Depth Report - Part Two

Handicapping Rybka 4

Chess programmers have for many years been finding some unique means of "handicapping" their chess engines to make said engines play a weaker chess game should the human user desire one. The reason for this should be obvious: not everyone enjoys getting his or her head torn off by a 2700+ Elo player on a daily basis.

The challenge for programmers over the past ten or twelve years is to find a means of making such handicapping essentially transparent to the user. The paradox is that a person using a chess playing program as a practice tool wants the option of "dumbing down" the chess engine, but he doesn't want to feel like he's playing said engine under handicap conditions.

In my opinion, the problem for a chess programmer is that it's difficult to find a really elegant solution for this paradox (or even just a passable solution which will please a majority of users), and searching for one simply takes time away from what are arguably more crucial programming concerns. The programming team for Rybka4 has opted for the direct approach; instead of offering a "transparent" solution, they've gone straight for the bare-bones approach with two new handicap forms for their software.

People who have read previous ChessBase releases about Rybka may have received the wrong impression about the two handicap modes which we're going to discuss in this column. The two modes are not designed to work together; they are, in fact, two distinctly separate modes for handicapping a chess game.

The first of these modes is a truncated opening book. There are two schools of thought regarding opening libraries for chess computers. The first is that a larger opening book is good for training purposes, because the human user will see a broader array of openings which he's likely to encounter when facing human opposition. The second school of thought is that a larger opening book gives the chess engine some kind of "unfair advantage" over a human opponent.

I've been in the chess software business for a decade and a half, and I find that second school of thought to be quite curious, given the sheer number of chess opening books, disks, and reference materials I've sold (and provided support for) over those years. Chessplayers spend far too much of their study time on the opening; in light of this, the idea that a computer program shouldn't have access to a detailed opening book is like saying one's opponent in a sprint should have his feet tied together.

However, that having been said, I can understand why a novice chessplayer might voice that particular opinion. In such a case, a player who doesn't know a King's Indian from a Ruy Lopez might well feel overwhelmed by playing a chess engine which references an opening book containing hundreds of thousands (even millions) of moves/positions. Rybka4, in addition to an opening book designed for normal play, also contains a second "handicap" book which goes just three moves deep. Note that by "three moves" I mean three move pairs (six plies, in "chess computerese"). This opening book, incidentally, can be used by any chess engine running within the ChessProgram11 interface; it's not limited to just Rybka4's use alone.

Another use for this handicap book is as an opening library for engine vs. engine games, matches, and tournaments. Since the book is a mere three moves deep and contains no "weighting" factors based on results of human games, it will provide a certain level of variety to games pitting engines against each other without unduly affecting the end result(s).

Note that the filename for this opening book is handicap.ctg; it's copied to your hard drive when you install Rybka4. The exception occurs if you selected a "Custom" installation and opted to not install the opening books. In this case, you'll find the book on your Rybka4 DVD:

If you need to copy the opening book manually, please be sure to copy all three of the tree files shown above (the file extentions are .ctb, .ctg, .cto) into the same hard disk folder, otherwise the tree won't work. Also be sure to remember which folder you've copied them to; after launching Rybka4, you can go to "File/Open/Openings book" and use the File Select dialogue to "point" the software to the proper opening book.

Another time-honored handicapping tradition is the "Material" or "Material+Move" handicap. This is often used today when teaching a novice chess player; the more experienced player removes a certain amount of material from the board (and may also give the less experienced player the White pieces; hence the "+Move" aspect). I've used this technique extensively when teaching children or teenagers to play. I'll remove my Queen from the board at the start of each game until they reach a point at which they regularly win games. Then I'll give "Rook odds" until they progress to a "minor piece odds" level, and so on.

Although this technique is primarily used as a teaching device today, there was a time in the 1800's when the technique of "giving odds" to the weaker player was a standard practice. It helped give the less experienced/less accomplished player a fighting chance while providing a more challenging game to the stronger/more experienced player (one of my favorite games I ever played was one in which I gave Queen odds to a teenager who'd just learned the game, and it was a challenging game for us both; the game is briefly described in my column "The Crossroads" [published in the year 2000 and which has been reprinted in various places around the Internet]).

For some reason, this tradition of offering "odds" has died off (at least among adult players); apparently many people find the concept to be somehow "insulting". However, if a player is willing to swallow a bit of that unreasonable pride and wishes to play that type of "odds" game against his Rybka4 software, that handicap mode is offered by going to the File menu, selecting "New", and then "Handicap position":

The dialogue offers a variety of "odds game" forms, all of which were traditionally used in the 19th Century. You can simply select one, click "OK", and the board will automatically be set up with the proper odds given (i.e. with the proper material missing). If you've selected "Material+Move" odds, that will also be automatically taken into account. If you've selected an option which gives Rybka the White pieces (you'l know this because the Black pieces will be at the bottom of the screen), just hit the Spacebar on your keyboard to have the engine start the game by making a move.

And by no means should you be "embarrassed" by playing an odds game against a computer program. It's just between you and your software; nobody else will ever know about it (unless you tell them). Best of all, it's actually fun and, if you're blessed with a bit of imagination, it's easy to picture yourself playing a game against a world-famous player in a Paris opera box sometime in the mid-1800's.

Until you return to the 21st Century, have fun!

Rybka 4 In-Depth Report - Part Three

Rybka Monte Carlo Analysis

Now for the moment for which everyone's been eagerly awaiting (if the e-mails jamming my electronic mailbox are any indication); in this week's installment of Rybka 4 In-Depth Report we're going to talk about the "Monte Carlo" analysis feature in Rybka 4

Mind you, I'm not trying to make anyone feel badly or anything, but more than one of these e-mails say that the feature is "under documented". I'll tell you straight away, there's not a lot here which requires a boatload of documentation. Basically, here's what "Monte Carlo analysis" is: you start with a game position, activate the feature, and then the Rybka engine plays a whole lot of games against itself (starting from that position), but instead of storing the games in a database (as the "Shootout" feature does), it stores all of the moves of those games in tree form.

That's it. Think of it as being similar to the Shootout feature (with which you're hopefully already familiar) with a couple of main differences: the results are stored as a tree, and the engine keeps playing games against itself endlessly until you stop it (instead of Shootout's pre-programmed "cap" on the number of games played).

Let's see this analysis mode in action to get a better grasp of what it does. We'll start with a position from a game played in 1901 in - you guessed it - Monte Carlo. My "old friend" David Janowski (who I wrote about at length in one of my e-books, Battle Royale) has the Black pieces against M. Didier. White has just played 14.c3 to reach the following position:

We should keep in mind here that this game takes place in 1901. These were the days when Janowski was a feared and respected chess competitor, very unlike his later gambling-addicted dissolute self of the mid-1920's. What does David Janowski do in this position?

I'll admit that as I replayed this game, I never saw this coming. Instead of living with the two White Knights supporting each other, Janowski sacrifices the Exchange by playing 14...Rxb6 15.Nxb6 Qxb6 16.cxd4 exd4. My curiosity piqued, I decided to see how a Rybka Monte Carlo analysis would turn out starting from the position after 14.c3.

To start a Monte Carlo analysis from a particular position, go to the Tools menu, select "Analysis", and then "Monte Carlo" from the submenu (note that this function will be in grey half-tone and unavailable unless you've already loaded a Rybka engine). The next thing you know, something startling happens: the game in your Notation pane disappears, to be replaced by the "Load book" button. Superimposed over all is the following dialogue:

 

You have two types of settings in this dialogue. The first is the search depth, with a default of "5". This controls how far ahead (in half-moves, or "plies") the engine will look before making a move. For example, if you leave this at "5", the engine will look 2.5 moves ahead before making a move. Remember, the engine is going to be playing a lot of games against itself and storing the moves in the form of a tree, so the search depth is important. You must realize, however, that there's something of a tradeoff here; the higher you set the search depth, the more time the engine will need to make each move - so you're trading time for depth. On the other hand, setting a lower search depth means that many more games will be played in a given amount of time, but that the moves themselves are likely to be more superficial.

Keep in mind, too, that you should use only odd numbers for the search depth, because chess engines tend to develop a tactical "blind spot" when made to analyze at even ply depths. Rule of thumb: odd numbers good, even numbers bad.

The second setting is the "width" of the tree. This is similar in some ways to the "Branching factor" in Deep Position Analysis and is another "space for time" tradeoff. If you create a "Narrow" tree, you won't see many alternative moves displayed in your game tree but the overall process of playing games and generating the tree will be faster. "Broad" trees show more alternatives but take longer to generate (it requires more processor time and thus slows down the chess engine).

Let's go for a "Medium" tree and a search depth of "7", click "OK" and see what happens next.

The software will load the engine and you'll get a dialogue to that effect. Then - nothing? Patience, please. For a minute or so it'll look like nothing's going on, but then you'll see the tree view (your former Notation pane) become populated with data:

This looks a lot like the game tree/opening book display with which you're already acquainted. This one acts a bit differently in the data it displays. You still have "N" for the number of games played (ten so far when I took this screen shot) and a numerical percentage of how well the move did from White's perspective; we're starting to see that Janowski's Exchange sac was probably unsound. "Prob" is the probability of a move being played; since 14...Rxb6 showed up in every game Rybka played against itself so far, the value here is "100%".

Note that you can actually play through the moves of the tree while it's still being generated, too. Use the cursor keys on your keyboard to navigate through the moves (left and right to move forward and backward, up and down to select a move when multiple moves are displayed).

The bar near the top of the display also provides useful information:

 

This display reminds us of the engine which is being used for the analysis and the search depth we set at the start of the process. We see how many games have been played so far (54 at the time I made the screen capture) and the results of those games. In this case, White won twenty-five of them while Black won just three; twenty-six of the games were drawn. The next value is the success rate, given from White's perspective (70.4%). "TP" is a "performance rating" value, again presented from White's viewpoint. The remaining values are the probabilities that the results will fall within the indicated ranges.

You can let Monte Carlo analysis run for as long as you like. Remember that the more games you let the engine play, the more reliable will be the statistical results.

Let's take a last look at the statistical Monte Carlo analysis for our game Didier-Janowski after White's 14.c3:

What we're seeing is that after 100 Rybka-generated games Janowski's Exchange sac was really the only move that makes sense (100% Prob value and no other moves showing in the tree). But it's not a great move: White scores 68% from the position after 14.Rxb6 (getting just over 2/3rds of the available points, with wins being a point and draws being a half-point, of course). In fact, Black won just seven out of 100 games played from this position.

What Rybka's Monte Carlo analysis is telling us is that 14.Rxb6 is a crappy move, but that Janowski was practically forced to play it since his alternatives were actually worse (so Janowski essentially painted himself into a corner somewhere along the way prior to this point). But the interesting thing is that Janowski went on to win this game; you can do a database search to find it and play out the rest of the moves if you like.

Back to Rybka: to stop the Monte Carlo analysis, click the "Stop" button (the little red button with the white "x" in the upper left corner of the Monte Carlo analysis screen). You'll see a popup dialogue asking if you wish to save the tree which the analysis generated. If you click "Yes", you'll get the standard Windows dialogue prompting you to pick a folder in which to store it and for you to give it a name. Note that all of the game moves prior to the point at which you started the analysis are also saved as part of the tree; in our example, all of the moves through 14.c3 will be saved along with the "Monte Carlo tree" which begins with Black's 14th move.

If you select "No", you'll simply be returned to the normal game window (chessboard with Notation pane), but you'll notice that any moves you replayed in the tree while the analysis was being generated will be displayed as variations/subvariations in the Notation pane's gamescore.

All of that seems prety verbose, but it's really very simple: Monte Carlo analysis causes Rybka to play a large number of games against itself and then store the results in the form of a statistical tree. That's really not hard to understand at all.

Rybka 4 In-Depth Report - Part Four

Rybka 4's Shared Analysis

OK, friends, strap yourself in for this one, because it's a pretty brilliant idea. In fact, it's one of those "obvious" brilliant ones, the kind where you smack yourself in the forehead and say, "Why didn't I think of that??"

Rybka has a new analysis mode called "Shared Analysis". Basically it involves a pair of "twin" chess engines analyzing simultaneously. This is nothing new; an old 1990's chess program used this technique to offer "instant" game analysis as soon as you finished a game against it. But Rybka's Shared Analysis feature offers an interesting twist on this old idea.

Before we proceed, we need to do a quick review on the subject of hash tables. When a chess engine looks ahead at the myriad possibilities which lie ahead, it stores the positions it's already evaluated (and their numerical assesments) in the hash tables. Then, if elsewhere in its search, it encounters the same position again (due to a different move order, known as a transposition) it won't waste time evaluating that position a second time - it just uses the stored evaluation from when it previously analyzed that position.

Shared Analysis is used when analyzing a single position. Start Infinite Analysis (ALT-F2) using one of the Rybka engines. Then right-click in the Engine Analysis pane to get a popup menu and select "Shared Analysis" from that menu. You'll see the analysis pane change to resemble the following:

The single Engine analysis pane then splits into two panes. Here's what's happened. The original chess engine (shown in the upper pane in the illustration above) gives up half of your computer's processor cycles. The software then starts a second "invocation" of the same chess engine which will then use that freed processing power; in other words, the software starts an identical copy of that same chess engine. Both of these engines then start analyzing the position, each using half of the computer processor's power.

"Big deal," I hear you saying. "They're just doing the same thing." Wellllll, not exactly. The first chess engine gets "locked" on the initial position it was analyzing when you started Shared Analysis. But the second chess engine (in the lower pane, noted as the "B" engine in the above illustration) is free to analyze different positions if you move the Notation pane cursor somewhere farther ahead in the game, but this second engine will also be storing its analyses in the same hash tables which it shares with the "A" engine.

 

OK, give up? Let's start Shared Analysis and then use the cursor keys or VCR buttons to jump the game ahead, say, three moves. The "A" engine will still be analyzing the initial position (the one on the board when we started the Shared Analysis function), but the "B" engine will be analyzing the position on the board three moves later and storing its evaluations in the hash tables it shares with Engine "A"; in theory, the "B" engine will always be three moves ahead of its "twin", therefore it'll always be storing positions in the hash tables for places the "A" engine hasn't reached yet. But when the "A" engine does get to these points, it'll find a whole lot of positions which have already been analyzed. This will allow the "A" engine to analyze a lot more positions very quickly and search even deeper than it could if the "A" engine was analyzing by itself. It's like a military team sending a reconaissance patrol ahead to report back on the terrain and enemy positions it encounters. When it's all said and done, Engine B is "feeding" extra analysis to Engine A:

You can see in the above illustration that the "A" engine is still analyzing the initial position (after Black's 15th move) and is also displaying the analysis in a bold font (to remind us that this is the main analysis). But we've jumped ahead three moves in the gamescore as we can see by looking at the "B" engine's Analysis pane; that Rybka engine is looking ahead from Black's 18th move). It's storing those positions in the same hash table files that the "A" engine is using, so when the "A" engine encounters these positions it won't have to analyze them - it'll already have access to these evaluations. To exit Shared Analysis mode, right-click on the "B" engine and select "Close" from the popup menu.

That's not just brilliant, that's crazy brilliant. But it's also one of those forehead-smacking genius ideas that's almost too obvious, now that someone's actually implemented it.

As a last tip regarding Shared Analysis, it's best used with a large-sized hash table (as big as you can get without causing excessive hard disk activity). Remember, you set the hash table size in the engine selection dialogue (reached by hitting F3 while in the main chessboard screen).

Make sure you check out Rybka 4 and Deep Rybka 4