In the IEEE total order, +0 and -0 are distinct, which your order doesn't handle, For NaNs, the issue is that NaN is NOT a single representation, but each combination of the sign bit and the 52 mantissa bits (except all zeros which signify infinity) when the exponent field is all ones is a different NaN (and the MSB of the mantissa indicates quiet or signalling). you code makes all these values unordered with respect to each other as opposed to having a distinct strict order. That probably isn't that important of a distinction. Ok. Fair enough. My 3-line version puts all the NaNs in whatever order they started out in in the list. Well, positive and negative get separated properly. I could add one more line to deal with the +/- zeros, but it's the same idea of making a tuple where the first element sorts first (maybe -0.5 / 0.5, or make the NaNs +/-2, whatever). The thing is that there's no *Python* way (other than the struct module) to get NaNs with any particular bits. I have no control over which bits I'll get with `float('nan')` or `math.nan` or `1e1000-1e999`. But if we actually want those bits I don't control ordered, we have to do it Tim's way... I get it now. Has anyone actually ever used those available bits for the zillions of NaNs for anything good?
IEEE total_order puts NaN as bigger than infinity, and -NaN as
less than -inf.
You mean like this?
def total_order(x): ... if math.isnan(x): ... return (math.copysign(1, x), x) ... return (0, x) ... ... nums = [1, 2, float('-inf'), float('nan'), float('inf'),
float('-nan')]
nums [1, 2, -inf, nan, inf, nan] sorted(nums, key=total_order) [nan, -inf, 1, 2, inf, nan]