On 7/5/20 11:07 PM, Bruce Leban wrote: > > On Sun, Jul 5, 2020 at 5:49 PM Steven D'Aprano <st...@pearwood.info > <mailto:st...@pearwood.info>> wrote: > > On Sun, Jul 05, 2020 at 11:58:58AM -0700, Bruce Leban wrote: > > But using a NAN is not an unreasonable operation. > > > I didn't say that it was. A NaN is the /result/ of an operation that > cannot produce a number. I didn't intend the word "unreasonable" to > mean anything more than that, just as you don't have to be crazy to > use irrational numbers. > > > There is a perfectly > sensible interpretaion available for using NANs as bounds, and it is > one which is supported by the IEEE-754 recommended treatment > of minimum and maximum: missing values. > > > Supported, yes. Recommended, no. IEEE-754 specifies that the *minimum > *operation propagates NaNs while the /alternate /*minimumNumber > *operation drops NaNs. > > image.png > It should be noted, this is a change in the Standard that is just 1 year old. The previous version did define minimum as similar to the minimumNumber version. The change was made because it handled sNans differently (it defined minimum(sNan, x) to be qNaN) and that definition turned out to be non-associative (it mattered whether the sNan was the last number or not) so they needed to change it. In doing the change, the also apparently decided that the 'Nan-poisoning' version was to be preferred and the Nan ignoring to be just an alternate with the change of behavior from the previous version with sNan. > > --- Bruce
-- Richard Damon _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BNWP2GASN5VT7H2FWBUTG756JWGFZMLN/ Code of Conduct: http://python.org/psf/codeofconduct/
