[issue36095] Better NaN sorting.

Marco Sulla added the comment: Excuse me, ignore my previous post. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36095] Better NaN sorting.

Marco Sulla added the comment: marco@buzz:~$ python3.9 Python 3.9.0a0 (heads/master-dirty:d8ca2354ed, Oct 30 2019, 20:25:01) [GCC 9.2.1 20190909] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from decimal import Decimal as Dec, BasicContext as Bctx >>> a

[issue36095] Better NaN sorting.

Tim Peters added the comment: Sorry, but I'm not replying here any more: the issue tracker is not for asking questions or brainstorming ideas. Take this to python-ideas, please. If a concrete proposal that gains traction results, _then_ the issue tracker may be an appropriate place (but

[issue36095] Better NaN sorting.

Marco Sulla added the comment: Excuse me, I had an epiphany. NaN returns False for every comparison. So in teory any element of the iterable should result minor that NaN. So NaN should treated as the highest element, and should be at the end of the sorted result! Indeed this is the

[issue36095] Better NaN sorting.

Tim Peters added the comment: Ah, so you're proposing a hack that would catch some, but not all, cases where a total ordering doesn't exist. Why? The issue tracker isn't a suitable place to discuss it regardless, so if you want to pursue it I'd suggest taking it to python-ideas. If you

[issue36095] Better NaN sorting.

Marco Sulla added the comment: > No idea what "are minor that another object" could possibly mean. Oh my god... a < b? > I don't know what purpose would be served by checking ">=" too Well, it's very simple. Since the sorting algorithm checks if a < b, if this check fails, I propose to

[issue36095] Better NaN sorting.

Tim Peters added the comment: Marco, your > I suppose the sorting function checks if the objects of > the iterable are minor that another object was incoherent to me. No idea what "are minor that another object" could possibly mean. As Mark explained, the mathematical meaning of

[issue36095] Better NaN sorting.

Marco Sulla added the comment: Anyway, Java by default puts NaNs at the end of the iterable: https://onlinegdb.com/SJjuiXE0S -- ___ Python tracker ___

[issue36095] Better NaN sorting.

Marco Sulla added the comment: Excuse me, but have you, Dickinson and Peters, read how I propose to check if the object is orderable or not? I explained it in a very detailed way, and this does not change the float comparison. And does not need to check first if the iterable it totally

[issue36095] Better NaN sorting.

Tim Peters added the comment: Closing as Mark suggested, but as "not a bug" rather than "won't fix". That floats aren't totally ordered is a consequence of IEEE 754 semantics, not Python's whim. As Mark said, if people want a total_ordering function for floats, that should be opened as a

[issue36095] Better NaN sorting.

Mark Dickinson added the comment: Tim, Raymond: I propose that we close this issue as "won't fix". The suggestion to add `math.total_ordering` could be broken out into a separate issue. -- ___ Python tracker

[issue36095] Better NaN sorting.

Mark Dickinson added the comment: > IMHO sorting functions should emit a warning if they contains an unorderable > objects How do you define "unorderable", and how do you propose to detect "unorderable objects" efficiently in practice within the sorting algorithm? What you propose isn't

[issue36095] Better NaN sorting.

Marco Sulla added the comment: Excuse me, a little errata: > After the current object a is checked against the object b, if > `all_orderables` is true [...] must be change to > After the current object a is checked against the object b, ***if the check > returns false and*** if

[issue36095] Better NaN sorting.

Marco Sulla added the comment: I'm in favor of a `math.total_ordering` function, but IMHO sorting functions should emit a warning if they contains an unorderable objects. This can be done easily: I suppose the sorting function checks if the objects of the iterable are minor that another

[issue36095] Better NaN sorting.

Tim Peters added the comment: > *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

[issue36095] Better NaN sorting.

Brandt Bucher added the comment: One other idea I had considered was having a new magic method intended to be used for elementwise comparisons such as these (I’m thinking specifically of the old __cmp__/tp_compare). Sorting routines could check for this method on each element, but fall back

[issue36095] Better NaN sorting.

Mark Dickinson added the comment: Agreed with Raymond and Tim here that the sorting functionality itself shouldn't be special-cased for nans. [Tim] > So people who go down this path can't get two steps before making a fork in > the road ;-) Well, both those solutions are wrong. *Clearly*,

[issue36095] Better NaN sorting.

Tim Peters added the comment: If we could roll back the clock, I'd impose a total ordering on floats in Python and supply some other way to spell 754's comparison operators (which users would have to ask for explicitly if they wanted to hassle with the near-useless and too-often-surprising

[issue36095] Better NaN sorting.

Raymond Hettinger added the comment: This issue isn't sorting. The issue is with what NaNs do. You can propose to "fix" NaNs rather than special casing everything else in Python that compares two values. A NaN could be given a deterministic sort order relative to other floats (much as

[issue36095] Better NaN sorting.

Brandt Bucher added the comment: Thanks for the feedback. I agree with you on the iffy delegation issue. However, this is problem that I feel deserves a fix... the behavior (silently producing garbage results) is just so un-pythonic. It’s been made clear in other issues that a warning isn’t

[issue36095] Better NaN sorting.

Raymond Hettinger added the comment: -1 I am flat opposed to special casing the list.sort() code for the specific case of NaNs. This is an incorrect delegation of responsibility. The sorted objects are responsible for saying how they will sort and whether than is. deterministic. Note,

[issue36095] Better NaN sorting.

Brandt Bucher added the comment: As a design decision, I consciously chose "no". However, it would be straightforward to make the change to support float subclasses: #define ISNAN(N) (N->ob_type == _Type && Py_IS_NAN(PyFloat_AsDouble(N))) becomes #define ISNAN(N) (PyFloat_Check(N) &&

[issue36095] Better NaN sorting.

Serhiy Storchaka added the comment: Does it work for subclasses of float? For other floating point types like numpy.float32? -- nosy: +serhiy.storchaka ___ Python tracker

[issue36095] Better NaN sorting.

Cheryl Sabella added the comment: This has been brought up in the past, for example, see #12286. -- nosy: +cheryl.sabella ___ Python tracker ___

[issue36095] Better NaN sorting.

Change by Karthikeyan Singaravelan : -- nosy: +rhettinger, tim.peters ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36095] Better NaN sorting.

Change by Brandt Bucher : -- keywords: +patch pull_requests: +12031 stage: -> patch review ___ Python tracker ___ ___

[issue36095] Better NaN sorting.

New submission from Brandt Bucher : Sorting sequences containing NaN values produces an incompletely sorted result. Further, because of the complexity of the timsort, this incomplete sort often silently produces unintuitive, unstable-seeming results that are extremely sensitive to the