# User Percentile computations appear to be wrong

Forgive me if this has been brought up either here or meta.se before, but I could not find it in either.

On a user's activity page, beneath their reputation, there is a label that says "top x% overall". Clicking this brings you to the user reputation leagues. However, there appears to be a flaw here.

At the top of this page, it shows a cumulative total of users (as seen in the image below).

Lower down, in the right-hand area, there is a table representing a breakdown of the number of users by reputation total, as shown below.

Adding the values in the second column, we arrive at the same number listed in the first image; that is to say, each row represents the total number of users with at least that reputation but less than the prior row's total.

This is confirmed by looking at the breakdowns; there are in fact 67 users here with >50,000 rep. However, if these data are cumulative, then the bottom-most row, representing users with 1+ reputation, should read the same as the number in the first image. It does not. Furthermore, it does not appear to be exclusive of the cumulative total in the 200+ rep row. Instead, it appears to incorrectly subtract the values of all prior rows, instead of just the cumulative 200+ row. (This detail was pointed out by @quid; thank you!)

• n.b. the "correct" denominator for computing the ranks for all users with 200+ rep should be 28276 as of this writing. – Emily Jun 20 '16 at 4:16
• Related post on meta.SE: miscalculation of top x% this week/month/quarter/year/overall. It is related to the fact that only users with 200+ rep are counted. (Perhaps meta.SE would be also a reasonable place to report this bug.) – Martin Sleziak Jun 20 '16 at 7:27
• However, looking at the reputation league, it seems that there are 13034 users with reputation 200 or higher. So the row called 200+ probably represents all users with at least 200 reputation points. (Not only users between 200 and 500.) – Martin Sleziak Jun 20 '16 at 7:33
• Just to check the computation: 24+67+175+498+884+1434+2044+3641+6475+13034+230783=259059 – Martin Sleziak Jun 20 '16 at 7:39
• – Martin Sleziak Jun 20 '16 at 7:43
• I think the actual problem is just that the table is done inconsistently and labeled incorrectly; the 1+ really is less than 200, while for the other x+ it is really x or more so > x. – quid Jun 20 '16 at 7:57
• @MartinSleziak interesting find. I think though the answer there is not completely correct. See my comment above. – quid Jun 20 '16 at 8:00
• @quid Still there seems to be some problem with the numbers. In your interpretation we get less than 244k total users. Which is much less that the number 259k which appears on the same page. – Martin Sleziak Jun 20 '16 at 8:15
• @MartinSleziak true enough. In addition I confused myself in my answer...but now I think I have a consistent theory. – quid Jun 20 '16 at 8:33
• @MartinSleziak I now think the 1+ in all likelihood is determined just to make the computation you give work, that is as a difference of the sum and the total user count (that themselves are likely extracted from the DB). – quid Jun 20 '16 at 8:49
• @martinSleziak The 13034 number cannot represent all 200+ rep users if the 259059 number is to be believed. There is no inclusion-exclusion at play. And as a gut check, that number feels low. – Emily Jun 20 '16 at 10:40
• The 13k should be fine. This is page 500 of users sorted by points We are at around 150 points there. There are 36 user per page so we are below 20k th user position but above 15k. So that's compatible with around 13k user above 200, yet not with 20k such users. // The exact page now is the 354 th This gives something slightly below 13k. Yet this discrepancy may be due to unregestired; deleted, etc. – quid Jun 20 '16 at 10:57

This has been fixed. The issue was in the way the "1+" group was calculated.

All the "n+" groups were exactly what they should have been, the number users with rep of at least "n", so basically "200+" includes the "500+" users.

The "1+" was instead calculated assuming the list was of non overlapping buckets, so we removed the sum of all the row counts from the total number of users, which is a known value.

I've set it so we just show the total number of users now in the 1+ row.

This will be deployed in the next Stack Exchange release later on.

This is now deployed.

There is a problem, yet it is a bit different from the one claimed. There is no problem with the computation of the percentile.

Let us look at a site with a much smaller number of users to simplify manual checks.

The site Retro Computing has 29 pages of users (a page holds 36 names). This gives a total number of users above 1008 and below 1044. This is in line with the 1025 users claimed on http://stackexchange.com/leagues/392/alltime/retrocomputing.

Their table is:

Total Rep  | Users
3,000+     |   1
2,000+     |   2
1,000+     |  10
500+       |  30
200+       |  68
1+         | 914


There is only 1 user above 3000 and one user between 2000 and 3000, and there are 10 above 1000 (not 13) and actually 68 above 200 (and not more than 100).
Thus, the x+ (except for 1+) really mean above the given threshold.

Yet then the sum of all matches the 1025. Thus, 1+ does not really mean 1 or more but rather it seems is intended to mean between 1 and 199.

Yet it seems to be a computed based on a misunderstanding of the earlier entries in the table, so that this value does not have any significance.

Summary: The x+, except for 1+, gives the number of user above the threshold. The 1+ does not give a significant number.

• Hm, interesting. This would imply that the 259059 number is incorrect, then. In this case, were this true, then retro has 68+914=982 users, so the 1+ row must be omitting some if your bounds are correct. – Emily Jun 20 '16 at 10:42
• No, I think it is somehow the other way around. The total number of users is correct. The number of users above 200 is the 200+ and is also correct. Yet the 1+ is neither the number of users with 1-199 points nor the number of users with at least 1 point (which would be just the total number of users). Instead the number given for 1+ is the number of total users minus the sum of users above 200 , users above 500, ... It has no real significance. The intention likely was to compute the number of those below 200, but it is done incorrectly. – quid Jun 20 '16 at 10:52
• Ah, yes. Agreed. It seems as though a computation gone awry. I will edit this bug report to show the true bug when I am before a proper computer. Thanks! – Emily Jun 20 '16 at 10:57