Menu
▾
▴
#199 two new built-in functions, 'ordering' and 'ranks'
I'd like to propose two new built-in functions, one to return a permutation which puts a list of items into sorted order, and one to return the ranks (positions in sorted order) of a list of items.
The first can be named ordering and the second can be named ranks. Those are both terms which are used in various mathematical contexts, so the names are my attempt to distinguish them. These functions exist in various other systems; e.g. in R they are named order and rank, respectively.
When the items are all distinct, ranks and ordering are inverse permutations of each other.
When some items are tied (i.e., equivalent under the sorting predicate), the behavior of ranks is governed by an optional argument. All tied items are assigned the mean rank when ties = mean and each tied item is assigned a distinct rank when ties = distinct. (R's rank function has other options; I'm not feeling enough motivation to implement all of them.)
I'd like to have optional arguments for both functions, and I see different ways to go about it, with various trade-offs. For both ordering and ranks, the sorting comparison predicate is an optional argument. There is a proposal on the table (see https://sourceforge.net/p/maxima/feature-requests/198/) to implement an optional argument for sort which would return a comparison key; if that comes to pass, then both ordering and ranks would want to have that as an optional argument too.
For ranks, the method for handling ties would be another optional argument.
At this point, I'd like to recommend that all optional arguments be represented by "=" expressions, specifically: comparison = <function of 2 arguments>, key = <function of 1 argument>, and ties = <'mean' or 'distinct'>. I'm willing to consider other arrangements if someone wants to suggest something.
In summary the two functions would be
ordering (<list>, comparison = <2 args function>, key = <1 arg function>)
ranks (<list>, comparison = <2 args function>, key = <1 arg function>, ties = <mean or distinct>)
where the optional arguments can be present or absent and in any order, and key = ... would be implemented when sort supports it.
What does anyone think about that?
