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/