On 12/29/19 7:43 PM, Tim Peters wrote:
[Christopher Barker <python...@gmail.com>]
...
But the biggest barrier is that it would be a fair bit of churn on the sort()
functions
(and the float class), and would only help for floats anyway. If someone want
to propose this, please do -- but I don't think we should wait for that to do
something
with the statistics module. Also, if you want to pursue this, do go back and
find
the thread about type-checked sorting -- I think this is it:
https://mail.python.org/pipermail/python-dev/2016-October/146613.html
I'm not sure if anything ever came of that.
It was completed and is part of released CPython now.
But it's useless for this particular purpose. Leaving aside that
sort() is a wrong place to put this (as David M keeps saying, pass a
key= function to sort if you want a non-default sorting order),
type-checked sorting was purely a speed optimization, and applies only
to lists with a single type of element. So, e.g., it could plug in a
different sort order for lists containing only floats, but mix in a
single int (or any other non-float object) and the optimization is
100% disabled, leaving you with the default comparison logic instead.
That said, if we could wind back the clock, I'd make Python's floats
use something like the later IEEE total_order ordering instead. No
goofy results, nothing special about NaNs. For people who really
wanted IEEE's insane ;-) comparison semantics, that's fine - they'd
get it via, say, math.ieee_goofy_compare(a, b, flags) instead, where
flags is the bitwise-or of 0 or more of {LT, EQ, GT, UNORD}. E.g.,
pass GT | UNORD to return True iif the IEEE mandated result is
"greater than" or "unordered" (each IEEE comparison outcome is exactly
one of those four).
Question, could that optimization detect that we have a list of just
floats, and pass it a 'total_order' comparison function to sort instead
of the default __lt__?
If so, then I don't think it would be a breaking change to do so. Code
that explicitly does floating point comparisons still get the IEEE
mandated results, but sorts that happen to have NaNs in them now get a
defined order, rather than the currently undefined order.
I suppose that there may be some programs out there that depend on the
current behavior (even though not promised, and subject to change if the
sort algorithm changes).
The total order maintains all the current ordered relationships, it just
adds a defined order for NaNs, and an order for equal values that have
differing representations (which I think for binary floating point is
just -0 and +0). I don;t think sorted makes any promises for stability
for 'equal' values, so sorting -0 before +0 shouldn't be a problem.
--
Richard Damon
_______________________________________________
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/VMPBNNVDTF3MWMTBE5BJDPHISHY5NBPP/
Code of Conduct: http://python.org/psf/codeofconduct/
