[issue44370] Inconsistent results for min() and max() with math.nan as argument

Raymond Hettinger added the comment: > Maybe add two key functions for making NaN either the smallest > or the largest number? SQL does this with NULLS FIRST or NULLS LAST but it is a nuisance. I think it better to opt for simplicity and choose a default. --

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Raymond Hettinger added the comment: > There's also a somewhat arbitrary choice to be made here: > do we consider NaNs to be negative or positive? > That is, do we want NaNs to sort to the beginning of the > list, or the end? I had suggested putting NaNs at the beginning because that is

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Serhiy Storchaka added the comment: Maybe add two key functions for making NaN either the smallest or the largest number? min(1, NAN, key=nan_is_smallest) -> NAN max(1, NAN, key=nan_is_smallest) -> 1 sorted([1, NAN, 2], key=nan_is_smallest) -> [NAN, 1, 2] min(1, NAN, key=nan_is_largest) -> 1

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Mark Dickinson added the comment: > That is, do we want NaNs to sort to the beginning of the list, or the end? FWIW, NumPy chooses to sort NaNs to the end of the list: https://numpy.org/doc/stable/reference/generated/numpy.sort.html -- ___ Python

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Mark Dickinson added the comment: > We should consider biting the bullet and revising the default NaN sort order. If we went that route, I think we wouldn't need to consider payload or identity. We could just do: NaN < NaN -> False NaN < non-NaN -> True non-NaN <

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Raymond Hettinger added the comment: We should consider biting the bullet and revising the default NaN sort order. It has been a perpetual irritant. 1) Have NaNs always compare to less than any other float value. 2) When comparing two distinct NaNs, use the NaN payload and fall back to

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Serhiy Storchaka added the comment: The idea of math.ieee754_total_order looks interesting, but how would it work with min/max? In https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/minNum_maxNum_Removal_Demotion_v3.pdf there is a comparison of several standards and

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Steven D'Aprano added the comment: math.ieee754_total_order sounds good to me, but how would you get the minimum? Wikipedia doesn't have much on the 2019 revision to IEEE-754 except to say that the min/max rules have been overhauled again, but without giving much detail.

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Mark Dickinson added the comment: See also #11986, which this report is essentially a duplicate of. I think it may be time to implement `math.ieee754_total_order` (after suitable bikeshedding about the name), so that one can do sorted(my_list_of_floats, key=math.ieee754_total_order) and

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Dennis Sweeney added the comment: implantation --> implementation -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Dennis Sweeney added the comment: This is essentially the same issue, but with sorted(): https://bugs.python.org/issue36095 The trouble is that the implementation of min() is roughly equivalent to: iterable = iter(iterable) current_min = next(iterable) for x in iterable: if x <

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Joël Larose added the comment: The same problem occurs if the argument is a `list`. The same inconsistency happens depending on the position in the list that `nan` happens to be. >>> max([5, nan, 3, 0, 8, -10]) 8 >>> min([5, nan, 3, 0, 8, -10]) -10 >>> min([nan, 5, 3, 0, 8, -10]) nan >>>

[issue44370] Inconsistent results for min() and max() with math.nan as argument

Joël Larose added the comment: Forgot to mention the environment: Python version: 3.9.0 OS: Windows 10 I have not tested this on any other version of python. -- ___ Python tracker

[issue44370] Inconsistent results for min() and max() with math.nan as argument

New submission from Joël Larose : If `math.nan` is the first argument for either max() or min(), the result is always `nan`, regardless of the other values in the results. However, if `nan` is in any other position in the arguments list, the result is always what you would expect if `nan`