[Python-ideas] checking for identity before comparing built-in objects

Joshua Landau joshua.landau.ws at gmail.com
Fri Oct 12 20:42:38 CEST 2012


On 11 October 2012 02:20, Steven D'Aprano <steve at pearwood.info> wrote:

> On 11/10/12 09:05, Joshua Landau wrote:
>
>  After re-re-reading this thread, it turns out one *(1)* post and two
>> *(2)* answers
>>
>> to that post have covered a topic very similar to the one I have raised.
>> All of the others, to my understanding, do not dwell over the fact
>> that *float("nan") is not float("nan")* .
>>
>
> That's no different from any other float.
>
> py> float('nan') is float('nan')
> False
> py> float('1.5') is float('1.5')
> False
>
> Floats are not interned or cached, although of course interning is
> implementation dependent and this is subject to change without notice.
>
> For that matter, it's true of *nearly all builtins* in Python. The
> exceptions being bool(obj) which returns one of two fixed instances,
> and int() and str(), where *some* but not all instances are cached.


>>> float(1.5) is float(1.5)
True
>>> float("1.5") is float("1.5")
False

Confusing re-use of identity strikes again. Can anyone care to explain what
causes this? I understand float(1.5) is likely to return the inputted
float, but that's as far as I can reason.

What I was saying, though, is that all other posts assumed equality between
two different NaNs should be the same as identity between a NaN and itself.
This is what I'm really asking about, I guess.


>  Response 1:
>> This implies that you want to differentiate between -0.0 and +0.0. That is
>> bad.
>>
>> My response:
>> Why would I want to do that?
>>
>
> If you are doing numeric work, you *should* differentiate between -0.0
> and 0.0. That's why the IEEE 754 standard mandates a -0.0.
>
> Both -0.0 and 0.0 compare equal, but they can be distinguished (although
> doing so is tricky in Python). The reason for distinguishing them is to
> distinguish between underflow to zero from positive or negative values.
> E.g. log(x) should return -infinity if x underflows from a positive value,
> and a NaN if x underflows from a negative.


Interesting.

Can you give me a more explicit example? When would you not *want* f(-0.0)
to always return the result of f(0.0)? [aka, for -0.0 to warp into 0.0 on
creation]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121012/6bccaa48/attachment.html>


More information about the Python-ideas mailing list