Showing content from http://mail.python.org/pipermail/python-dev/attachments/20110427/c2f16595/attachment.html below:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#330033" bgcolor="#ffffff">
On 4/27/2011 2:04 PM, Mark Dickinson wrote:
<blockquote
cite="mid:BANLkTik6Fr0e=5PLNTu4x=CT+v12tt3Tsg@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Apr 27, 2011 at 10:37 AM, Hrvoje Niksic <a class="moz-txt-link-rfc2396E" href="mailto:hrvoje.niksic@avl.com"><hrvoje.niksic@avl.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The other day I was surprised to learn this:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">nan = float('nan')
nan == nan
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">False
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">[nan] == [nan]
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">True          # also True in tuples, dicts, etc.
</pre>
</blockquote>
<pre wrap="">
That one surprises me a bit too: I knew we were using
identity-then-equality checks for containment (nan in [nan]), but I
hadn't realised identity-then-equality was also used for the
item-by-item comparisons when comparing two lists. It's defensible,
though: [nan] == [nan] should presumably produce the same result as
{nan} == {nan}, and the latter is a test that's arguably based on
containment (for sets s and t, s == t if each element of s is in t,
and vice versa).
I don't think any of this should change. It seems to me that we've
currently got something approaching the best approximation to
consistency and sanity achievable, given the fundamental
incompatibility of (1) nan breaking reflexivity of equality and (2)
containment being based on equality. That incompatibility is bound to
create inconsistencies somewhere along the line.
Declaring that 'nan == nan' should be True seems attractive in theory,
but I agree that it doesn't really seem like a realistic option in
terms of backwards compatibility and compatibility with other
mainstream languages.
</pre>
</blockquote>
<br>
I think it should change. Inserting a NaN, even the same instance
of NaN into a list shouldn't suddenly make it compare equal to
itself, especially since the docs (section 5.9. Comparisons) say:<br>
<ul>
<li>
<p class="first">Tuples and lists are compared lexicographically
using comparison of
corresponding elements. This means that to compare equal, each
element must
compare equal and the two sequences must be of the same type
and have the same
length.</p>
<p>If not equal, the sequences are ordered the same as their
first differing
elements. For example, <tt class="docutils literal"><span
class="pre">[1,2,x]</span> <span class="pre"><=</span>
<span class="pre">[1,2,y]</span></tt> has the same value as
<tt class="docutils literal"><span class="pre">x</span> <span
class="pre"><=</span> <span class="pre">y</span></tt>.
If the corresponding element does not exist, the shorter
sequence is ordered first (for example, <tt class="docutils
literal"><span class="pre">[1,2]</span> <span class="pre"><</span>
<span class="pre">[1,2,3]</span></tt>).</p>
</li>
</ul>
The principle of least surprise, says that if two unequal items are
inserted into otherwise equal lists, the lists should be unequal.Â
NaN is unequal to itself.<br>
<br>
</body>
</html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4