13 Sep 2018 - 1.7 release

27 Dec 2015 - 1.6 release

21 Nov 2014 - 1.5 release

1 Nov 2012 - 1.4 release

21 Nov 2009 - 1.3 release

25 Feb 2009 - 1.2 release

28 Jan 2009 - 1.1 release

26 May 2008 - 1.0 release

Hoffman calculates chess tablebases, which are large files containing all possible configurations of chess pieces in an endgame and the best play to either win or draw. Unlike a conventional chess engine, which uses a heuristic evaluation function, a retrograde engine is almost completely non-heuristic. When it labels a position as a win, it is because it has considered all possibles lines, be they 10, 20, or 100 moves long, and determined that the win is forced, even with best play by the opposing side. Some chess-like games, such as the Japanese game Shogi, are not suitable for retrograde analysis because pieces never leave the game (captured pieces in Shogi can be put back into play by the capturing player). Yet for chess, the frequent reduction of games to positions where only a handful of pieces remain has created an entire subfield of endgame analysis.

Systematic analysis of chess endgames dates at least to the ninth century. Pioneering work in computer retrograde analysis was done in the 1980s by Ken Thompson, of UNIX fame, and S.J. Edwards, but the most popular tablebases today are those generated by a program written by E.V. Nalimov. Suffice it to say that while Nalimov's program has completely solved all chess endgames with six or fewer pieces remaining, and while Nalimov tablebases are widely available on the Internet, the Nalimov approach of solving an endgame completely results in very slow run times and exceptionally large tablebases. The K+P+P vs K+P endgame, for example, due to the possibility of all pawns queening, requires the K+Q+Q vs K+Q endgame to be solved before it can be calculated. The Nalimov kppkp tablebase occupies 64MB; Hoffman's current, less efficient storage scheme requires 225MB for the same tablebase.

Hoffman takes a somewhat different approach, one pioneered by Eiko Bleicher's Freezer, now a commercial program. When faced with something like K+P+P vs K+P, rather than calculate all possible resulting positions, it may ignore the possibility of more than two pawns queening at the same time, thus computing nothing more complex than K+Q+P vs K+Q. While incomplete, such a tablebase is nevertheless useful. For the player with two pawns, if the tablebase finds a winning line subject to the queening restrictions, then that line is still playable for a win, even though a faster winning line may exist. From the opposing point of view, if the tablebase treats any position where the third pawn queens as a loss, then the player can be confident that any drawing line can not be improved upon by the superior side. From a computational perspective, we have reduced the complexity requirements to a point where the calculation can be performed in a reasonable amount of time. While still too slow for over-the-board use, we now have a useful tool for the analysis of more complex endgames, useful for either static analysis, or for the slow time controls of correspondence games.

Hoffman improves upon Freezer with a more sophisticated method of chaining one endgame analysis into another, allowing more realistic modeling of queening combinations and exchanges. For example, in a bishop vs knight endgame (with pawns), we can (if we wish) analyze first the king and pawn endgame resulting after a trade of the minors, then use this information to analyze a similar set of king vs knight and king vs bishop endgames, and finally combine all this information together to analyze the original endgame. While the current version of Freezer can only regard the capture of the knight or bishop as a forced win for one side or the other, Hoffman can look through the exchange to determine the result more accurately.

Hoffman thus attempts to combine the best of Nalimov and Freezer. Unlike Freezer, the program is powerful enough to solve any endgame completely (given enough computing resources), reproducing any Nalimov tablebase. Unlike Nalimov, the program is capable of pruning pawn moves, queening combinations, movement options and exchanges, giving it Freezer's ability to solve complex endgames in a reasonable amount of time. The exact tradeoff between the two extremes is made using a XML-based configuration that can seem daunting at first, but ultimately offers the user the ability to extensively tailor the program's operation. Combined with a human being's common sense and chess judgement, it is my hope that this flexibility with ultimately make the program more useful for endgame retrograde analysis than either Nalimov or Freezer.

For those not up on Americana, the program is named after Trevor Hoffman, an All Star baseball pitcher who specializes in "closing" games. It was written specifically for The World vs. Arno Nickel game (ultimately won by the World team with no help needed from Hoffman).

Software development is hosted at https://github.com/BrentBaccala/hoffman

Hoffman 1.7 Release

hoffman-1.7.tgz (source)
hoffman-1.7.exe (installer for Windows executable)

The Hoffman Tutorial
The Hoffman Reference Guide

Hoffman 1.6 Release

hoffman-1.6.tgz (source)

The Hoffman Tutorial
The Hoffman Reference Guide

Hoffman 1.5 Release

hoffman-1.5.tgz (source)

The Hoffman Tutorial
The Hoffman Reference Guide

Hoffman 1.4 Release

hoffman-1.4.tgz (source)

The Hoffman Tutorial
The Hoffman Reference Guide

Hoffman 1.3 Release

hoffman-1.3.tgz (source)
hoffman-1.3.exe (installer for Windows executable)

The Hoffman Tutorial
The Hoffman Reference Guide

Hoffman 1.2 Release

hoffman-1.2.tgz (source)
hoffman-1.2.exe (installer for Windows executable)

Hoffman 1.1 Release

hoffman-1.1.tgz (source)
hoffman-1.1.exe (installer for Windows executable)

Hoffman 1.0 Release

hoffman-1.0.tgz (source)
hoffman-1.0.exe (installer for Windows executable)