# Algorithm to pick user

I need an algorithm for picking a user.

Users are identified by letter {A, B, C, ...} and are ranked by number {1, 2, 3, ...}. Rank is the degree of likelihood to be picked, so a rank 2 user is twice as likely to be picked over a rank 1 user, and rank 4 is four times as likely, etc.

So let's say four users are {A, B, C, D}, with rank {1, 1, 5, 2} respectively. A user table might store rank:

``````   USER   RANK
A   1
B   1
C   5
D   2
``````

How do I pick a user based on rank?

My first idea for an algorithm is to add up all the ranks 1 + 1 + 5 + 2 to obtain a sum of 9. Then assign subranges from 1 to 9 to each user, where subrange size is user rank. So A has range [1, 1], B has range [2, 2], C has range [3, 7] (5 possibilities due to rank being 5), and D has range [8, 9]. The table becomes this:

``````   USER   RANK  RANGE
A   1     [1, 1]
B   1     [2, 2]
C   5     [3, 7]
D   2     [8, 9]
``````

Then calculate a random value from 1 to 9, and find the user whose range contains that value. So if the random value is 4, user C is picked because 4 falls within range [3, 7].

This achieves fairness based on rank. If you repeat picking randomly this way, on the average, users will be chosen fairly, and no user will be starved.

However, it feels sloppy, because to add or remove users, I have to recalculate all the ranges. Here is removing user C (recalculate range of user D):

``````   USER   RANK  RANGE
A   1     [1, 1]
B   1     [2, 2]
D   2     [3, 4]
``````

And here is changing user A to have rank 2 (recalculate range of B and D):

``````   USER   RANK  RANGE
A   2     [1, 2]
B   1     [3, 3]
D   2     [4, 5]
``````

What is the best algorithm to pick a user? Surely recalculating ranges for every user add, delete, or update is suboptimal. Is there a well-known function or algorithm that can help?

UPDATE: @rwong got me thinking about grouping people by rank, then picking rank instead of picking user. With one person in each rank, you turn the random-shaped ranges into a very linearly-growing ranges (one dot is one chance to be picked):

``````Rank 1:  *
Rank 2:  * *
Rank 3:  * * *
Rank 4:  * * * *
Rank 5:  * * * * *
``````

Works great for exactly one person per rank, but it falls apart when you have lots of people at rank 1, where their chances should increase by the number of people within that rank, possibly overtaking the chances of higher ranks.

Now we're back to an irregular shape, and must pick from it. A friend pointed me to Rejection sampling. This seems to be a great solution where you pick a random x and y coordinate, see if it falls within the shape, and if so, we now picked rank. Then pick a random person within that rank.

To show this solution, here is the shape with multiple people inside each rank. For rank 2, there are 5 people, so that's 2 x 5 = 10 chances:

``````User count   Rank   Chances(graph)       Chances(number)
5            1      * * * * *            5
5            2      * * * * * * * * * *  10
1            3      * * *                3
0            4                           0
1            5      * * * * *            5
``````

The algorithm is to pick a random row (like picking an x coordinate), and pick a random value from 1 to max(chances) (like picking a y coordinate). See if that is less than or equal to the number of chances at that rank. If not repeat until you have a valid rank and chance. This takes care of distribution probability. Now that you have chosen a valid rank, at that point you simply pick a random person within that rank. Done!

The beauty is, to add or remove someone, you increment or decrement the user count column, and assign a new Changes(number). Two small very simple updates. The memory complexity and time complexity of add/remove/update user and also complexity to pick a user is nothing, like O(1).

We grouped user by rank, and captured user count in each rank, then calculate chances for that rank, and used a simple looping algorithm to pick random rows and chance values until we get a hit, and finally pick a random person at that rank.

• What are your complexity requirements? Do you need to choose fast, add users fast, delete users fast, change ranks fast? It's always a trade-off and you can't get it all for free. Commented Aug 22, 2013 at 5:58
• If there aren't many rank levels, then put all users of the same rank into one list, and assign an aggregate range for this list at this rank. Commented Aug 22, 2013 at 6:07
• Please define "best". Having ranges precalculated allows binary search, which is fast. Recalculating ranges for every user add, delete, or update is fine if add/delete/update occurs seldom. Commented Aug 22, 2013 at 10:59
• An interesting trade-off might be to pre-calculate ranges, but to store them in a kind of B-tree structure, with each leaf restarting the ranges at 0. This way, an update / delete may only invalidate a small portion of the structure (the rest of its own leaf, plus the right portion of the parent layers). This might be worthwhile exploring if performance is paramount, and you are dealing with an extremely large number of users. Commented Aug 22, 2013 at 11:53
• @maxpolk Well, because the "different probabilities" are actually relative to the entire set, it's reasonable that the operation will need to take into consideration all the other records, in some form. In general, you can either do this each time, or pre-calculate, but "fast in every scenario and easy to code" are generally at odds with each other :) (actually, even "fast in every scenario" by itself is impossible) If there's such a solution for this problem, it doesn't seem to be well known. Commented Aug 23, 2013 at 6:11

1. Put each user `rank` times into a suitable data structure (bag, multiset, list, array). Such a data structure should already be available for your language, you probably don't need to implement it yourself.
2. Sample a random element from that data structure. Such an operation should already be available, you probably don't need to implement it yourself.

For example in Ruby:

``````users = %i[A B C D]
ranks = [1, 1, 5, 2]

user_pool = users.map.with_index {|u, i| [u] * ranks[i] }.flatten
# => [:A, :B, :C, :C, :C, :C, :C, :D, :D]

user_pool.sample
# => :C
``````

No loops, no counting, no computing totals. Just two lines making use of the collections framework.

• This is correct answer. Commented Aug 22, 2013 at 9:21
• -1: it's an easy hack, but it's way sub-optimal if the ranks are higher than single digits. Commented Aug 22, 2013 at 10:43
• This answer is correct (that's why I am not going to downvote), but I guess it will become slow and a memory hog if the ranks are getting big. The OP should have given more information about the expected number of users and the expected rank size. @vartec: downvotes are for wrong answers, not for sub-optimal ones. Commented Aug 22, 2013 at 10:45
• @DocBrown: question is clearly about algorithm, not about code for quick-dirty hack.Thus this answer is wrong, because this is not the correct algorithm. Commented Aug 22, 2013 at 10:48
• Nice solution: (1) extremely fast at runtime O(1); (2) manageable space grows linearly with number of users O(n); (3) add/remove/update users supported by collection search O(log(n)) Commented Aug 23, 2013 at 12:25

You don't have to pre-calculate the ranges if you know the rank.

1. Add up the total in ranks
2. create your random number between 1 and that sum
3. To select the user, start a count at zero, loop through the users to create a running total of ranks, and when that total equals or exceeds your random number, thats your user.
• Actually, this means calculating the original ranges in the OP's example on the fly every time a user is selected, which is a correct answer, so I gave you +1. But the more interesting question would be: is there a datastructure which allows quick picking of users without looping over them all, and without recalculating the whole ranges for every add/delete/update? Commented Aug 22, 2013 at 10:57
• @DocBrown: I can imagine some kind of B-tree, where you'd do O (log(n)) recalculations rather than O (n) on update/insert/delete. Commented Aug 22, 2013 at 11:51
• Very nice solution, the sum of ranks can be stored in a static variable and easily change by adding/deleting/updating of user. There can be also the 'running total of ranks' for every user to make finding the user faster (just half-interval section to find the 'running total of ranks' >= random number). This 'running total of ranks' must be updated only by deleting or updating of user Commented Aug 23, 2013 at 8:51

If you reverse your RANK value so that lower values are more likely than it's a lot easier, or you can define a cap RANK value of say 10 and then just go (10-RANK).

To implement this in SQL it's easy.

``````SELECT *,((10-rank) * RAND()) AS odds
FROM users
ORDER BY odds
LIMIT 1;
``````

That will generate a random value per user from 0 to their rank. Users with a higher rank are more likely to sort above others, then just find the first one.

• The comments on this similar answer suggest strongly that this doesn't give the right distribution. Commented May 8, 2014 at 9:05