Here’s a cute exercise for the next time you’re teaching radix sorting in an algorithms class:

Suppose you’re given as input a set of real numbers , and an integer parameter . Describe an algorithm for sorting the numbers in time . You can assume that standard arithmetic operations on real numbers (including comparisons and rounding down to an integer) take constant time per operation.

Models of computation that mix constant-time real arithmetic and rounding operations can be problematic, as by building up and then rounding numbers with unlimited precision you can access a level of computational power beyond what actual computers can do, but I don’t think that’s a concern here. If someone wants to use bit-packing tricks to implement a crazy but fast sorting algorithm in this model, they’re beyond the level of this exercise.

The same method (which I’m not going to describe, to preserve its value as an exercise) more generally allows you to take as input pairs and sort the numbers in time where . But it relies heavily on the fact that you’re adding integers to the ’s. For a problem that can’t be handled in this way, consider instead sorting the numbers where we multiply instead of adding. Or, if you prefer to view this as a type of sorting problem, take logs in your favorite base and sort the numbers . It’s not at all obvious to me whether this can be done in the same time bound.

The motivation for looking at all this is a question about how to implement the greedy set cover quickly. You can find the unweighted greedy set cover in linear time (linear in the sum of the sizes of the input sets; this is an exercise in CLRS), and you can approximate the weighted greedy set cover very accurately in linear time using similar ideas. If you could sort quickly you could use the sorted order to compute the weighted greedy set cover exactly in the same time as the sorting algorithm. Which is totally useless because the greedy cover is already an approximation, so a fast and accurate approximation to the greedy cover is good enough. But I think the question of sorting is interesting despite its uselessness in this application.

(Discuss on Mastodon)