On Sun, 29 May 2011 17:55:22 -0700, Carl Banks wrote: > Floating point arithmetic evolved more or less on languages like Fortran > where things like exceptions were unheard of,
I'm afraid that you are completely mistaken. Fortran IV had support for floating point traps, which are "things like exceptions". That's as far back as 1966. I'd be shocked if earlier Fortrans didn't also have support for traps. http://www.bitsavers.org/pdf/ibm/7040/C28-6806-1_7040ftnMathSubrs.pdf The IEEE standard specifies that you should be able to control whether a calculation traps or returns a NAN. That's how Decimal does it, that's how Apple's (sadly long abandoned) SANE did it, and floats should do the same thing. Serious numeric languages like Fortran have supported traps long before exceptions were invented. > and defining NaN != NaN > was a bad trick they chose for testing against NaN for lack of a better > way. That's also completely wrong. The correct way to test for a NAN is with the IEEE-mandated function isnan(). The NAN != NAN trick is exactly that, a trick, used by programmers when their language or compiler doesn't support isnan(). Without support for isinf(), identifying an INF is just as hard as identifying an NAN, and yet their behaviour under equality is the complete opposite: >>> inf = float('inf') >>> inf == inf True > If exceptions had commonly existed in that environment there's no chance > they would have chosen that behavior; They did exist, and they did choose that behaviour. > comparison against NaN (or any > operation with NaN) would have signaled a floating point exception. > That is the correct way to handle exceptional conditions. > > The only reason to keep NaN's current behavior is to adhere to IEEE, And because the IEEE behaviour is far more useful than the misguided reliance on exceptions for things which are not exceptional. Before spreading any more misinformation about IEEE 754 and NANs, please learn something about it: http://grouper.ieee.org/groups/754/ http://www.cs.berkeley.edu/~wkahan/ieee754status/ieee754.ps I particularly draw your attention to the FAQ about NANs: http://grouper.ieee.org/groups/754/faq.html#exceptions [quote] The 754 model encourages robust programs. It is intended not only for numerical analysts but also for spreadsheet users, database systems, or even coffee pots. The propagation rules for NaNs and infinities allow inconsequential exceptions to vanish. Similarly, gradual underflow maintains error properties over a precision's range. When exceptional situations need attention, they can be examined immediately via traps or at a convenient time via status flags. Traps can be used to stop a program, but unrecoverable situations are extremely rare. Simply stopping a program is not an option for embedded systems or network agents. More often, traps log diagnostic information or substitute valid results. Flags offer both predictable control flow and speed. Their use requires the programmer be aware of exceptional conditions, but flag stickiness allows programmers to delay handling exceptional conditions until necessary. [end quote] -- Steven -- http://mail.python.org/mailman/listinfo/python-list
