Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!novia!news-out.readnews.com!news-xxxfer.readnews.com!panix!not-for-mail From: Grant Edwards Newsgroups: comp.lang.python Subject: Re: float("nan") in set or as key Date: Mon, 6 Jun 2011 14:03:38 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 71 Message-ID: References: <94dkd3F7k4U1@mid.individual.net> <4de1e3e7$0$2195$742ec2ed@news.sonic.net> <4de22007$0$29996$c3e8da3$5496439d@news.astraweb.com> <4de2d746$0$29996$c3e8da3$5496439d@news.astraweb.com> <4de75dd5$0$29983$c3e8da3$5496439d@news.astraweb.com> NNTP-Posting-Host: dsl.comtrol.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: reader1.panix.com 1307369018 1612 64.122.56.22 (6 Jun 2011 14:03:38 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Mon, 6 Jun 2011 14:03:38 +0000 (UTC) User-Agent: slrn/pre0.9.9-102 (Linux) Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:7085 On 2011-06-03, Nobody wrote: >>> 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 think that you misunderstood. What I was saying here was that, if you > wanted exception-on-NaN behaviour from Python, the interpreter wouldn't > need to call isnan() on every value received from the FPU, but rely upon > NaN-propagation and only call it at places where a NaN might disappear > (e.g. comparisons). Ideed, I did misunderstand. I thought you were talking about a the value of reducing the number of isnan() tests in user application code. >>> I mean undefined, in the sense that 0/0 is undefined >> >> But 0.0/0.0 _is_ defined. It's NaN. ;) > > Mathematically, it's undefined. True, but we must be careful not to confuse math and scientific calculation using fixed-length binary floting point. >> 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. > > But then IEEE-754 considers integers and floats to be completely > different beasts, while Python makes some effort to maintain a > unified "numeric" interface. If you really want IEEE-754 > to-the-letter, that's undesirable, although I'd question the choice > of Python in such situations. Python's minor issues with IEEE-754 are far outweighed by advantages in other areas. :) >>> 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. > > That's what exceptions are for. NaNs probably save a huge amount of > effort in languages which lack exceptions, but that isn't applicable > to Python. How do you obtain using exceptions a behavior that's the same as with quiet NaNs? >>>> The correct answer to "nan == nan" is to raise an exception, >>>> because you have asked a question for which the answer is nether True >>>> nor False. >>> >>> Wrong. >> >> That's overstating it. It was an attempt to illustate the overstatement to which it was a reply. -- Grant Edwards grant.b.edwards Yow! You should all JUMP at UP AND DOWN for TWO HOURS gmail.com while I decide on a NEW CAREER!!