On 11 October 2012 02:20, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<div>False</div></div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Response 1:<br>
This implies that you want to differentiate between -0.0 and +0.0. That is<br>
bad.<br>
<br>
My response:<br>
Why would I want to do that?<br>
</blockquote>
<br></div>
If you are doing numeric work, you *should* differentiate between -0.0<br>
and 0.0. That's why the IEEE 754 standard mandates a -0.0.<br>
<br>
Both -0.0 and 0.0 compare equal, but they can be distinguished (although<br>
doing so is tricky in Python). The reason for distinguishing them is to<br>
distinguish between underflow to zero from positive or negative values.<br>
E.g. log(x) should return -infinity if x underflows from a positive value,<br>
and a NaN if x underflows from a negative.</blockquote><div><br></div><div>Interesting. </div></div><br><div>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]</div>