On Sun, Oct 30, 2016 at 06:26:13AM -0700, David Mertz wrote:
> NaN's *usually* propagate. The NaN domain isn't actually closed under IEEE
> 754.
[...]
> >>> min(1, nan)
> 1
>
> The last one isn't really mandated by IEEE 754, and is weird when you
> consider `min(nan, 1)`.
Python's min() and max() don't treat NANs correctly according to IEEE
754. The 2008 revision to the standard says that:
min(x, NaN) = min(NaN, x) = x
max(x, NaN) = max(NaN, x) = x
https://en.wikipedia.org/wiki/IEEE_754_revision#min_and_max
Professor Kahan, one of the IEEE 745 committee members, writes:
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.
Page 9, https://people.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
I believe that the standard does allow implementations to define a
second pair of functions that implement "NAN poisoning", that is, they
return NAN when given a NAN argument.
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
