Mailman 3 Total_order - Python-ideas

30 Dec 2019

      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]

Total_order

David Mertz

Tim Peters

David Mertz

Tim Peters

Richard Damon

Anders Hovmöller

Andrew Barnert

Steven D'Aprano

tags

participants (6)