In the IEEE total order, +0 and -0 are distinct, which your orderdoesn'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]