Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #74197

Re: NaN comparisons - Call For Anecdotes

Path csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path <2014@jmunch.dk>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.018
X-Spam-Evidence '*H*': 0.96; '*S*': 0.00; 'example:': 0.03; 'float': 0.07; 'anders': 0.09; 'keys,': 0.09; 'objects,': 0.09; 'returns,': 0.09; 'way:': 0.09; 'cc:addr:python-list': 0.11; 'def': 0.12; '*should*': 0.16; 'equivalence': 0.16; 'nan': 0.16; 'nans': 0.16; 'rounding': 0.16; 'tuples,': 0.16; 'wrote:': 0.18; 'module': 0.19; '>>>': 0.22; 'import': 0.22; 'cc:addr:python.org': 0.22; 'header :User-Agent:1': 0.23; 'cc:2**0': 0.24; 'compare': 0.26; 'equivalent': 0.26; 'header:In-Reply-To:1': 0.27; 'chris': 0.29; "doesn't": 0.30; 'you?': 0.31; '"",': 0.31; 'assumes': 0.31; 'keyerror:': 0.31; 'received:dk': 0.31; 'struct': 0.31; 'up:': 0.31; 'file': 0.32; 'class': 0.32; '(most': 0.33; "can't": 0.35; 'except': 0.35; 'equal': 0.35; 'but': 0.35; 'false': 0.36; 'doing': 0.36; 'charset:us-ascii': 0.36; 'should': 0.36; 'list': 0.37; 'generic': 0.38; 'anything': 0.39; 'recent': 0.39; 'expect': 0.39; 'skip:p 20': 0.39; 'above,': 0.60; 'header:Return-path:1': 0.60; 'most': 0.60; 'mentioned': 0.61; 'new': 0.61; 'simple': 0.61; "you're": 0.61; 'such': 0.63; 'to:addr:gmail.com': 0.65; 'serial': 0.72; 'special': 0.74; 'subject:For': 0.78; 'algorithm,': 0.84; 'sets,': 0.84; 'sound.': 0.84; 'imagine': 0.93
Date Tue, 08 Jul 2014 20:29:52 +0200
From "Anders J. Munch" <2014@jmunch.dk>
Organization .
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version 1.0
To Chris Angelico <rosuav@gmail.com>
Subject Re: NaN comparisons - Call For Anecdotes
References <53BC05FB.4050707@jmunch.dk> <CAPTjJmoD5gfwpcW_45bzO846gFYMGH6+9TYowSea0SPpe-o__A@mail.gmail.com>
In-Reply-To <CAPTjJmoD5gfwpcW_45bzO846gFYMGH6+9TYowSea0SPpe-o__A@mail.gmail.com>
Content-Type text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding 7bit
Cc "python-list@python.org" <python-list@python.org>
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.11649.1404844195.18130.python-list@python.org> (permalink)
Lines 57
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1404844195 news.xs4all.nl 2934 [2001:888:2000:d::a6]:33241
X-Complaints-To abuse@xs4all.nl
Xref csiph.com comp.lang.python:74197

Show key headers only | View raw


Chris Angelico wrote:
>
> Why *should* all NaNs be equal to each other? You said on the other
> list that NaN==NaN was equivalent to (2+2)==(1+3), but that assumes
> that NaN is a single "thing".

I don't actually care if all NaN bitpatterns are in the same equivalence group 
or if each bitpattern is its own equivalence group. I just want the == 
equivalence relation to be sound.

> For hash keys, float object identity will successfully look them up:

Except you can't expect to rely on object identity in most interesting cases.

 >>> x = float('nan')
 >>> import struct
 >>> y = struct.unpack('<f', struct.pack('<f', x))[0]
 >>> d[x] = "found"
 >>> d[y]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: nan

and also:

 >>> def f(): return float('inf')/float('inf')
 >>> f() == f()
False
 >>> f() is f()
False

> But any time you compare floats for equality, you *already* have to
> understand what you're doing (because of rounding and such), so I
> don't see why the special case on NaN is significant, unless as
> mentioned above, you want all NaNs to be equal, which doesn't make
> sense.
Let me conjure up a simple example:

| class Monitor(Thread):
| def run(self):
| old = self.get_current_value()
| while not self.Terminated:
| new = self.get_current_value()
| if new != old:
| print(time.asctime(), "changed to", new)
| old = new
| time.sleep(1)

This is a completely generic change detection algorithm, and not a 
"floating-point algorithm" in any way: It will work on strings, lists, sets, 
anything that get_current_value returns, including non-NaN floats. You don't 
need to know anything about floating-point representation to write or use such 
an algorithm, why should you? It works on tuples, sets, lists, serial port 
handles, module objects, pretty much anything you can imagine -- except NaN floats.

regards, Anders

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

Re: NaN comparisons - Call For Anecdotes "Anders J. Munch" <2014@jmunch.dk> - 2014-07-08 20:29 +0200

csiph-web