Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!news.glorb.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!spln!extra.newsguy.com!newsp.newsguy.com!not-for-mail From: Chris Torek Newsgroups: comp.lang.python Subject: Re: float("nan") in set or as key Date: 3 Jun 2011 17:52:24 GMT Organization: None of the Above Lines: 55 Message-ID: References: <4de75dd5$0$29983$c3e8da3$5496439d@news.astraweb.com> NNTP-Posting-Host: p4bea614e09e0e6682b2b88637b1e1bf421c3673cd33f7fd7.newsdawg.com X-Newsreader: trn 4.0-test76 (Apr 2, 2001) Originator: torek@elf.torek.net (Chris Torek) Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:6957 >On 2011-06-02, Nobody wrote: >> (I note that Python actually raises an exception for "0.0/0.0"). In article Grant Edwards wrote: >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. Indeed -- or at least, inconsistent. (Again I would not mind at all if Python had "raise exception on NaN-result" mode *as well as* "quietly make NaN", perhaps using signalling vs quiet NaN to tell them apart in most cases, plus some sort of floating-point context control, for instance.) >> 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? Mostly because for integers it's "too late" and there is no standard for it. For others, well: >>> import decimal >>> decimal.Decimal('nan') Decimal("NaN") >>> _ + 1 Decimal("NaN") >>> decimal.setcontext(decimal.ExtendedContext) >>> print decimal.Decimal(1) / 0 Infinity >>> [etc] (Note that you have to set the decimal context to one that does not produce a zero-divide exception, such as the pre-loaded decimal.ExtendedContext. On my one Python 2.7 system -- all the rest are earlier versions, with 2.5 the highest I can count on, and that only by upgrading it on the really old work systems -- I note that fractions.Fraction(0,0) raises a ZeroDivisionError, and there is no fractions.ExtendedContext or similar.) >> 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. This analogy perhaps works better than expected. Whenever I swap between Oz or NZ and the US-of-A, I have a brief mental clash that, if I am not careful, could result in various bad things. :-) -- In-Real-Life: Chris Torek, Wind River Systems Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: gmail (figure it out) http://web.torek.net/torek/index.html