Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #74197
| 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
Re: NaN comparisons - Call For Anecdotes "Anders J. Munch" <2014@jmunch.dk> - 2014-07-08 20:29 +0200
csiph-web