Alexander Belopolsky <belopol...@users.sourceforge.net> 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 nan < x
are two different issues. Quoting Kahan,
"""
Some familiar functions have yet to be defined for NaN . For instance max{x, y}
should deliver the same result as max{y, x} but almost no implementations do
that when x is NaN . There are good reasons to define max{NaN, 5} := max{5,
NaN} := 5 though many would disagree.
"""
-- Lecture Notes on the Status of IEEE Standard 754 for Binary
Floating-Point Arithmetic by Prof. W. Kahan
http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps
In the same lecture, Prof. Kahan states that nan < x must signal.
My ideal solution would be to make nan < x signal, keep naive implementation of
builtin max() and provide symmetric float.max such that nan.max(x) = x.max(nan)
= x (nan result would be a valid but less useful alternative.)
This will make float behavior closer to that of Decimal.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11986>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
