Tim Peters <t...@python.org> added the comment:
> *Clearly*, negative NaNs should be sorted to the start
> of the list, while positive NaNs are sorted to the end
> of the list. (Yes, I'm joking, but only a little bit: that's
> the result you'd get if you used IEEE 754's totalOrder
> to sort.
So not a joke at all! If a revision of the standard mandates a specific total
ordering, it's certain that people will eventually ask for it be supported.
> But it's difficult to see how it would be useful in
> practice, given that people usually don't know about
> or care about the sign that their NaN has.)
The standard "wastes" an enormous number of bit patterns on NaNs, catering to
some hypothetical system that uses those bits to encode diagnostic information
(e.g., maybe the source code line number of the operation that produced the
NaN), and this is just one more "wasted" bit. If any implementation actually
used any of these possibilities, I'm sure semi-plausible ;-) use cases would
follow.
I bet this was driven by implementation - it's _almost_ what you'd get if you
viewed the float bit patterns as signed integers. Seems the only flaw with
that is that the negative floats are in "reverse order" then. Which can be
repaired easily enough; e.g.,
import struct
def totkey(x, *, MASK=(1 << 63) - 1, pack=struct.pack):
asint = int.from_bytes(pack(">d", x), "big", signed=True)
if asint < 0:
asint ^= MASK
return asint
Then
xs = [2.0, 1.0, 0.0, -0.0, -1.0, -2.0,
math.inf, -math.inf, math.nan, -math.nan]
print(sorted(xs, key=totkey))
displays
[nan, -inf, -2.0, -1.0, -0.0, 0.0, 1.0, 2.0, inf, nan]
That makes negative NaNs smallest, positive NaNs largest, puts -0 before +0,
and in all other respects I checked ;-) appears to match the totalOrder
requirements. On most boxes, it will even consider (positive) signaling NaNs
to "be smaller" than (positive) quiet NaNs, which totalOrder also seems to
require (presumably again not because it's obviously useful, but because it
_follows_ from a very simple implementation like the one above).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36095>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
