Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Sat, May 14, 2011 at 2:50 PM, Mark Dickinson <rep...@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 <rep...@bugs.python.org>
> <http://bugs.python.org/issue11949>
> _______________________________________
>
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11949>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
