On 2011-06-02, Nobody <nob...@nowhere.com> wrote: > On Thu, 02 Jun 2011 09:54:30 +0000, Steven D'Aprano wrote: > >>> Exceptions allow you to write more natural code by ignoring the >>> awkward cases. E.g. writing "x * y + z" rather than first determining >>> whether "x * y" is even defined then using a conditional. >> >> You've quoted me out of context. I wasn't asking for justification >> for exceptions in general. There's no doubt that they're useful. We >> were specifically talking about NAN == NAN raising an exception >> rather than returning False. > > It's arguable that NaN itself simply shouldn't exist in Python; if > the FPU ever generates a NaN, Python should raise an exception at > that point.
Sorry, I just don't "get" that argument. I depend on compliance with IEEE-754, and I find the current NaN behavior very useful, and labor-saving. > But given that NaNs propagate in almost the same manner as > exceptions, you could "optimise" this by treating a NaN as a > special-case implementation of exceptions, and turn it into a real > exception at the point where you can no longer use a NaN (e.g. when > using a comparison operator). > > This would produce the same end result as raising an exception > immediately, but would reduce the number of isnan() tests. I've never found the number of isnan() checks in my code to be an issue -- there just arent that many of them, and when they are there, it provides an easy to read and easy to maintain way to handle things. > I mean undefined, in the sense that 0/0 is undefined But 0.0/0.0 _is_ defined. It's NaN. ;) > (I note that Python actually raises an exception for "0.0/0.0"). IMHO, that's a bug. IEEE-754 states explicit that 0.0/0.0 is NaN. Pythons claims it implements IEEE-754. Python got it wrong. > Also, note that the "convenience" of NaN (e.g. not propagating from > the untaken branch of a conditional) is only available for > floating-point types. If it's such a good idea, why don't we have it > for other types? > The definition is entirely arbitrary. I don't agree, but even if was entirely arbitrary, that doesn't make the decision meaningless. IEEE-754 says it's True, and standards compliance is valuable. Each country's decision to drive on the right/left side of the road is entire arbitrary, but once decided there's a huge benefit to everybody following the rule. > You could just as easily define that (NaN == NaN) is True. You could > just as easily define that "1 + NaN" is 27. I don't think that would be "just as easy" to use. > Actually, "NaN == NaN" makes more sense than "NaN != NaN", as the > former upholds the equivalence axioms You seem to be talking about reals. We're talking about floats. > If you're going to argue that "NaN == NaN" should be False on the > basis that the values are sentinels for unrepresentable values (which > may be *different* unrepresentable values), it follows that "NaN != > NaN" should also be False for the same reason. Mostly I just want Python to follow the IEEE-754 standard [which I happen to find to be very well thought out and almost always behaves in a practical, useful manner]. > If you want to argue that "NaN == NaN" should be False, then do so. > Simply asserting that it should be False won't suffice (nor will > citing the IEEE FP standard *unless* you're arguing that "because the > standard says so" is the only reason required). For those of us who have to accomplish real work and interface with real devices "because the standard says so" is actaully a darned good reason. Years of experience has also shown to me that it's a very practical decision. > If anything, it has proven to be a major nuisance. It takes a lot of > effort to create (or even specify) code which does the right thing in > the presence of NaNs. That's not been my experience. NaNs save a _huge_ amount of effort compared to having to pass value+status info around throughout complex caclulations. > I'm not aware that they made any conclusions about Python. They made some very informed (and IMO valid) conclusions about scientific computing using binary floating point arithmatic. Those conclusions apply largly to Python. -- Grant -- http://mail.python.org/mailman/listinfo/python-list
