On Dec 29, 2019, at 20:04, Richard Damon <[email protected]> wrote: > > Thus your total_order, while not REALLY a total order, is likely good enough > for most purposes.
Well, it is a total order of equivalence classes (with all IEEE-equal values being equivalent, all negative NaNs being equivalent, and all positive NaNs being equivalent). But whether it’s good enough for most purposes depends on what those purposes are. I’m having a hard time imagining any purposes where “some well-defined but arbitrary, unnatural, and idiosyncratic total order of equivalence classes of the binary64 values” is of any use at all. Maybe that’s just a failure of my imagination. But “the specific well-defined but arbitrary, unnatural order that almost every other similar bit of code in every language is likely to use” seems a lot more likely to be useful. (And, needless to say, so does “this specific order that I defined myself”. I don’t know why the OP wanted to treat all NaNs as equivalents values greater than inf, but presumably he does know, and that’s fine. So, I don’t think that needs to be built into the module as one of the options, but I don’t see why he shouldn’t be able to specify it explicitly.) _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/2CP6PJY5Z6UGUNL6XSK3DZRSKXP3Z44D/ Code of Conduct: http://python.org/psf/codeofconduct/
