Author belopolsky
Recipients alex, belopolsky, daniel.urban, mark.dickinson, rhettinger
Date 2011-05-16.17:26:38
SpamBayes Score 5.28603e-11
Marked as misclassified No
Message-id <BANLkTi=f-Y5kVmuxHqwxqbxrfuBV5yMSFA@mail.gmail.com>
In-reply-to <1305399033.28.0.945166541094.issue11949@psf.upfronthosting.co.za>
Content
On Sat, May 14, 2011 at 2:50 PM, Mark Dickinson <report@bugs.python.org> wrote:
..
> On the issue itself, I'm -1 on making comparisons with float('nan') raise: I don't see that there's a real problem here that needs solving.
>

I probably should have changed the title of this issue after making an
alternative proposal to make INVALID operations produce a warning:

http://mail.python.org/pipermail/python-ideas/2011-April/010101.html

For the case of nan ordering, this idea seemed to receive support on
the mailing list:

http://mail.python.org/pipermail/python-ideas/2011-April/010102.html
http://mail.python.org/pipermail/python-ideas/2011-April/010103.html
http://mail.python.org/pipermail/python-ideas/2011-April/010104.html

> Note that the current behaviour does *not* violate IEEE 754, since there's nothing anywhere
> in IEEE 754 that says that Python's < operation should raise for comparisons involving NaNs:
>  all that's said is that a conforming language should provide a number of comparison operations
> (without specifying how those operation should be spelt in the language in question), including
> both a < operation that's quiet (returning a false value for comparison with NaNs) and a <
> operation that signals on comparison with NaN.  There's nothing to indicate definitively which of
>  these two operations '<' should bind to in a language.
>

Yes, IEEE 754, provides little guidance to language designers, but why
would anyone want to treat
ordering of floats differently from ordering of decimals?

Traceback (most recent call last):
  ..
decimal.InvalidOperation: comparison involving NaN

> It *is* true that C chooses to bind '<' to the signalling version, but that doesn't automatically mean that we should do the same in Python.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue11949>
> _______________________________________
>
History
Date User Action Args
2011-05-16 17:26:39belopolskysetrecipients: + belopolsky, rhettinger, mark.dickinson, alex, daniel.urban
2011-05-16 17:26:38belopolskylinkissue11949 messages
2011-05-16 17:26:38belopolskycreate