When I first started playing tournament chess a master was helping me develop my own opening repertoire. Unfortunately I was not that interested in openings. I think most U.S. players tend to put their time and study on learning to play endings and other things for some reason. Because of this he encouraged me to specialize in order to save time so that I could focus on other things.
In other words, he wanted me to pick just 1 move that I would play from any position in my repertoire. So I did not have to learn how to play 1. d4 saving me a huge amount of time. Of course sometimes things transposed to queen pawn openings but this still save an enormous amount of work. He warned me that I might want to learn alternatives when I became strong enough that people would actually bother to prepare against me.
So software could easily be designed to handle this, showing JUST the move (or moves) you want to play from any given position.
bbbaro25us wrote:I added another example, hopefully more explicative.hgm wrote:
I can't say I completely understand it. Are you talking about a specially prepared PGN file, where each 'main line' of a game is enormously dresseded up with variations, sub-variations, sub-sub-variations etc.? And if so, is the idea that each variation should then be complete to the end, even beyond the point where it runs into a transposition with a variation somewhere else in the file? Or would eah position only be continued in one unique place in the file, so that most lines would end pretty quickly in the tree that lists them, but the user should then use the search command to jump to another (unique) tree where that position is on the main line?
The latter is what the search-position command in WinBoard would do. You walk through one tree, reach the end of a variation that ends in a transposition, then press 'find position', get the game(s) listed in which thisposition occurred on the main line, (presumably only one), and then load that game to get to see the continuation (which can itself be a tree, etc.).
It would require a lot of designing to organize the PGN file so thatit works like this, though. It sounds that what you basically want is a smart viewer /tree-walker for a conventional opening book. Which constructs the PV from the book by following the moves with the largest weights, and optionally lists the sub-optimal moves as variations. The book would basically bethe index of positions you talk about, but there is no real need to store actual games. The games are implied by the book.
Anyway I'm not asking anything so complex, not something linking separate PGNs in a database or book: the index-reference I was saying should be simply an automatically generated comment line of the assembled pgn (or whatever format: I speak about a sequence of moves, with variations and subvairiations, like the "dressed pgn" you say, I suppose).
The aim is reading a printed copy. And the possibility to keep ading stuff and having the program organizing it in a coherent readible way.
You see: if I open a number of game files from a database merging them together (or if I add lines to a "dressed pgn" with variations and subvariations), I keep adding caos on caos, and I cannot use the results as a repertoire.
This problem is especially relevant because of the transpositions, and the actual impossibility to sort out the repeated positions when the repertoire grows big and complex enough for me to not be able to spot them anymore. The program should not have my human search and memory problems: so I think there should be a way to have it reorganize it all in a sensitive way, in a way that could result in a decent printed repertoire.
If, for example, I add a pgn game to a "dressed pgn" (the repertoire), when a transposition happens after a different number of moves, or after a different sequence of moves, it gets added without me knowing of it. Similarly, if I'm adding a line manually to the "dressed pgn" and by chance i pass over a position which is already represented in there I cannot really know it. Hence the "dressed pgn" keeps growing in size and caos even when I'm not adding new informations to it.
So When a "transposition position" occurs, it would be helpful if the program would use it as a milestone of sort, writing every move/line happening before that position first (no matter how many move long it is: I suppose the move after the transposition would be numbered with the lower possible value coherently to the shortest possible path to it), and writing all the continuations, from that position on, after the "transposition position".
As there may well be many such "transposition position" in a repertoire which is coherent and easy to memorize, each one of these positions shoud have an index of ANY sort, the simpler the better, which the program could add as a comment at the end of all the trunkated lines which converge at a "transposition position": just a way for the HUMAN user to navigate through the final result!
I hope this time I was understandable, and sorry for the English: not my language.


