> On Dec 29, 2019, at 18:42, David Mertz <me...@gnosis.cx> wrote: > > On Sun, Dec 29, 2019, 9:23 PM Andrew Barnert >>> Here it is. I could save a line by not using the 'else'. >>> >>> def total_order(x): >>> if is_nan(x): >>> return (math.copysign(1, x), x) >>> else: >>> return (0, x) >> >> This doesn’t give you IEEE total order. Under what circumstances would you >> prefer this to, say, Decimal.compare_total, which does? > > > How does this differ from IEEE? I'm not being rhetorical, I really thought > that was their order. But I haven't looked carefully.
IEEE total order specifies a distinct order for every distinct bit pattern, and tries to do so in a way that makes sense. IIRC, this means -0.0 comes before 0.0, distinct but equal denormal values are ordered by exponent, sNaN comes after qNaN, two NaNs of the same kind are ordered by payload, negative NaNs come at the front rather than the back, and… I think that’s all the rules, but I wouldn’t want to bet too heavily on that. I don’t think you usually care too much about exactly how the values are ordered, but you do care that it’s consistent across implementations—two different programs sorting the same data in IEEE total order should give the same order. And leaving it up to the type and/or the end user means that you (or Stephen) don’t actually need to know how to correctly totally order Decimals or mpfrs, much less some crazy thing like Levi-Civita numbers; only the person writing the decimal or gmpy2 or infinitesimal module does. > median_employee = statistics.median((e.salary, e) for e in employees)[1] >> >> By the same argument, nothing actually needs a key function because you can >> always decorate-sort-undecorate. And yet, key functions are useful in all >> kinds of places. > > > It's a balance, I think. `key_fn=` feels much too "heavy" for users of > statistics module. Key functions are ubiquitous in Python, and I think people learn them reasonably early. You can always get around them with DSU, but the result is always less readable, and that’s why they’re ubiquitous. And that really isn’t any different here than in itertools.groupby or heapq.merge or anywhere else. If anything, DSU is trickier here than elsewhere (how do you undecorate after the sort but before the average-two-values step?), but key is not. IEEE total order, on the other hand… how many people even know that it’s a thing, much less know when and how to use it? > Handling NaNs one way or the other is the 95% concern. And for the 5%, DSU > covers it. The 95% case is handled by just ignore and raise. Novices should probably never be using anything else. Experts will definitely often want poison. And probably sometimes fast for backward compatibility and/or performance. That gets you to 98%. Experts will rarely but not never want total order. But when they do, they’ll know what they want, and how to find the appropriate function for the type they’re using, and how to pass it as a key function to a key parameter that works the same way as everywhere else in Python. And experts might also want something different from IEEE total order, like uniformly pushing all NaNs to the end. I’m not sure when you’d actually want that, but since it was the original suggestion that kicked off this whole discussion, it’s obviously not inconceivable. I get the idea that, once you’ve already got an on_nan param, adding another value to that param doesn’t add as much cognitive load as adding a whole other param would. But I think a total order value is so rarely useful that it’s probably more load than it’s worth, while a key param is a more widely useful and therefore worth more load (although maybe still not enough).
_______________________________________________ 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/JYQJPSDHDWYOQX2DSGPU4MIWW5FAUYS6/ Code of Conduct: http://python.org/psf/codeofconduct/
