TascBase lesson: copy-trees
Mats Winther
This is a very efficient way of using TascBase which I´ve found out. The
advantage of this method is that you can continuously refine your
repertoire while investigating the variations for fun. There is no heavy
labor involved; instead the repertoire will be continuously refined from a
coarse-, to a narrow and exact repertoire. This is a top-down model of work
that is applicable to the huge mass of variations of modern theory. To set
about to create repertoire keys by using the bottom-up model - making one
refined key ofter the other - is an extremely tedious task - a
Sisyphos-work. Instead one should begin with a complete repertoire - but
coarse - and continuously work to refine it. This sounds self-evident, but
it is not so easy to implement using databases with no-, or inferior
opening book handling, like the other big databases on the market. With
TascBase you can immediately mark a coarse repertoire and work with the
extracted game material.
I have these three concepts: repertoire-trees, copy-trees and master-tree.
The copy-trees are copies of the repertoire-trees. The copy-trees are empty
of games. These trees are only used when importing games to the
repertoire-trees. Initially, one must set the repertoire markings in these
trees in a rather coarse way. Entire sub-trees are marked as repertoire
although some of its sub-trees in turn don´t really belong to the
repertoire. So this repertoire marking should not take so long. The reason
for not doing a narrow marking of the repertoire is that it is convenient
to have a heap of extra material to investigate when questioning ones
variations.
When importing games to the copy-tree, those games belonging to the coarse
repertoire will be extracted from the bulk of games. When the extraction is
done these games are copied from the copy-tree to the corresponding
repertoire-tree. The copy tree is then emptied.
(Note: the easiest way to empty a tree is to copy the tree structure
without games ( the same technique as when doing backup). This new empty
tree becomes the new copy-tree and the old copy-tree with its games is
deleted.)
But in the repertoire tree one should definitely not use this coarse
repertoire marking. Instead, whenever a branching occurs - while
investigating branches or inserting or expanding branches - you should mark
the branch of your choice with a repertoire-dot. This marking is all that
is needed to to tell you whether the subtree belongs to your repertoire.
This is merely a memory marking. Another day, perhaps, you will make
further investigations and insert repertoire-dots in the branchings further
down in the tree.
Eventually, your repertoire variations will become longer than the others
because of game expansion (Split Key), etcetera. Then you could run the
Sort Database command so that the long repertoire variations become primary
(overmost) variations.
Games from other branches that transposes to the repertoire tree will be
transported to the chosen variation sub-tree at Optimize Database. This is
because the repertoire variation has grown longer (than the other branches)
during studies (ramifications have occured). As the variation continuosly
grows longer it will capture new transpositions from peripheral branches
and the appurtenant games will be transported automatically (at Optimize
Database) to your chosen variations. So you don´t have to worry about
transpositions "from behind", so to speak. After the transponating games
have been transported they can be used for the creation of new keys by
expansion (Split Key). This means that you don´t have to bother about the
"Retro Moves" in TascBase. In the Fritz5-tree, for instance, there are no
transportation facility since the positions in the tree are not regarded as
keys. One cannot store games under them. That is why "Retro Moves" are in
some way a necessary evil there.
Now, the only thing you have to worry about are the transpositions *from*
the position you are working with. But TascBase shows these in all modes
(also in View Mode by Ctrl-T). TascBase shows all transpositions, no matter
whether they jump forwards or backwards in the tree. So, there is actually
the possibility that - when performing, for instance, your thirteenth move
- you will actually jump back somewhere in the tree to move eleven! This is
amazing, but it´s a fact! (although a rare occurence).
These transpositions are important. They should be marked by inserting a
´T´ in the second position after a move. Later when you happen to pass such
a move in View Mode (Graphical Tree display), you just have to hit Ctrl-T
to see the transposition(s) from the actual position. But in other modes
the transpositions are automatically displayed.
By working in this way you don´t need to exhaust yourself. New keys will be
created when you happen to investigate that particular opening. At the same
time repertoire-dots will be inserted here and there - a little at random.
This is a random way of work that suits persons that wants to work with
openings for fun, not out of necessity.
If you continuously receive new games you can save them until you have a
heap of games - then you do the above extraction procedure again.
Eventually, when you have a lot of singular repertoire-dots in your
repertoire base, you could copy the repertoire-tree to become a new
copy-tree (and thereby removing the old copy-tree). Now, thanks to your
singular repertoire markings, you are able to make a more accurate
repertoire marking of the copy tree. Now you must work from the leaf nodes
of your repertoire sub-trees and mark those branches entirely which belong
to the repertoire. In this way you work bottom-up in the tree. If you feel
that the in-between variations on the branch are not important - then you
don´t need to mark these branches - but normally you should mark the
head-branches too, so that novelties are captured.
(Note: if you have a repertoire marking and branches below it where there
are no markings, TascBase will - while importing with the Use Repertoire
option - consider these branches as exclude-branches. That is; games
belonging to these will not be imported. The only games that will be
imported are those that don´t belong to these branches and therefore belong
to the marked key. This is the reason why you now must work bottom-up so
that the repertoire markings are set all the way down to the leaf nodes of
your repertoire sub-trees. But also this labor could be done a little at a
time.)
The master-tree is generated from the complete bulk of games. You could
either choose this method or regard the FideChess Encyklopedia as the
master-tree. But it is not necessary to have this as a database tree. The
complete games could also be stored merely as a game file. But it is very
practical to have a huge tree to wander about in, out of curiosity.
This huge game file, together with the empty trees, are what you must back
up. The master game file seldom needs to be backed up (perhaps never, since
you could always retrieve the games again from a cheap CD). However, the
repertoire trees must be backed up all the time. This is done by copying
the empty tree. One should not have a separate tree for each opening. This
causes problems because of openings transposing into each other (well, of
course, if you play Orangutang etcetera, there is little risk of this).
Generally, I recommend as a maximum, four different repertoire-trees.
When importing huge amounts of games (e.g million-bases, etcetera) to the
copy-trees, one should have prepared the copy-tree so that it is thoroughly
ramified in every variation. It doesn´t really matter how horrible the
copy-tree looks as this is not what you will work with. The reason for this
ramification preparation is to spare oneself from the tedious and
time-consuming automatical key-split that occurs while importing games.
Before removing duplicates - do a Optimize Database. This speeds up the
process. I removed virtually all duplicates, using a radical method in a
1.2 million base, in three minutes!
(By the way, if you have a master-tree and by chance get this message
during import: "key 00000 is full", then this means that the root key
contains about two thousand zero-move games. They must be removed since
this crammed key cannot be split up (since the games contain no moves).
Mats Winther
Komputer Korner
The logic of starting from a huge number of games escapes me when creating
an opening book. Many lines are simply bad. The only bad lines you should
keep in your repertoire are those that you would miss the first time when
confronted with the position over the board. Of course correspondence play
is excepted here. But in OTB play, the best practice is in putting the
lines in yourself and that is why Fritz 5 is best because all you have to
do is make the move on the board. Your idea of repertoire refinement will
still involve looking at all the lines. And in Tascbase you don't get the
immediate help of the engine's PV while doing this. If you don't use the
engine or if you do and switch back and forth to mark the positions, then
how are you saving time here? In your method you have 3 tasks, one is
marking the value of a move Good, Bad, unclear etc... another task is
marking the branches with dots and the 3rd is marking the transpositions.
The last 2 tasks are not needed in the Fritz 5 opening book tree. And all
this copying of trees and so forth is also not needed in Fritz 5 either,
just one simple import of games is all that is needed Mats, you have gone
so far into the TascBase forest that you can't find your way out.
--
- -
Komputer Korner
The inkompetent komputer
If you see a 1 in my email address, take it out before replying.
Please do not email both me and the r.g.c.c. at the same time. I read all
the postings on r.g.c.c.
Mats Winther <mats.w...@swipnet.se> wrote in article
<01bd0594$11f353e0$LocalHost@melki-sedek>...
> This is a very efficient way of using TascBase which I“ve found out. The
> advantage of this method is that you can continuously refine your
> repertoire while investigating the variations for fun.
>
> I have these three concepts: repertoire-trees, copy-trees and
master-tree.
>
> The copy-trees are copies of the repertoire-trees. The copy-trees are
empty
> of games. These trees are only used when importing games to the
> repertoire-trees. Initially, one must set the repertoire markings in
these
> trees in a rather coarse way. Entire sub-trees are marked as repertoire
> although some of its sub-trees in turn don“t really belong to the
> repertoire. So this repertoire marking should not take so long. The
reason
> for not doing a narrow marking of the repertoire is that it is convenient
> to have a heap of extra material to investigate when questioning ones
> variations.
- you should mark
> the branch of your choice with a repertoire-dot. This marking is all that
> is needed to to tell you whether the subtree belongs to your repertoire.
> This is merely a memory marking. Another day, perhaps, you will make
> further investigations and insert repertoire-dots in the branchings
further
> down in the tree.
>
> Now, the only thing you have to worry about are the transpositions *from*
> the position you are working with. But TascBase shows these in all modes
> (also in View Mode by Ctrl-T). TascBase shows all transpositions, no
matter
> whether they jump forwards or backwards in the tree.
>
Komputer Korner
As usual, Mats has been smoking the TascBase pipe. It is true that TascBase
has the ability to restrict import of games to certain lines and Mats, I
was aware of this so don't tell me what I am or am not aware of. I am as
interested in chess and chess games as anyone, however there is one
important point that Mats is missing here. Before you import any games into
the Fritz 5 chesstree, you have the possibility to massage your database of
games that you import so that they are restricted to your opening lines.
Fritz 5 enables you to copy games and with CBLIGHT the free chess dB from
ChessBase you can put any in any new games and sort them in the CBLIGHT
clipboard. Then you can easily do some searches on ECO and get rid of the
ones you don't want. Or you can manually scan the games after sorting them
by ECO and manually delete the unwanted ones . This is easier than you
think because Shift- Arrow down lets you scroll through lots of games very
fast. Admittedly this is a more cumbersome procedure than the TascBase
feature of automatically dumping in games based on your marked repertoire
lines, but don't forget that after your games are in, you don't have to
worry about transpositions any more. They are automatically shown to you
whereas in Tascbase you have to either mark them or play the move while in
view database mode or else you have to go to the key database screen. After
your theory is built up, I have found that the paper back Chess Informator
which comes out 3 times a year is perfect for keeping it up to date. No
more hassles with importing files or games, just reading the Informator and
checking the Hiarcs or Fritz engine PV's on the screen and adding moves by
moving the piece on the board is sufficient. In TascBase this involves
another keyboard shortcut to get to the engine PV's to check out the
validity of the move and a keyboard shortcut to get back to the view
database screen. All this is unnecessary in Fritz 5. Don't forget that you
still have to decide which lines are good for you. In Tascbase you have to
do the above 2 operations to do that and then choose an evaluation symbol.
If you want to add a further move you have to press CTL-A, whereas in Fritz
5 you simply look at the engine PV's on the same screen and then play the
move on the board and then add the evaluation symbol. It is automatically
added to the opening book/chesstree. I guess Mats's way makes it seem like
it is easier to add your lines, but you still have to look at them and
decide which moves are good and bad. There is no magic bullet for studying
openings.
--
- -
Komputer Korner
The inkompetent komputer
If you see a 1 in my email address, take it out before replying.
Please do not email both me and the r.g.c.c. at the same time. I read all
the postings on r.g.c.c.
Mats Winther <mats.w...@swipnet.se> wrote in article
<01bd062c$ae261160$d24cf482@melki-sedek>...
> Firstly, I want to clarify what I said in the previous message. I said:
> "Fritz5 isn´t able to copy trees at all". This is not correct. What I
meant
> was: "Fritz5 isn´t able to copy sub-trees".
>
> I forgot to mention that the inferior tree of Fritz5 suffers from the
> contamination problem. Every lousy game imported to the tree will be
> expanded and so the tree becomes contaminated. And when this has happened
> you cannot remove that line -horrible! With TascBase you can choose
whether
> to expand directly when importing to the tree (definitely not
> recommendable) or whether to expand the games of your choice later, when
> investigating the variations. This avoids the contamination problem.
> TascBase is the only tree database that have this feature of avoiding
> contamination.
>
> The Fritz5-tree is highly suitable for developing the theory knowledge of
> the chess playing program. But the Fritz5 tree is not suitable for
opening
> investigation and work. It is inferior here.
>
> The point is that with the tree-copying in TascBase you can mark them
> differently with the repertoire marking. This is why I explained this
> copy-tree idea. Fritz5 doesn´t have this very important feature of
> importing only those games that belongs to your repertoire. But as usual
KK
> isn´t even aware of this feature in TascBase. KK has no interest in chess
> games at all. He thinks one can develop theory without the games of other
> chess players. Don´t believe him. This is not how to work professionally.
> One must always look at master games to understand the openings.
>
> Mats Winther
>
Komputer Korner
Calm down Mats, you will get a hernia. I answered this in another post, but
here is some more explanation. All your TascBase gyrations are ingenious,
but taken all together do you really think that you can convince us that
TascBase saves the user work and time in creating an opening repertoire and
updating it? Your latest post of having the computer analyze all the end
positions is exactly the same as a program analyzing a Bookup epd file, and
finally explains to me why you think you can avoid human input at each
branch of your opening repertoire. I for one won't trust a computer to
decide all my lines based on an end node calculation. You have to play out
each line right to the endgame to really see whether each position is
playable. As I said in the other post, there is no magic bullet. It is
you who are being dishonest in making it seem as if TascBase is God's
creation for opening book editors. IT IS NOT. Sure it is an amazing non
drag and drop database, but for opening study, it has it's limitations
which you refuse to acknowledge. What you are saying to everybody is that
Bookup is not needed and that Fritz 5 is worthless for opening study. Well,
sales go against you Mats.
Users have come to realize that any time a user has to develop special
procedures to work around limitations, that it just isn't worth it for the
most part. You have spent an awful amount of work learning all the limits
and uses of TascBase and developing workarounds for those limits. I
congratulate you for being the world's expert on that program, but please
don't underestimate our understanding of what a good opening book editor
should be.
- -
Komputer Korner
The inkompetent komputer
If you see a 1 in my email address, take it out before replying.
Please do not email both me and the r.g.c.c. at the same time. I read all
the postings on r.g.c.c.
Mats Winther <mats.w...@swipnet.se> wrote in article
<01bd0619$743ac6c0$d24cf482@melki-sedek>...
snipped>
> By the way - yes, I know, to you TascBase is a forest. You could never
> understand this sophisticated software. You never understood what I wrote
> about. Here I work several hours and make a valuable contribution to the
> group - and what do I get? Only the obligatory verbal fart by KK.
>
> Mats Winther
>
>
>
Har...@t-online.de
quoting a mail from mats.w...@swipnet.se
> Firstly, I want to clarify what I said in the previous message. I said:
> "Fritz5 isn't able to copy trees at all". This is not correct. What I meant
> was: "Fritz5 isn't able to copy sub-trees".
>
> I forgot to mention that the inferior tree of Fritz5 suffers from the
> contamination problem. Every lousy game imported to the tree will be
> expanded and so the tree becomes contaminated. And when this has happened
> you cannot remove that line -horrible!
Referring to Matthias this will be corrected in Fritz5.01
> The Fritz5-tree is highly suitable for developing the theory knowledge of
> the chess playing program. But the Fritz5 tree is not suitable for opening
> investigation and work. It is inferior here.
Why? Learning out of databases should do the job.
> Mats Winther
Harald Faber
Har...@t-online.de
quoting a mail from mats.w...@swipnet.se
> Har...@t-online.de skrev i inlaegg <66qmg6$32b$1...@news01.btx.dtag.de>...
> > > I forgot to mention that the inferior tree of Fritz5 suffers from the
> > > contamination problem. Every lousy game imported to the tree will be
> > > expanded and so the tree becomes contaminated. And when this has
> happened
> > > you cannot remove that line -horrible!
> >
> > Referring to Matthias this will be corrected in Fritz5.01
> > Harald Faber
> But will it be a Bookup solution so that only one position is removed - so
> that the variation is merely hidden and one still can transpose into it? If
> this will be the case, the retro moves must be updated and be set in the
> next position (after the one deleted). Or am I wrong? Or will one be able
> to remove the whole variation subtree? There will be a lot of retro moves
> to update(?)
> Mats Winther
Don't ask me, ask Matthias.
Harald Faber