On Dec 29, 2019, at 20:04, Richard Damon <rich...@damon-family.org> 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 -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2CP6PJY5Z6UGUNL6XSK3DZRSKXP3Z44D/ Code of Conduct: http://python.org/psf/codeofconduct/
