# Map each list value to its corresponding percentile

I think your example input/output does not correspond to typical ways of calculating percentile. If you calculate the percentile as “proportion of data points strictly less than this value”, then the top value should be 0.8 (since 4 of 5 values are less than the largest one). If you calculate it as “percent of data points less than or equal to this value”, then the bottom value should be 0.2 (since 1 of 5 values equals the smallest one). Thus the percentiles would be `[0, 0.2, 0.4, 0.6, 0.8]` or `[0.2, 0.4, 0.6, 0.8, 1]`. Your definition seems to be “the number of data points strictly less than this value, considered as a proportion of the number of data points not equal to this value”, but in my experience this is not a common definition (see for instance wikipedia).

With the typical percentile definitions, the percentile of a data point is equal to its rank divided by the number of data points. (See for instance this question on Stats SE asking how to do the same thing in R.) Differences in how to compute the percentile amount to differences in how to compute the rank (for instance, how to rank tied values). The `scipy.stats.percentileofscore` function provides four ways of computing percentiles:

``````>>> x = [1, 1, 2, 2, 17]
>>> [stats.percentileofscore(x, a, 'rank') for a in x]
[30.0, 30.0, 70.0, 70.0, 100.0]
>>> [stats.percentileofscore(x, a, 'weak') for a in x]
[40.0, 40.0, 80.0, 80.0, 100.0]
>>> [stats.percentileofscore(x, a, 'strict') for a in x]
[0.0, 0.0, 40.0, 40.0, 80.0]
>>> [stats.percentileofscore(x, a, 'mean') for a in x]
[20.0, 20.0, 60.0, 60.0, 90.0]
``````

(I used a dataset containing ties to illustrate what happens in such cases.)

The “rank” method assigns tied groups a rank equal to the average of the ranks they would cover (i.e., a three-way tie for 2nd place gets a rank of 3 because it “takes up” ranks 2, 3 and 4). The “weak” method assigns a percentile based on the proportion of data points less than or equal to a given point; “strict” is the same but counts proportion of points strictly less than the given point. The “mean” method is the average of the latter two.

As Kevin H. Lin noted, calling `percentileofscore` in a loop is inefficient since it has to recompute the ranks on every pass. However, these percentile calculations can be easily replicated using different ranking methods provided by `scipy.stats.rankdata`, letting you calculate all the percentiles at once:

``````>>> from scipy import stats
>>> stats.rankdata(x, "average")/len(x)
array([ 0.3,  0.3,  0.7,  0.7,  1. ])
>>> stats.rankdata(x, 'max')/len(x)
array([ 0.4,  0.4,  0.8,  0.8,  1. ])
>>> (stats.rankdata(x, 'min')-1)/len(x)
array([ 0. ,  0. ,  0.4,  0.4,  0.8])
``````

In the last case the ranks are adjusted down by one to make them start from 0 instead of 1. (I’ve omitted “mean”, but it could easily be obtained by averaging the results of the latter two methods.)

I did some timings. With small data such as that in your example, using `rankdata` is somewhat slower than Kevin H. Lin’s solution (presumably due to the overhead scipy incurs in converting things to numpy arrays under the hood) but faster than calling `percentileofscore` in a loop as in reptilicus’s answer:

``````In [11]: %timeit [stats.percentileofscore(x, i) for i in x]
1000 loops, best of 3: 414 µs per loop

In [12]: %timeit list_to_percentiles(x)
100000 loops, best of 3: 11.1 µs per loop

In [13]: %timeit stats.rankdata(x, "average")/len(x)
10000 loops, best of 3: 39.3 µs per loop
``````

With a large dataset, however, the performance advantage of numpy takes effect and using `rankdata` is 10 times faster than Kevin’s `list_to_percentiles`:

``````In [18]: x = np.random.randint(0, 10000, 1000)

In [19]: %timeit [stats.percentileofscore(x, i) for i in x]
1 loops, best of 3: 437 ms per loop

In [20]: %timeit list_to_percentiles(x)
100 loops, best of 3: 1.08 ms per loop

In [21]: %timeit stats.rankdata(x, "average")/len(x)
10000 loops, best of 3: 102 µs per loop
``````

This advantage will only become more pronounced on larger and larger datasets.