Answers.Body: <p>The statistics show what happened in games that reached the current <em>position</em>.</p>
  
  <p>So in your first diagram, there are 28 games that reached that position. White scored 30.3% on average in those games. In 11 of them, Nc3 was played here, and White scored 27.2% in those 11 games.</p>
  
  <p>The position after Nc3 was reached 72 times. That obviously includes the 11 games from above, but also 61 other games that reached this position in a different order of moves. And in these 72 together, white scored 52.7%.</p>
  
  <p>That's not inconsistent, you can go through the list of games yourself and verify the numbers.</p>
  
  <p>What it is, is an example why looking at move statistics can be very misleading. The fact that white scored only 30.3% from the first position doesn't mean that black is winning <strong>at all</strong>. You don't even know that a single one of those results had anything to do with the opening! There could be all kinds of reasons for the results, maybe black was the much better player in all of them, or there were some white blunders, or who knows what.</p>
  
  <p>Lies, damn lies, and statistics.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-03-22T14:57:30.873Z
Answers.Text: If so, then in my view, this is a case of a very bad decision in the UI design. The score statistics reported next to each move in the 1st position should obviously have indicated the average score of the **resultant** position after said move is played (including transpositions). So in the first screenshot, next to **Nc3**, the score reported should be 52.7% and not 27.2%. That would have been very useful and intuitive. Otherwise, as it now stands, these numbers are almost useless. Do I get you right? Or is there a way to properly "read" something in those numbers under the present model?
Answers.UserDisplayName: Marcus Junius Brutus
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-03-22T15:48:39.273Z
Answers.Text: The main problem is that the Tree Window is already noticeably slow, because every time it updates it has to scan the whole database to search for the current position (tens of millions of positions in case of Icofy). If it then has to do another search for each of the positions after every move that occurs, it'll be much slower still. Anyway this is mostly a problem in the early opening stages when such transpositions happen a lot, and there statistics are pretty unnecessary anyway.
Answers.UserDisplayName: RemcoGerlich
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-03-22T13:48:55.610Z
Answers.LastActivityDate: 2014-03-22T13:48:55.610Z
Answers.UserDisplayName: RemcoGerlich
Body: <p>I can't seem to figure out how to interpret the score statistics when browsing a chess database with <a href="http://scidvspc.sourceforge.net/" rel="noreferrer">Scid vs. PC</a>.</p>
  
  <p>To give an example, the following is a position from the <a href="http://www.icofy-blog.de/icofy-base/" rel="noreferrer">ICOfY</a> chess database tree browsed with Scid vs. PC:</p>
  
  <p><img src="https://i.sstatic.net/MqJVC.png" alt="enter image description here"></p>
  
  <p>In the above position White is to play and the move <strong>Nc3</strong> is shown as yielding a score of 27%. I.e. Black is winning by a wide margin. However, when I click on the <strong>Nc3</strong> move I am faced with the following screen:</p>
  
  <p><img src="https://i.sstatic.net/yE3d9.png" alt="enter image description here"></p>
  
  <p>... which paints a widely different picture for Black's prospects. Namely, showing a score of 46% for Black's most common reply (i.e. Black is only slightly better if I interpret the statistics correctly). Am I right in thinking that these statistics are not consistent with one another or am I failing to grasp something? Bonus point if you can explain why the <em>Event</em> description (lower left corner) is a series of question marks.</p>
  
Tags: <software><database><scid>
Title: Making sense of Scid vs. PC tree score statistics
ThreadText: # Making sense of Scid vs. PC tree score statistics
  
  (Asked by: username_0 on 2014-03-22)
  
  I can't seem to figure out how to interpret the score statistics when browsing a chess database with [Scid vs. PC](http://scidvspc.sourceforge.net/).
  
  To give an example, the following is a position from the [ICOfY](http://www.icofy-blog.de/icofy-base/) chess database tree browsed with Scid vs. PC:
  
  ![enter image description here](https://i.sstatic.net/MqJVC.png)
  
  In the above position White is to play and the move **Nc3** is shown as yielding a score of 27%. I.e. Black is winning by a wide margin. However, when I click on the **Nc3** move I am faced with the following screen:
  
  ![enter image description here](https://i.sstatic.net/yE3d9.png)
  
  ... which paints a widely different picture for Black's prospects. Namely, showing a score of 46% for Black's most common reply (i.e. Black is only slightly better if I interpret the statistics correctly). Am I right in thinking that these statistics are not consistent with one another or am I failing to grasp something? Bonus point if you can explain why the *Event* description (lower left corner) is a series of question marks.
  
  **Tags:** software, database, scid
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-03-22. Score: 7 | Accepted answer
  
  The statistics show what happened in games that reached the current *position*.
  
  So in your first diagram, there are 28 games that reached that position. White scored 30.3% on average in those games. In 11 of them, Nc3 was played here, and White scored 27.2% in those 11 games.
  
  The position after Nc3 was reached 72 times. That obviously includes the 11 games from above, but also 61 other games that reached this position in a different order of moves. And in these 72 together, white scored 52.7%.
  
  That's not inconsistent, you can go through the list of games yourself and verify the numbers.
  
  What it is, is an example why looking at move statistics can be very misleading. The fact that white scored only 30.3% from the first position doesn't mean that black is winning **at all**. You don't even know that a single one of those results had anything to do with the opening! There could be all kinds of reasons for the results, maybe black was the much better player in all of them, or there were some white blunders, or who knows what.
  
  Lies, damn lies, and statistics.
  
  > **Comments:**
  > **username_0**: If so, then in my view, this is a case of a very bad decision in the UI design. The score statistics reported next to each move in the 1st position should obviously have indicated the average score of the **resultant** position after said move is played (including transpositions). So in the first screenshot, next to **Nc3**, the score reported should be 52.7% and not 27.2%. That would have been very useful and intuitive. Otherwise, as it now stands, these numbers are almost useless. Do I get you right? Or is there a way to properly "read" something in those numbers under the present model?  
  > **username_1**: The main problem is that the Tree Window is already noticeably slow, because every time it updates it has to scan the whole database to search for the current position (tens of millions of positions in case of Icofy). If it then has to do another search for each of the positions after every move that occurs, it'll be much slower still. Anyway this is mostly a problem in the early opening stages when such transpositions happen a lot, and there statistics are pretty unnecessary anyway.  
  
  ---
  
  