checking for identity before comparing built-in objects - python-ideas

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion checking for identity before comparing built-in objects
Received-SPF: pass (google.com: domain of python-ideas-bounces+python-ideas-garchive-35620=googlegroups....@python.org designates 2001:888:2000:d::a6 as permitted sender) client-ip=2001:888:2000:d::a6;
Date: Tue, 9 Oct 2012 15:16:16 +1100
From: Steven D'Aprano <st...@pearwood.info>
To: python-id...@python.org
Message-ID: <20121009041613.GG27445@ando>
References: <CAOVPiMhnBezrw3gusD1QmW8MawV1HDCQHiTbd2Z0_T1TLDa...@mail.gmail.com>
	<506D94EE.30...@pearwood.info>
	<CAP7h-xZBg-MbWtmWFSQ4HmSPjCO_+Av_f-ip6hrH8WBSPJv...@mail.gmail.com>
	<CAPTjJmrRENuYXMOjPzobY1Hjkr+Vmqq04Z4_JOr6=DCdP4-...@mail.gmail.com>
	<CAP7h-xb4WvNuDGayqe60GRGmV4Nk-nzcN1d=HLahHw-hkG7...@mail.gmail.com>
	<CAP7+vJ+G-0WXZRTgr5Y=T+OdaMWmGzgk1--UH8=zoBGLsia...@mail.gmail.com>
	<CAP7h-xaV3RaA2EW4+vWuU=L=2JjhnKBGqhHPhgnmf4VbgGm...@mail.gmail.com>
	<CAP7+vJLt_WNzS75S25kMgPjFMiKz5DFCj5V69ZeyiWsYs5A...@mail.gmail.com>
	<50723BE5.3060...@nedbatchelder.com>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <50723BE5.3060...@nedbatchelder.com>
User-Agent: Mutt/1.4.2.2i
Subject: Re: [Python-ideas] checking for identity before comparing built-in
	objects
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: python-ideas-bounces+python-ideas-garchive-35620=googlegroups....@python.org
Sender: "Python-ideas"
	<python-ideas-bounces+python-ideas-garchive-35620=googlegroups....@python.org>

On Sun, Oct 07, 2012 at 10:35:17PM -0400, Ned Batchelder wrote:

> A sentence in section 5.4 (Numeric Types) would help.  Something like, 
> "In accordance with the IEEE 754 standard, NaN's are not equal to any 
> value, even another NaN.  This is because NaN doesn't represent a 
> particular number, it represents an unknown result, and there is no way 
> to know if one unknown result is equal to another unknown result."

NANs don't quite mean "unknown result". If they did they would probably 
be called "MISSING" or "UNKNOWN" or "NA" (Not Available).

NANs represent a calculation result which is Not A Number. Hence the 
name :-) Since we're talking about the mathematical domain here, a 
numeric calculation that doesn't return a numeric result could be said 
to have no result at all: there is no real-valued x for which x**2 == 
-1, hence sqrt(-1) can return a NAN.

It certainly doesn't mean "well, there is an answer, but I don't know 
what it is". It means "I know that there is no answer".

Since neither sqrt(-1) nor sqrt(-2) exist in the reals, we cannot say 
that they are equal. If we did, we could prove anything:

sqrt(-1) = sqrt(-2)

Square both sides:

-1 = -2


I was not on the IEEE committee, so I can't speak for them, but my guess 
is that they reasoned that since there are an infinite number of "no 
result" not-a-number calculations, but only a finite number of NAN bit 
patterns available to be used for them, it isn't even safe to presume 
that two NANs with the same bit pattern are equal since they may have 
come from completely different calculations.

Of course this was before object identity was a relevant factor. As I've 
stated before, I think that having collections choose to optimize away 
equality tests using object identity is fine. If I need a tuple that 
honours NAN semantics, I can subclass tuple to get one. I shouldn't 
expect the default tuple behaviour to carry that cost.

By the way, NANs are awesome and don't get anywhere near enough respect. 
Here's a great idea from the D language:

http://www.drdobbs.com/cpp/nans-just-dont-get-no-respect/240005723



-- 
Steven
_______________________________________________
Python-ideas mailing list
Python-id...@python.org
http://mail.python.org/mailman/listinfo/python-ideas
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
