[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
More information about the Python-ideas mailing list
Fri Oct 12 20:42:38 CEST 2012
- Previous message: [Python-ideas] checking for identity before comparing built-in objects
- Next message: [Python-ideas] checking for identity before comparing built-in objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message: [Python-ideas] checking for identity before comparing built-in objects
- Next message: [Python-ideas] checking for identity before comparing built-in objects
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-ideas mailing list