# Making sense of Scid vs. PC tree score statistics

I can't seem to figure out how to interpret the score statistics when browsing a chess database with Scid vs. PC.

To give an example, the following is a position from the ICOfY chess database tree browsed with Scid vs. PC:

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:

... 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.

-

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.

-
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? – Marcus Junius Brutus Mar 22 '14 at 14:57
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. – RemcoGerlich Mar 22 '14 at 15:48