Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #74173
| Path | csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail |
|---|---|
| Return-Path | <ian.g.kelly@gmail.com> |
| X-Original-To | python-list@python.org |
| Delivered-To | python-list@mail.python.org |
| X-Spam-Status | OK 0.009 |
| X-Spam-Evidence | '*H*': 0.98; '*S*': 0.00; 'explicitly': 0.05; 'binary': 0.07; 'problem:': 0.07; 'upgraded': 0.07; 'anders': 0.09; 'defines': 0.09; 'sanity': 0.09; 'spelling': 0.09; 'python': 0.11; '2.7': 0.14; '"standard': 0.16; 'exponent': 0.16; 'nan': 0.16; 'nans': 0.16; 'reason.': 0.16; 'unequal': 0.16; 'wrote:': 0.18; 'bit': 0.19; "python's": 0.19; 'seems': 0.21; 'comparing': 0.24; 'fine': 0.24; 'question': 0.24; 'compare': 0.26; 'header:In- Reply-To:1': 0.27; 'am,': 0.29; 'message-id:@mail.gmail.com': 0.30; 'comparison': 0.31; "they'll": 0.31; 'stuff': 0.32; 'says': 0.33; 'worked': 0.33; 'equal': 0.35; 'no,': 0.35; 'requirement': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'should': 0.36; 'two': 0.37; 'expected': 0.38; 'to:addr:python- list': 0.38; 'skip:b 40': 0.39; 'to:addr:python.org': 0.39; 'changed': 0.39; 'ensure': 0.60; 'world.': 0.61; "you're": 0.61; "you'll": 0.62; 'provide': 0.64; 'between': 0.67; 'legal': 0.71; 'jul': 0.74; 'subject:For': 0.78; 'discovered': 0.83; 'everything,': 0.84; 'itself?': 0.84; 'regard.': 0.84 |
| DKIM-Signature | v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=SP9t6g/k2PVZJEsgqHKD8tsgL7ulqQ7Nxl2FwEP64mg=; b=F0TzVP7tzZVpzkKR00HC0DXb+5oS2eMiwcBHNKKFR3VQBmP2IlYtk8b+yJ5OSu7s/J EBS64LGIR+FGwfcx6HRq8kK3rMSTTRaabBicIlPJH0IMzjMU7joxziLtQtYychFxGllP gJcW0kP6mhc/NAX6w+vEiQ1a41W0hYNpl2z2ow1dQ38sZnCp1MnEv1abCSoUR2gKhUrv OsrBEY/yn0Kvqe2RWbWPG/9mD+KSgj0o3Lr1Zux+K0yCIRxkVEZ2XmsV6iy45+I2DE9V /Q3nZEdX0q93zRQkxTnb4AmMrbu3ABIHum08zkQUYWLXVmjnF1jZmGCzwmQpYTBM1N+5 90Vw== |
| X-Received | by 10.66.179.111 with SMTP id df15mr34304834pac.52.1404833067947; Tue, 08 Jul 2014 08:24:27 -0700 (PDT) |
| MIME-Version | 1.0 |
| In-Reply-To | <53BC05FB.4050707@jmunch.dk> |
| References | <53BC05FB.4050707@jmunch.dk> |
| From | Ian Kelly <ian.g.kelly@gmail.com> |
| Date | Tue, 8 Jul 2014 09:23:47 -0600 |
| Subject | Re: NaN comparisons - Call For Anecdotes |
| To | Python <python-list@python.org> |
| Content-Type | text/plain; charset=UTF-8 |
| X-BeenThere | python-list@python.org |
| X-Mailman-Version | 2.1.15 |
| Precedence | list |
| List-Id | General discussion list for the Python programming language <python-list.python.org> |
| List-Unsubscribe | <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe> |
| List-Archive | <http://mail.python.org/pipermail/python-list/> |
| List-Post | <mailto:python-list@python.org> |
| List-Help | <mailto:python-list-request@python.org?subject=help> |
| List-Subscribe | <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.11632.1404833077.18130.python-list@python.org> (permalink) |
| Lines | 37 |
| NNTP-Posting-Host | 2001:888:2000:d::a6 |
| X-Trace | 1404833077 news.xs4all.nl 2851 [2001:888:2000:d::a6]:36985 |
| X-Complaints-To | abuse@xs4all.nl |
| Xref | csiph.com comp.lang.python:74173 |
Show key headers only | View raw
On Tue, Jul 8, 2014 at 8:53 AM, Anders J. Munch <2014@jmunch.dk> wrote: > And that worked fine in my Python 2.4 apps. Then I upgraded to 2.7 > and it broke. Because 2.7 goes out of it's way to ensure that NaN's > don't compare equal to themselves. As far as I know nothing changed between 2.4 and 2.7 in this regard. Python has always had NaN compare unequal to everything, per the standard. > I discovered it when a sanity check told me that two functions, > to_binary and from_binary, weren't each other's inverse, as they were > intended to be. Apparently, > bitPattern==to_binary(from_binary(bitPattern)) wasn't true for this > particular value of bitPattern. Of course, the bit pattern in > question was the binary representation for a floating-point NaN. Okay, here's your problem: there isn't just one binary representation for NaN. The standard defines any value with all 1's in the exponent and a non-zero significand as NaN (a zero significand would instead be an infinity). Your bit comparison is going to have to be prepared to compare NaNs that don't have the same binary representation. By the way, there are also multiple binary representations for 0. If you compare them as floats, then they'll compare equal to one another, but if you're just comparing binary representations then you'll have issues there as well. > Now, all this bothers me. Not that I had to do some work to get stuff > to work in an imperfect world. No, what bothers me is that this > behaviour was explicitly and deliberately put in for no good reason. > The only reason is "standard says so". Not that there's any legal > requirement for Python to follow the IEEE-754 standard. Or for that > matter, for Python's spelling of IEEE-754 comparisons to be "==". Following the standard isn't a good reason itself? It seems to me that one should be expected to provide a strong justification for *deviating* from the standard, not for following it.
Back to comp.lang.python | Previous | Next | Find similar | Unroll thread
Re: NaN comparisons - Call For Anecdotes Ian Kelly <ian.g.kelly@gmail.com> - 2014-07-08 09:23 -0600
csiph-web