With the advent of chess engines and many other computer programs or methods of analysis, correspondence chess has undergone a revolution.
The essence of the game has not changed for those who continue to practice it but the way it’s played has changed dramatically in the last few years.
I would like to invite you to a turbulent ride across the labyrinth of modern correspondence chess analysis guided by an expert in the field, my friend Kostas Oreopoulos. I met Kostas in the Aquarium Forum, his nickname there is buffos. Kostas is an extremely intelligent individual, you don’t need to meet him in person to reach this conclusion quite fast when interacting with him. He is always willing to answer questions and help aficionados like myself learn how to take advantage of the program Aquarium, the best analysis tool in correspondence chess. Kostas has gratiously agreed to an interview and will share his deep knowledge in the area of correspondence chess analysis. You may review a short bio he has kindly provided to us.
How to prepare for the opening.
What follows assumes you have a fair knowledge of how Aquarium works, since it would be very very long going into every detail.
Preparing for the opening is an evolving process. Once maintaining an opening repertoire and expanding it, was a very hard task. Even with databases it is very hard, since correspondence analysis is usually very very deep and detailed and keeping track is a huge task.
For this hard task I use exclusively Aquarium’s tree’s (both computer generated aka IDEA and infinite analysis trees and database generated trees).
Database trees of course are not new. They have been ‘here’ for more than 15 years (as far as I can remember in the first versions of Chess Assistant). They are certainly very helpful and a tool every corr player should use.
My use is rather standard. I have a database tree from my big database ( I use Opening Master database) , one from games only played in correspondence chess, one from centaurs and a database tree from my own correspondence games.
The big database tree is mostly used to guide me to what is played in the position (and to feed IDeA, more on this later). Win percentages are not so important from this database since they involve OTB (over the board) games but percentages from the other two database trees (only corr games and centaurs games) are an important guide and inspiration.
Of course I never use them blindly, since a single game can alter the assessment of an entire variation.
Last but not least , my own games database tree helps me “remember” if I ahve played that position before or not (and eliminates the need for constantly searching the database to see if I have played it or not).
All those trees (and more) , and the information they carry, are combined in the Aquarium configuration tree (pic to follow).
One big obstacle for now, is that very big databases like Opening Master cannot fit in a single tree. The limitation is because of Aquarium’s 32bit nature (and Chess Assistant legacy since who would expect trees bigger than 2GB 20 years ago).
The current work around I use is to split the trees into time periods.
For example, I do a database search for games until 1990 and then build a database tree out of it. Next I do the same for 1990-2000 , 2000-2003, 2003-2007… etc. (year ranges are examples and the only requirement is that the size of the resulting tree is under 2GB’s.)
The last tree is from 2011-now. Every time the opening master is updated, I do a search for that last period (2011-now), build the tree for that last period and replace the previous one. I do not have to rebuild the entire database.
Now the trick is to combine them, and view statistics for all those sub-trees as a whole. The work around Aquarium uses are treeheader.uni files. Those are simple text files. Here is a sample “mytree.uni”
As you see you just list the locations of the tree’s you want to view as a whole and then save that *.uni file (its just a text file).
Then when you treat that mytree.uni as a normal tree (like it was an mytree.hsh file) and load column content from it like you would normally do with *.hsh tree files.
As far as I know in the coming version of Aquarium, this might change and Aquarium will support very large trees, so you wouldn’t have to use that trick, although I would still split the database in (start of time – 2010) and (2010-now) in order to rebuild the tree for much fewer games , thus saving a lot of time.
A tree configuration showing data from multiple databases
This is the first and easy part of tools needed for opening preparation. The hard and most time consuming part of the opening preparation are computer generated trees (i.e. trees that have an evaluation attached to every position).
They are two kind of such trees. Minimaxed ones (like IDeA generated ones and CAP) and non-minimaxed ones (like those generated during infinite analysis) that simply hold “point- evaluations”.
Both are useful and we will see later how we can use both to steer the game into territories favorable to us.
The general idea is, that if the point evaluation (that is the evaluation provided by the engine) is very different from the minimaxed one, its obvious the engine gets the position wrong (so it would probably be good to steer the game into such positions where infinite analysis alone is not enough)
Minimax is a simple process. Lets say you can reach a position (with black to move) with 5 different black moves. Every one of those 5 different moves results in a different position, with a different evaluation. Which move is the best? The one with the **minimum** score (since computer score is from white’s perspective a -1.00 score is better for black than a -0.50 score). When we do this for a position with white to move (so we have N white moves to choose from), we choose the move that “maximizes” the score. This is why the process is called minimax. Every parent node gets a score, which is min or max depending on which side has the move.
The result is simple. Score is propagated to the parent nodes, and every position now hold a second evaluation , the minimaxed one.
Point evaluations (IA) versus minimaxed evaluations (IDeA)
As you can imagine , a single move addition can change the evaluation of many positions in the tree. For example if in a position, that you thought was equal you found a winning move, then this position, and every position leading to this one, should update the score to reflect that change.
The most important and time consuming part of the whole process is creating those trees.
I don’t know which is the most efficient way of working, but here is what i do.
First of all I have a big IDeA tree, which I use as a Msster tree. I export very often information from smaller IDeA tree’s to this one, and use it as my big reference. I never use it to work directly with IDeA. Just as a Master tree, to export to and import from other projects
My single most important advice is to take very frequent backups into various places of your Master tree. You don’t want to lose it.
A tree configuration with Master and CAP scores
The next tree I use is the CAP tree. This is a must have. There is tremendous amount of work in this one (it has over 55 million analyzed positions).
For every correspondence game that I play I use linked IDeA projects. What are linked IDeA projects? Imagine a game in a database, that is “linked” to an IDeA project. Why use linked projects and not normal ones? Because with linked projects I keep my analysis inside the database game, and after I delete the project, my analysis stays in the game. On the other hand, if you use a normal project, all the analysis you “write” in the notation pane is lost after the project is deleted.
Of course there is an extra benefit from linked projects. Namely combining infinite analysis and IDeA, but I’ll come back to that later.
(to be continued)