Re: [Scid-users] Repertoire editor

[pgeorges <pas...@fr...>]

Hi, thank you for sharing your ideas about repertoires (a very important 
matter !). Here are mines below, but I must admit I don't know much 
about the "repertoire editor" functionality because I've always been 
reluctant to use it .

Denis J Navas a écrit :
> I can't avoid to gave some opinion about the repertoire editor.  I 
> used it extensively about two years ago.  I include a pretty small 
> example when I was thinking on a repertoire as black.
>
> The repertoire implementation have, in my opinion, some drawbacks.  
> These are what I remember:
>
> 1)  It can take transpositions into account.  It is a structural 
> deficiency, because the repertoire does not register epd.
We don't need to register epd for this : Scid has a nice function 
[sc_pos hash] to determine if 2 positions are the same (of cource this 
means going through the different lines for the check).
> 2)  I added evaluations at the end of every variation, but the 
> repertoire editor can't backsolve those evaluations to the root 
> position.  I did it manually.  [Perhaps, could be implemented with an 
> aditional field to hold the evaluation, be it numerical (pawns) or 
> with symbols].
The question is (suppose Mx is a move) :
1. M1  M2 ->
    var1 = 2. M3 - M4  3. M5 ....- M60 +-
    var2 = ......
Does this means that M3 deserves a "! " just because far later this 
particular line is favorable to white ?
This has always puzzled me : when reading opening books, you encounter 
this situation and there is no evidence that the first move in the 
variation (M3) is really the very best one that deserves a "!"
> 3)  I can't transfer a game up to some depth to the repertoire editor 
> with the game reference (white--black, site, event, year, result and 
> length), in an automated fashion.  This is a desirable capacity.
Seems to be easy to do with PGN, I think.
> 4)  I can't export the repertoire editor's variation as a game with 
> variations or as a game per variation.  This is a serious drawback.
This is what prevents me from using the repertoire editor : once you put 
your precious data in it, you're stuck with it. With Chessbase and 
Chesspositiontrainer, you always have the ability to export to PGN all 
your data at once.
> 5)  I can't import a set of games up to a predefined depth, adding the 
> game reference at the end of the line.
Seems to be easy to do with PGN, again. Few work to implement this in 
Scid, in PGN or an "ordinary" game database.
> 6)  I can't browse the repertoire lines, as anyone can do with the pgn 
> window or with the main Scid interface.
>
> But, due to its simplicity, have some benefits.
>
> 1)  The most important is to search in a new set of games, those that 
> have the lines that constitute your repertoire.  Therefore, it is 
> unnecesary to keep your repertoire games in a diferent database.  The 
> original concept call to hold those games as variants inside the 
> '.sor' file.
This should be easily implemented with "ordinary" game databases. This 
would mean flag a DB as a repertoire DB, go through it, keep of list of 
position hashes and see if you get the same positions in another DB. I 
don't understand why this feature is present in "repertoire editor" and 
not through databases.
Note : I don't want to mean that "repertoire editor" is useless, but I 
don't understand why some of its features have been put here and not in 
ordinary DB management.
> 2)  The repertoire editor, is pure text.  Therefore, is easy to add 
> your own thoughts or ideas about your own repertoire.  Even, you can 
> use the text inside the '.sor' file, as a source for a more complex 
> essay.
PGN is also pure text. In PGN you can even add markers : can you in a 
.sor file ?
> 3)  Its plain presentation of variations, makes easy to administer 
> what lines to add and what lines to supress.  This is a little bit 
> harder with a pure game representation.  But, could be better if long 
> lines could 'wrap' inside the variations window.
Maybe if a PGN file indents correctly its variations, we could 
administer the lines so easily.
> A really good improvement, as an option, could be to show variations 
> in tabular format or ECO format, have facilities to export to a game 
> with variations a whole or a part of the repertoire, have a way to 
> include game fragments inside the repertoire from the tree explorer 
> window, with a reference to the highest rated game, and a cursor 
> follow the moves and variations, as these were variations on a game.  
> These improvements, could increase the benefit of the repertoire editor.
>
> Another posibility, is to follow Pascal Georges idea of having a 
> separate database of repertoire games.  Something I consider 
> expensive, because you will end having several databases:  The source 
> games, commented games and repertoire games, without a clear conection 
> between them and without explanatory text.  If an idea like this could 
> be implemented, I think it should be as an index to the games in the 
> main database.  That way, you can analyze and comment a game, and if 
> you like it, add a flag to incorporate it in the index of repertoire 
> games.  Even though, from that idea follows the need to explore the 
> main database following the index of repertoire games only and have a 
> tree of only repertoire games.
>
> But I must insist, that this isn't a real repertoire, because you 
> can't evaluate the end positions and with that information and 
> backsolving the evaluations up to the root of the tree using mini-max, 
> you can't easyly squeeze knowledge from that game collection.  Also, 
> this kind of implementation lacks also the capability to track 
> transpositions.
>
> As a comparison, a new option has been developed to manage repertoires 
> for windows:  Chess Position Trainer.  It hasn't been ported to Linux 
> or Unix yet.  It uses the window's '.net' framework.  But the actual 
> version, has built its storage around XML, an this implementation is a 
> good example of up to what extent an idea as the repertoire editor 
> could be extended. But I must warn, that this approach isn't efficient 
> as a database when you reach 40,000 positions.
>
> Since this piece of software is really complex and has demanded a lot 
> of work from his authors, I think that the best approach, instead of 
> developing a more complex repertoire editor, is how to read and browse 
> CPT files, or even better, how to use the tree as the basis for a 
> repertoire, but with the advantage of adding text comments.
Chesspositiontrainer is clearly a good software. It will not be ported 
to Linux because it seems that Mono API will not suffice.
Concerning the compatibility between CPT XML files and Scid : I think 
the exchange format must be PGN, because :
- CPT can now export in PGN;
- its current format XML will change with the arrival of CPT 4.0 (I 
think it will use a database instead of flat XML files).

But it would be really great to add to Scid some or all of CPT features. 
The first idea I got is to open a repertoire DB in Scid, let the user 
play and trigger some popups when he does not follow its own repertoire, 
either because the move does not exist or because it has a "?" mark. 
That's why I have some questions on backsolving (see upper : if a line 
has at its end a +/- or -/+, does it mean that the first move of the 
line is neccesarily a blunder ?).
>
>
> As a side line, if Pascal Georges have interest, I can email him, more 
> elaborated repertoires on:  A60 Benoni, B12 Caro-Kann advance 
> variation, B45 Sicilian Taimanov and C65 Cordell's defense.

Thanks for the proposal, please send them to me {but those are not all 
my favorite lines ;-) }
If anybody has a good repertoire for black : French defense, King's 
indian and for white with 1.d4, I would appreciate much :-)

Pascal Georges