[Python-ideas] checking for identity before comparing built-in objects
python at mrabarnett.plus.com
Fri Oct 12 21:19:48 CEST 2012
On 2012-10-12 19:42, Joshua Landau wrote:
> On 11 October 2012 02:20, Steven D'Aprano <steve at pearwood.info
> <mailto: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
> 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')
> py> float('1.5') is float('1.5')
> 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)
It re-uses an immutable literal:
>>> 1.5 is 1.5
>>> "1.5" is "1.5"
and 'float' returns its argument if it's already a float:
>>> float(1.5) is 1.5
>>> float(1.5) is float(1.5)
But apart from that, when a new object is created, it doesn't check
whether it's identical to another, except in certain cases such as ints
in a limited range:
>>> float("1.5") is float("1.5")
>>> float("1.5") is 1.5
>>> int("1") is 1
And it's an implementation-specific behaviour.
> >>> float("1.5") is float("1.5")
> 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
> 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
> and a NaN if x underflows from a negative.
> 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]
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas