Answers.Body: <p>Unfortunately, many of the statistical functions of the Opening Book feature in ChessBase have been unreliable in every version I've owned. </p>
  
  <p>For example, after the Caro-Kann line 1. e4 c6 2. d4 d5 3. e5 Bf5 4. Nf3 e6 5. Be2 Nd7 6. O-O h6 7. Nbd2 Ne7 8. Nb3 Qc7 9. Bd2, the opening book PowerBook 2013 shows this table:</p>
  
  <pre><code>Move       N     %    Av  Perf
            15  76.7  2409  2283
  </code></pre>
  
  <hr>
  
  <pre><code>9...Bh7    8  56.3  2433  2494
  9...g5     6  83.3  2405  2233
  9...Nc8    4  62.5  2393  2335
  9...a5     2  50.0  2561  2564
  9...Be4    1 100.0  2414  2315
  </code></pre>
  
  <p>Well, first off, you'll notice that the number of games in the total (15) has no relation to the number of games in each variation given (a total of 21).</p>
  
  <p>Second, if you do some simple arithmetic, you can work out that the average White win percentage is actually 66.7%, not 76.7%, as reported.</p>
  
  <p>Well, then, let's ignore the overall position total statistics, and move on to examining a line item. Let's look at the 9...Bh7 line, which this table says was derived from 8 games, with a White winning percentage of 56.3%</p>
  
  <p>If you make that move, you get a new table. Since we're now at the new position, the position statistics at the top of the new table should read the same as those from the 9...Bh7 detail line of the parent table from the prior position, right?</p>
  
  <p>Here's what they <em>actually</em> say:</p>
  
  <pre><code>Move       N     %    Av  Perf
             8  56.3  2545  2484
  </code></pre>
  
  <hr>
  
  <p>Not bad, right? The first two stats agree... but the Average ELO and Performance ELO numbers are off by 100 ELO in the 1st stat, and 10 ELO in the 2nd.</p>
  
  <p>And here's the full table for the new position</p>
  
  <pre><code>Move       N     %    Av  Perf
             8  56.3  2545  2484
  </code></pre>
  
  <hr>
  
  <pre><code>10.a4      4  75.0  2455  2513
  10.Bb4     4  62.5  2557  2537
  10.Rc1     2  50.0  2650  2591
  </code></pre>
  
  <p>Again, the total # of games is unrelated to the # of games in each of the continuations.  And this time, the White winning percentage works out to 65%, not 56.3%.  And the position's Performance ELO is clearly not the average of the continuations' Performance ELO. It should be 2538, an error of 50 ELO.</p>
  
  <p>I picked a ready example from a game I was looking at a few minutes ago, but any game will do to demonstrate this problem.  I frequently find that when I try to choose a move from an apparently winning continuation that the the detail data from the resulting position just doesn't support the apparently "winning" statistic. In some cases, it could say White has as much as a 60% winning percentage for the continuation, and then in the next position none of the further continuations has a percentage higher than 50%. Simply put, it's nonsensical.</p>
  
  <p>Now, here's where it gets interesting: 
  I have set my Reference Database as the database of games that was supplied with PowerBook 2013 (PowerGames 2013). PowerBook 2013 was generated by ChessBase using <strong>all</strong> of the games from PowerGames 2013, and <strong>only</strong> those games. </p>
  
  <p>I can now open the Reference window pane, and it will look up the statistics from the games in that database. They should be identical to the stats shown in the Opening Book pane, but they're not.</p>
  
  <p>In fact, the Reference statistics for the 2nd position (after 9...Bh7) show the following:</p>
  
  <pre><code>10.Bb4     4  62.5  
  10.a4      2  50.0  
  10.Rc1     2  50.0 
  </code></pre>
  
  <p><em>This</em> is where the total statistics in PowerBook 2013 are coming from! The total number of games = 8 (correct), and the average performance = 56.25% (correct)!  </p>
  
  <p>In fact, in the PowerBook 2013 continuation stats there appear to be 2 extra games where 10.a4 was played (and which White apparently won), but they don't appear in the Reference database stats at all, and they aren't factored into the PowerBook 2013 totals stats.</p>
  
  <p>It doesn't really matter whether this is a problem inherent in the commercially-sold books from ChessBase, or in how the ChessBase database software uses/calculates/displays the statistics. Simply put, there's a defect here that's been present since at least ChessBase 6.0, and hasn't been fixed at late as Version 11 (the one I'm using).  Just watch out for it when you try to use an opening book to pick a line based on its purported winning percentage.  The best approach is to use the Reference Pane, or at least double-check the continuations for a couple of further moves.</p>
  
  <p>Personally, I now use the Reference window pane for this purpose, and put up with the slight lag required to update the stats for every new position in the game.  I use an AMD Quad processor at 2.9 GHz, so if you have something less powerful, you might feel the pinch a little more.</p>
  
  <p>I'm not excessively critical of the ChessBase software in general; I use many of the features quite effectively. But a few of them have known faults you should know how to work around. </p>
  
  <p>Another example: Try using a position search in a database; ignore the results. Then, <em>edit</em> the position within the search filter (add, move, delete pieces, whatever), make a note of the new position you're now searching for, and run the search again. Save the resulting list of games.  Now, reset the search filter completely (I suggest closing and reopening the database as well). Finally, set up the (altered) search position again from scratch, and run the search a 3rd time. The results from the 2nd (edited position) and 3rd (fresh position) searches should match. They frequently <strong>do not</strong>.  I've noted many cases where the fresh search filter returned many more games than the edited search filter.  I have no explanation for this, but I no longer edit the position in the search filter.  I always create a fresh position (usually by copying and pasting from a game window I set up for the purpose).</p>
  
  <p>Hope this is helpful!</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-05T01:57:33.303Z
Answers.Text: The Opening Book deals with positions, not variations, which can be confusing in the case of transpositions. In your Caro-Kann example, the position after 9.Bd2 occurred 15 times, out of which White scored 11.5/15 = 76.7%. The position after 9.Bd2 Bh7 occurred 8 times, but not all of these came from the position after 9.Bd2; some were transpositions. 21 games in total reached one of the five positions that occur when Black responds to 9.Bd2.
Answers.UserDisplayName: dfan
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-11-05T05:39:05.757Z
Answers.Text: @danf Your explanation makes sense, but there isn't much point to knowing what the stats are for the position after 9 Bd7 if all of the moves from that position lead to a completely different set of statistics. In effect, it's a case of reverse-you-can't-get-there-from-here, in which you can't avoid going places that you didn't intend.  I think it would be more intuitive and helpful to show the _averages_ of the ELO and Win Rate for the _continuations_, instead of the stats for the _position_ from which the continuations ensue, which are superseded by those of the transpositions anyway.
Answers.UserDisplayName: jaxter
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-14T01:55:59.443Z
Answers.LastActivityDate: 2016-09-14T01:55:59.443Z
Answers.UserDisplayName: jaxter
Answers.Body: <p>We do not know the exact format for Chessbase books, and it is entirely possible that what I'm about to say is not true in this case.</p>
  
  <p>The open standard book formats that I know of (Crafty, Pro Deo, Polyglot) represent chess positions as a 64-bit Zobrist hash. You can google how one of these works if you want to, it's beyond the scope of this answer. This is likely the same for Chessbase books.</p>
  
  <p>These hashes are designed so that the key for 1. e4 c5 2. Nf3 is <em>identical</em> to the key for 1.Nf3 c5 2. e4. This is useful for covering transpositions like this one. However, it means that it cannot distinguish between lines, resulting in there being no way of removing these transpositions.</p>
  
  <p>TL;DR I suspect this is impossible because of technical restrictions in the Chessbase book format.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-08-26T16:15:33.923Z
Answers.LastActivityDate: 2016-08-26T16:15:33.923Z
Answers.UserDisplayName: ZirconiumX
Answers.Body: <p>You can get this information from the Reference tab, rather than the Openings Book tab. (Of course the stats will correspond exactly only if your openings book was made from your reference database.)</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-01-02T15:32:37.543Z
Answers.LastActivityDate: 2015-01-02T15:32:37.543Z
Answers.UserDisplayName: dfan
Answers.Body: <p>You can also create an opening key for the games, and arrange it the way you like.  If you highlight a node in the key, and press 'S', you can see the statistics.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-09-26T16:20:14.723Z
Answers.Text: unfortunately, we're researching lines where _each_ move has branches. Creating such a key would have to be automatic. The Reference function already does this on the fly; the difference is that the key is static/permanent, but the Reference report is dynamic/temporary. So, you can use the nodes of the key more than once, and pay the setup cost once. Using any position more than once in Reference requires _repeating_ all the calculations each time. I don't know of an automated way to create such keys, but the Opening Book feature does the equivalent. But its stats are wrong...
Answers.UserDisplayName: jaxter
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-29T21:29:57.873Z
Answers.LastActivityDate: 2015-09-29T21:29:57.873Z
Answers.UserDisplayName: A passerby
Answers.Body: <p>One solution that I have developed for this issue is that you can go to the first node. Now you take the game list and separate it. Then you use a tree on this to go to the second node. Etc. In the end you will end up with a list of games with the exact move order you are interested in.</p>
  
  <p>I know it is cumbersome and that an automatic solution would be great, (like a switch you could flip in the tree to have it either way) but just thought I would throw this out there as a possibility if it's only a few lines you need exact move orders for.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-30T22:38:48.910Z
Answers.LastActivityDate: 2015-09-30T22:38:48.910Z
Answers.UserDisplayName: hpcp
Body: <p>In an opening tree (also called "opening explorer" or "openings book") on ChessBase 12, here are the statistics that we get after 1. Nf3 c5 :</p>
  
  <p><img src="https://i.sstatic.net/2OH1h.png" alt=""></p>
  
  <p>So it seems that after 1. Nf3 c5 White will play 2. e4 93% of the time.<br>
  It is obvious that these statistics are nonsense.<br>
  Everyone knows that after 1. Nf3 c5 White will play 2. c4 50% of the time, 2. g3 30% of the time, and 2. e4 only 10% of the time.<br>
  White players who play 1. Nf3 are generally not very interested to get into an Open Sicilian...<br>
  "2. e4 464238" does not mean "in this position White has played the move 2. e4 464238 times", it just means "the position reached after the move 2. e4 has been reached 464238 times by different move orders".<br>
  How can we resolve this problem?<br>
  It should not be physically impossible, since most other opening trees do not have this issue (<a href="http://chessok.com/?page_id=352" rel="noreferrer">ChessOK's opening tree</a>, <a href="http://www.365chess.com/opening.php" rel="noreferrer">365Chess' opening explorer</a> and <a href="http://www.ficsgames.org/openings.html" rel="noreferrer">FICS' opening explorer</a> do not have this problem).</p>
  
  <p>When we do a right click, and then click on "Properties", this window pops up:</p>
  
  <p><img src="https://i.sstatic.net/5QiNg.png" alt=""></p>
  
  <p>But unfortunately checking or unchecking the box "Unplayed transpositions" does not seem to do anything.</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-01-02T15:34:18.527Z
Comments.Text: Unchecking "Unplayed transpostions" will only prevent the Openings Book tab from displaying moves that were never made in its database but still lead to a position in its database via transposition.
Comments.UserDisplayName: dfan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-05T09:39:30.593Z
Comments.Text: Chess.com also does this, Scid does it the way you feel is correct.
Comments.UserDisplayName: RemcoGerlich
Tags: <opening><software><statistics><database><chessbase>
Title: In an opening tree on ChessBase, how can we fix the statistics so that transpositions are not taken into account in the total number of games?
ThreadText: # In an opening tree on ChessBase, how can we fix the statistics so that transpositions are not taken into account in the total number of games?
  
  (Asked by: username_0 on 2015-01-01)
  
  In an opening tree (also called "opening explorer" or "openings book") on ChessBase 12, here are the statistics that we get after 1. Nf3 c5 :
  
  ![](https://i.sstatic.net/2OH1h.png)
  
  So it seems that after 1. Nf3 c5 White will play 2. e4 93% of the time.  
  It is obvious that these statistics are nonsense.  
  Everyone knows that after 1. Nf3 c5 White will play 2. c4 50% of the time, 2. g3 30% of the time, and 2. e4 only 10% of the time.  
  White players who play 1. Nf3 are generally not very interested to get into an Open Sicilian...  
  "2. e4 464238" does not mean "in this position White has played the move 2. e4 464238 times", it just means "the position reached after the move 2. e4 has been reached 464238 times by different move orders".  
  How can we resolve this problem?  
  It should not be physically impossible, since most other opening trees do not have this issue ([ChessOK's opening tree](http://chessok.com/?page_id=352), [365Chess' opening explorer](http://www.365chess.com/opening.php) and [FICS' opening explorer](http://www.ficsgames.org/openings.html) do not have this problem).
  
  When we do a right click, and then click on "Properties", this window pops up:
  
  ![](https://i.sstatic.net/5QiNg.png)
  
  But unfortunately checking or unchecking the box "Unplayed transpositions" does not seem to do anything.
  
  **Tags:** opening, software, statistics, database, chessbase
  
  > **Comments:**
  > **username_1**: Unchecking "Unplayed transpostions" will only prevent the Openings Book tab from displaying moves that were never made in its database but still lead to a position in its database via transposition.  
  > **username_2**: Chess.com also does this, Scid does it the way you feel is correct.  
  
  ---
  
  ## 5 answers
  
  ### Answer by username_3 on 2016-09-14. Score: 2
  
  Unfortunately, many of the statistical functions of the Opening Book feature in ChessBase have been unreliable in every version I've owned. 
  For example, after the Caro-Kann line 1. e4 c6 2. d4 d5 3. e5 Bf5 4. Nf3 e6 5. Be2 Nd7 6. O-O h6 7. Nbd2 Ne7 8. Nb3 Qc7 9. Bd2, the opening book PowerBook 2013 shows this table:
  Move       N     %    Av  Perf
            15  76.7  2409  2283
  
  
  9...Bh7    8  56.3  2433  2494
  9...g5     6  83.3  2405  2233
  9...Nc8    4  62.5  2393  2335
  9...a5     2  50.0  2561  2564
  9...Be4    1 100.0  2414  2315
  
  Well, first off, you'll notice that the number of games in the total (15) has no relation to the number of games in each variation given (a total of 21).
  Second, if you do some simple arithmetic, you can work out that the average White win percentage is actually 66.7%, not 76.7%, as reported.
  Well, then, let's ignore the overall position total statistics, and move on to examining a line item. Let's look at the 9...Bh7 line, which this table says was derived from 8 games, with a White winning percentage of 56.3%
  If you make that move, you get a new table. Since we're now at the new position, the position statistics at the top of the new table should read the same as those from the 9...Bh7 detail line of the parent table from the prior position, right?
  Here's what they actually say:
  Move       N     %    Av  Perf
             8  56.3  2545  2484
  
  
  Not bad, right? The first two stats agree... but the Average ELO and Performance ELO numbers are off by 100 ELO in the 1st stat, and 10 ELO in the 2nd.
  And here's the full table for the new position
  Move       N     %    Av  Perf
             8  56.3  2545  2484
  
  
  10.a4      4  75.0  2455  2513
  10.Bb4     4  62.5  2557  2537
  10.Rc1     2  50.0  2650  2591
  
  Again, the total # of games is unrelated to the # of games in each of the continuations.  And this time, the White winning percentage works out to 65%, not 56.3%.  And the position's Performance ELO is clearly not the average of the continuations' Performance ELO. It should be 2538, an error of 50 ELO.
  I picked a ready example from a game I was looking at a few minutes ago, but any game will do to demonstrate this problem.  I frequently find that when I try to choose a move from an apparently winning continuation that the the detail data from the resulting position just doesn't support the apparently "winning" statistic. In some cases, it could say White has as much as a 60% winning percentage for the continuation, and then in the next position none of the further continuations has a percentage higher than 50%. Simply put, it's nonsensical.
  Now, here's where it gets interesting: 
  I have set my Reference Database as the database of games that was supplied with PowerBook 2013 (PowerGames 2013). PowerBook 2013 was generated by ChessBase using all of the games from PowerGames 2013, and only those games. 
  I can now open the Reference window pane, and it will look up the statistics from the games in that database. They should be identical to the stats shown in the Opening Book pane, but they're not.
  In fact, the Reference statistics for the 2nd position (after 9...Bh7) show the following:
  10.Bb4     4  62.5  
  10.a4      2  50.0  
  10.Rc1     2  50.0 
  
  This is where the total statistics in PowerBook 2013 are coming from! The total number of games = 8 (correct), and the average performance = 56.25% (correct)!  
  In fact, in the PowerBook 2013 continuation stats there appear to be 2 extra games where 10.a4 was played (and which White apparently won), but they don't appear in the Reference database stats at all, and they aren't factored into the PowerBook 2013 totals stats.
  It doesn't really matter whether this is a problem inherent in the commercially-sold books from ChessBase, or in how the ChessBase database software uses/calculates/displays the statistics. Simply put, there's a defect here that's been present since at least ChessBase 6.0, and hasn't been fixed at late as Version 11 (the one I'm using).  Just watch out for it when you try to use an opening book to pick a line based on its purported winning percentage.  The best approach is to use the Reference Pane, or at least double-check the continuations for a couple of further moves.
  Personally, I now use the Reference window pane for this purpose, and put up with the slight lag required to update the stats for every new position in the game.  I use an AMD Quad processor at 2.9 GHz, so if you have something less powerful, you might feel the pinch a little more.
  I'm not excessively critical of the ChessBase software in general; I use many of the features quite effectively. But a few of them have known faults you should know how to work around. 
  Another example: Try using a position search in a database; ignore the results. Then, edit the position within the search filter (add, move, delete pieces, whatever), make a note of the new position you're now searching for, and run the search again. Save the resulting list of games.  Now, reset the search filter completely (I suggest closing and reopening the database as well). Finally, set up the (altered) search position again from scratch, and run the search a 3rd time. The results from the 2nd (edited position) and 3rd (fresh position) searches should match. They frequently do not.  I've noted many cases where the fresh search filter returned many more games than the edited search filter.  I have no explanation for this, but I no longer edit the position in the search filter.  I always create a fresh position (usually by copying and pasting from a game window I set up for the purpose).
  Hope this is helpful!
  
  > **Comments:**
  > **username_1**: The Opening Book deals with positions, not variations, which can be confusing in the case of transpositions. In your Caro-Kann example, the position after 9.Bd2 occurred 15 times, out of which White scored 11.5/15 = 76.7%. The position after 9.Bd2 Bh7 occurred 8 times, but not all of these came from the position after 9.Bd2; some were transpositions. 21 games in total reached one of the five positions that occur when Black responds to 9.Bd2.  
  > **username_3**: @danf Your explanation makes sense, but there isn't much point to knowing what the stats are for the position after 9 Bd7 if all of the moves from that position lead to a completely different set of statistics. In effect, it's a case of reverse-you-can't-get-there-from-here, in which you can't avoid going places that you didn't intend.  I think it would be more intuitive and helpful to show the _averages_ of the ELO and Win Rate for the _continuations_, instead of the stats for the _position_ from which the continuations ensue, which are superseded by those of the transpositions anyway.  
  
  ---
  
  ### Answer by username_4 on 2016-08-26. Score: 1
  
  We do not know the exact format for Chessbase books, and it is entirely possible that what I'm about to say is not true in this case.
  
  The open standard book formats that I know of (Crafty, Pro Deo, Polyglot) represent chess positions as a 64-bit Zobrist hash. You can google how one of these works if you want to, it's beyond the scope of this answer. This is likely the same for Chessbase books.
  
  These hashes are designed so that the key for 1. e4 c5 2. Nf3 is *identical* to the key for 1.Nf3 c5 2. e4. This is useful for covering transpositions like this one. However, it means that it cannot distinguish between lines, resulting in there being no way of removing these transpositions.
  
  TL;DR I suspect this is impossible because of technical restrictions in the Chessbase book format.
  
  
  ---
  
  ### Answer by username_1 on 2015-01-02. Score: 1
  
  You can get this information from the Reference tab, rather than the Openings Book tab. (Of course the stats will correspond exactly only if your openings book was made from your reference database.)
  
  
  ---
  
  ### Answer by username_5 on 2015-09-29. Score: 0
  
  You can also create an opening key for the games, and arrange it the way you like. If you highlight a node in the key, and press 'S', you can see the statistics.
  
  > **Comments:**
  > **username_3**: unfortunately, we're researching lines where _each_ move has branches. Creating such a key would have to be automatic. The Reference function already does this on the fly; the difference is that the key is static/permanent, but the Reference report is dynamic/temporary. So, you can use the nodes of the key more than once, and pay the setup cost once. Using any position more than once in Reference requires _repeating_ all the calculations each time. I don't know of an automated way to create such keys, but the Opening Book feature does the equivalent. But its stats are wrong...  
  
  ---
  
  ### Answer by username_6 on 2015-09-30. Score: 0
  
  One solution that I have developed for this issue is that you can go to the first node. Now you take the game list and separate it. Then you use a tree on this to go to the second node. Etc. In the end you will end up with a list of games with the exact move order you are interested in.
  
  I know it is cumbersome and that an automatic solution would be great, (like a switch you could flip in the tree to have it either way) but just thought I would throw this out there as a possibility if it's only a few lines you need exact move orders for.
  
  
  ---
  
  