Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Sat, May 14, 2011 at 3:08 PM, Raymond Hettinger <rep...@bugs.python.org> wrote: .. >> Note that the current behaviour does *not* violate IEEE 754, ... > > I agree with Mark. Do we really need a popular vote to determine what a published standard does or does not require? Section 7.2 of IEEE Std 754-2008 states: """ 7.2 Invalid operation The invalid operation exception is signaled if and only if there is no usefully definable result. In these cases the operands are invalid for the operation to be performed. … For operations producing no result in floating-point format, the operations that signal the invalid operation exception are: ... j) comparison by way of unordered-signaling predicates listed in Table 5.2, when the operands are unordered """ Python comparison operators. We can argue, of course about the proper mapping of IEEE 754 'INVALID' exception to the available Python construct. Arguably, a compliant language can ignore INVALID exceptions, issue a warning while returning result, or raise an exception and produce no result. In a post on Python ideas Mark argued that the ideal disposition of INVALID is a ValueError: """ IMO, the ideal (ignoring backwards compatibility) would be to have OverflowError / ZeroDivisionError / ValueError produced wherever IEEE754 says that overflow / divide-by-zero / invalid-operation should be signaled. """ http://mail.python.org/pipermail/python-ideas/2011-April/010106.html If IEEE 754 compliance is a stated goal in Python design, it would make very little sense to treat some cases of INVALID differently from others. If, however, IEEE 754 compliance is not a goal, we should consider what is the most useful behavior. On the mailing list, I posted a challenge - review your code that will work differently if nan ordering was disallowed and report whether that code does the right thing for all kinds of float (including nan, inf and signed 0). So far, I have not seen any responses to this. My own experiment with the Python library itself, have revealed a bug in the test suit. This matches my prior experience: naive numeric code usually produces nonsense results when nans are compared and careful numeric code makes an effort to avoid comparing nans. > Am closing this feature request which is both ill-conceived and likely to > cause more harm than good (possibly breaking code that currently does not > fail). > My primary goal in posting this patch was to support the discussion on python-ideas. The patch was not intended to be applied as is. At the minimum, I would need to make nan < nan issue a deprecation warning before turning it into an error. If this is not an appropriate use of the tracker - please propose an alternative. Posting a patch on the mailing list or outside of python.org seems to be a worse alternative. >> the discussion about cleaning up test_math >> (which I agree would be a good thing to do) >> should probably go into another issue. > > I agree. Why? The issue in test_math is small enough that it can be fixed without any discussion on the tracker. If someone would want to improve unittest based on this experience, this can indeed be handled in a separate issue. As long as the changes are limited to Lib/test, I don't see what a separate issue will bring other than extra work. ---------- _______________________________________ 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
