This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients brandtbucher, cheryl.sabella, mark.dickinson, rhettinger, serhiy.storchaka, tim.peters
Date 2019-02-24.22:58:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1551049109.6.0.721748992761.issue36095@roundup.psfhosted.org>
In-reply-to
Content
> *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).
History
Date User Action Args
2019-02-24 22:58:29tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, serhiy.storchaka, cheryl.sabella, brandtbucher
2019-02-24 22:58:29tim.peterssetmessageid: <1551049109.6.0.721748992761.issue36095@roundup.psfhosted.org>
2019-02-24 22:58:29tim.peterslinkissue36095 messages
2019-02-24 22:58:28tim.peterscreate