[issue11986] Min/max not symmetric in presence of NaN

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 =

[issue11986] Min/max not symmetric in presence of NaN

Alexander Belopolsky added the comment: On Sat, May 21, 2011 at 3:32 PM, Mark Dickinson wrote: .. > That might be viable (a math module function might also make sense here), > though it feels a bit YAGNI to me. I have to admit that it would be YAGNI for most of my code because it uses numpy f

[issue11986] Min/max not symmetric in presence of NaN

Mark Dickinson added the comment: > and it's dishonest to claim it is. This language was going too far, and I apologise for it. I think I need one of those 'wait 5 minutes before allowing you to post' controls. -- keywords: +gsoc ___ Python tracke

[issue11986] Min/max not symmetric in presence of NaN

Mark Dickinson added the comment: > This is just sophistry. If Python was more popular than C at the > time Prof. Kahan wrote this, he would write "in the syntax of Python." I doubt it. C has a standard that explicitly states that < must signal on comparison with NaNs. Python doesn't. Ale

[issue11986] Min/max not symmetric in presence of NaN

Alexander Belopolsky added the comment: On Sat, May 21, 2011 at 3:22 PM, Mark Dickinson wrote: > > Mark Dickinson added the comment: > >> Prof. Kahan states that nan < x must signal. > > Would that be the sentence that starts "In the syntax of C ..." ? This is just sophistry. If Python was

[issue11986] Min/max not symmetric in presence of NaN

Mark Dickinson added the comment: > keep naive implementation of builtin max() Agreed. > provide symmetric float.max such that nan.max(x) = x.max(nan) = x (nan > result would be a valid but less useful alternative.) That might be viable (a math module function might also make sense here), th

[issue11986] Min/max not symmetric in presence of NaN

Mark Dickinson added the comment: > Prof. Kahan states that nan < x must signal. Would that be the sentence that starts "In the syntax of C ..." ? -- ___ Python tracker ___ ___

[issue11986] Min/max not symmetric in presence of NaN

Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue11986] Min/max not symmetric in presence of NaN

Alexander Belopolsky added the comment: rhettinger> Your other tracker item correctly focused on the behavior of rhettinger> float('NaN') itself, You closed issue11949 as well, so it won't help. I disagree that this issue would be resolved by resolving issue11949. Defining max(nan, x) and na

[issue11986] Min/max not symmetric in presence of NaN

Raymond Hettinger added the comment: The report is invalid because min/max make no guarantees about values without a total ordering. Your other tracker item correctly focused on the behavior of float('NaN') itself, rather than on the behavior of everything else in the Python world that compa

[issue11986] Min/max not symmetric in presence of NaN

Alexander Belopolsky added the comment: On Tue, May 3, 2011 at 2:41 PM, Raymond Hettinger wrote: .. > Undefined ordering means just that. Means what? Compare float behavior to Decimal('1') >>> Decimal(1).max(Decimal('nan')) Decimal('1') >>> max(Decimal('1'), Decimal('nan')) Traceback (most r

[issue11986] Min/max not symmetric in presence of NaN

Raymond Hettinger added the comment: Undefined ordering means just that. -- nosy: +rhettinger resolution: -> invalid status: open -> closed ___ Python tracker ___ _

[issue11986] Min/max not symmetric in presence of NaN

Antoine Pitrou added the comment: Not specific to NaNs: >>> min({1}, {2}) {1} >>> min({2}, {1}) {2} -- nosy: +pitrou ___ Python tracker ___

[issue11986] Min/max not symmetric in presence of NaN

New submission from Alexander Belopolsky : >>> nan = float('nan') >>> min(nan, 5) nan >>> min(5, nan) 5 Good arguments can be made in favor of either result, but different value for min(x, y) depending on the order of arguments can hardly be justified. "In the face of ambiguity, refuse the tem