ELECTRONIC T-NOTES


CHESSBASE USA'S WEEKLY ON-LINE NEWSLETTER


FOR THE WEEK OF JULY 15, 2001


NEW CHESSBASE PLAYING PROGRAMS

by Steve Lopez

As recently as seven years ago, speed was king -- at least as far as chess programs were concerned. Back in the days when a Pentium I 133 MHz machine was considered the great miracle of modern civilization many chess programmers still believed that rapid analysis of gobs of positions (that is, huge numbers of nodes per second to diehard chess computer freaks) was the key to a silicon player's achievement of chess mastery.

But a funny thing happened along the way between those days and now: chess programs hit a sort of wall. Every time you add another ply (half-move) to a program's search depth, you exponentially increase the number of positions the program must evaluate in order to complete that ply. For example, let's consider an imaginary chess position in which White has twenty legal moves. A program only has to evaluate those moves to figure out which one is "best". But let's say that Black has twenty possible replies to each of White's moves (just for the sake of the argument and to make the multiplication easier). To evaluate two full plies ahead, a chess program must now evaluate 400 positions. That's still child's play for a computer. If, on the third ply, White has twenty responses to each Black move, the number of positions jumps to 8000. Add another Black ply and you get 160,000. Slap on another White move and you get 3,200,000 positions. Another Black ply brings to total number of positions to 64,000,000. One more White ply (bringing us to seven plies) and you get smoke rolling out of your pocket calculator. By the time the ply count reaches the double-digit range, you're into the billions of positions -- literally billions of chess positions must be evaluated before another ply can be squeezed out of the evaluation.

But how much stronger does a program play when you add a single ply to the search depth? I've seen a lot of arguments on the topic and there's been no definitive answer. One thing, though, is clear -- it's a perfect example of the "law of diminishing returns". Yes, you can have a chess program take twenty-eight extra minutes to chew through that one additional ply to go from a depth of fifteen to sixteen but it's not going to significantly alter the strength of the program. In other words, it's really not worth the extra time -- ergo, speed isn't "king" anymore. Even though personal computer processors are very fast these days, they still can't handle the sheer avalanche of work that's required to analyze a chess position out to any great depth.

So if sheer speed and brute force aren't enough to strengthen a chess program from version to version, what will do the trick? Chess knowledge. Many of the older chess programs are known as "fast but dumb" analyzers. They can analyze a large number of individual positions and are strong chessplayers because of the sheer volume of what they can "see", but they don't really "understand" the positions in chess terms -- only in "number crunching, bean counting" terms. Most of the newer programs (relative to the older ones) fall into the "slow but smart" category. They don't analyze nearly as many positions as their older counterparts, but they "understand" more of what they see; in other words, more chess knowledge (beyond the traditional criteria of material and space) has been programmed into them. This actually makes them stronger and more positionally adept than older chess programs.

These are interesting times for chess programmers and computer chess fans, and what makes this so is the variety of approaches being devised for programming chess knowledge into present day engines. Each programmer tackles the problem in a slightly different manner, ergo each chess engine is different and unique.

We see some examples of this in the three new chess engines just released by ChessBase: Junior7, Deep Junior7, and Shredder 5.32. All three are strong chess engines, but their strength is derived from using different evaluation methods.

Amir Ban and Shay Bushinsky have been hard at work on Junior over the past eighteen months (admirable, since neither gent is a full-time chess programmer -- they both have jobs in the "real world"). They've taken Junior and added a lot of tweaks to its evaluation function. Consequently, what you'll actually see on your screen when you fire up Junior7 is much the same as what you saw with Junior6 -- the interface is the same (the standard Fritz6 interface, used by all programs in the "Fritz family" [with the exception of Hiarcs7.32]). The changes between Junior6 and Junior7 are all internal -- meaning that they're all within the engine itself.

The programmers' main area of concentration has been in the area of positional evaluation: why one side or the other is said to be "ahead" in a given position. In an interview in the printed booklet that accompanies the ChessBase Magazine 82 CD, Amir Ban reveals some of the criteria he and his partner examined in developing Junior7. One of these is compensation. In many chess games, one of the players will give up a pawn (or more!) in return for other factors: a space advantage, better piece placement, or to open lines for attack (in fact, this is the core basis of gambit play -- see ETN for June 3, 2001 for a discussion on the topic). These are often "fuzzy" criteria -- i.e. not easily quantified in concrete, much less mathematical, terms. Junior's programmers think that they've discovered new ways to quantify some of these criteria and have added the necessary algorithms to the Junior7 engine.

An offshoot of the "compensation" question is the area of sacrifice. Computer chess programs traditionally have been reluctant to sacrifice material. This was due to the "bean counter" algorithms of the old "fast but dumb" engines -- if a pawn was sacked, the computer saw this as a -1.00 evaluation and shied away from that variation. Present day programmers are becoming more and more adept at creating formulae that take positional sacrifices into account. Some are more apt to do this than others; the Chess Tiger engines are a good example of this. The Tigers tend to actually look for these opportunites -- in fact, Gambit Tiger seems to often sac a pawn just for the sheer everloving fun of it. The Tigers will do a good bit of speculative sacrifice. A human player would think of it this way: "Well, I'm not certain that it works but it looks promising, so I'll go for it". You've done this, I've done this -- we sometimes lose badly, but when we win we'll win spectacularly.

Junior7 isn't as speculative as the Tigers (certainly not as much as Gambit Tiger) but you will sometimes see pretty risky play from Junior. This sometimes leads to Junior's downfall (witness some of the games from the Cadaques tournament) but in other cases it leads to beautiful play and impressive wins, especially against other chess programs. Because many other members of the Fritz family of engines do tend to "play it safe", Junior provides a nice compliment to them -- particularly when you're looking at an unclear position and want to get a variety of opinions about it. This also can lead to many fun games when using Junior as a sparring partner when honing your own chess skills.

Back at the top of this article, I mentioned that speed is no longer the primary concern of chess programmers. However, speed is still important -- it's just not the main concern anymore. One of the ways to try to get around the "wall" effect when trying to deeply analyze chess positions is to use multiple processors. Two or more processors split the work between them, resulting in faster evaluations and deeper searches (compared to the same search on a single-processor machine). This is the entire point of Deep Junior7 -- it's Junior7 in a form designed to run on multi-processor machines.

As an important side note, I'm frequently asked, "How do I know if I have a multi-processor machine?" The short answer is that if you have to ask, you don't own one. You'll know you have one by the emptiness of your wallet after you've purchased a multi-processor computer -- they're considerably more expensive than a standard single-processor PC.

All of the previous comments concerning Junior7's positional knowledge also apply to Deep Junior7 -- the engines are internally the same, with the exception that Deep Junior7 has the ability to be used by multiple processors. So if you have a single-processor machine, there's no advantage to purchasing Deep Junior, unless you plan to purchase a multi-processor machine in the near future (or upgrade your existing box if the motherboard is set up for optional additional chips). If you have a single-processor machine and don't plan to add processors or buy an expensive new unit, you'll want to purchase Junior7 instead.

Another programmer, Stefan Meyer-Kahlen, has also been hard at work developing his own methods for improving his chess engine's strength without relying on sheer speed alone. The results have been overwhelming. Shredder has long been one of the strongest chess programs around, particularly in competition against other chess engines: it's been the world computer chess champion multiple times in recent years.

Obviously, I'm thrilled that Shredder has become part of the Fritz family of chessplaying programs. Nothing succeeds like success and Shredder has achieved that in truckloads. I've been curious about Shredder for a long time but have never tried it, mainly because of my own laziness: I'm not a huge fan of learning my way around an unfamiliar interface. Now that Shredder's part of the Fritz stable, I can run it in the familiar Fritz interface and concentrate on chess instead of on locating menu items.

What sets Shredder apart from the other chess programs we offer? The primary difference I've spotted is its style of play: Shredder plays excellent positional chess, even moreso than the former "positional" leader, Hiarcs7.32. I've mentioned the "computer-like" style of play in this and other articles -- computer programs tend to count material well ahead of other concerns. But Shredder is different -- it looks at criteria such as piece placement and pawn structure in its evaluations. This has a double-edged effect: Shredder not only plays surprisingly good pawn moves, but also has the ability to take advantage of its opponents' mistakes regarding pawn play. and defense. An excellent example of this can be found in the printed booklet accompanying ChessBase Magazine 82, in which Shredder's play in a position taken from Kharlov-Beshukov (Ekaterinburg 1997) is shown. Black slips up by making a Queenside pawn move, after which Shredder sacs a Bishop for two pawns and gets a screaming Kingside attack, recognizing in the process that Black's pieces are badly placed for the defense. In fact, there is no defense -- but it takes White over ten moves to force the win. This can't be calculated by brute force alone -- Shredder uses its positional knowledge to understand what to do after the Bishop is sacked.

This is truly impressive stuff. While no computer program is yet capable of Steinitzian positional play, Shredder goes a long way toward bringing this goal to fruition. It's a very solid-playing program, very tough in defense while also being a ferocious attacker when the opportunities arise. Shredder shows almost no weaknesses in its position -- you'll have to look long and hard to find points to attack, assuming any exist. It's hard work to force Shredder to create weaknesses in its own position (even in Friend mode); playing against it will make you stretch your abilities in this area.

Shredder is also quite adept at forcing weaknesses in your position. Even though its main strength is in positional play, Shredder can also be a fine tactician -- even sacrificing material when the position requires it (see the example from Rohde-Shipman in the booklet from CBM 82). In fact, positional analysis (recognizing promising positional motifs) is Shredder's strong suit compared to other chess engines; with its large amount of positional understanding, you can always count on Shredder to find excellent moves in the positions it analyzes.

The ultimate strength of Shredder is the subject of endless discussion on the computer chess message boards; it's arguable the strongest engine of the Fritz stable. Of course (as regular readers of this column know), I tend to stress features over strength when writing about chess programs. Shredder5.32 contains all of the standard features of the Fritz interface: Friend and Sparring modes, Explain All Moves, and the coach features. So don't be put off by the "strength" angle -- Shredder is also a fine program for the developing chessplayer who's looking to hone and refine his skills. Shredder's not just an outstanding analysis engine but is also an excellent sparring partner for the average player.

For owners of multiprocessor machines, there won't be a "Deep Shredder" -- there's no need for one. Shredder5.32 already has multiprocessor capabilities. The "threads" setting under "Engine options" allows you to set how many processors Shredder will use in its analysis. It will support from one to eight processors.

All of the programs mentioned in this article contain their own opening books as well as a 320,000 game database which you can use to seek out and play through great games of the past. All three of these programs also access engame tablebase files (such as the Fritz Turbo Endgame -- see ETN for July 2, 2000).

Ultimately, the differences in these programs is one of style. The Junior engines tend to play a riskier form of chess, taking chances in many positions and sometimes making speculative sacrifices. Shredder plays a "safer" game, more solid, tough in defense and fearsome on the attack. All are strong but approach their analyses differently -- and those differences are what makes having multiple engines for the Fritz interface so dang much fun (which, until we meet agian next week, is what I hope you'll be having).

You can e-mail me with your comments, suggestions, and analysis for Electronic T-Notes.