<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 29, 2013, at 8:54 PM, Oliver Hunt wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>As currently specified Math.sign has 5 different return values and, as far as i can tell, does not solve the problem I thought it was trying to address. That is the difficulty in distinguishing positive and negative numbers without having to manually do the divide -> ±Infinity cruft.<br><br>What is the rational for this behaviour?<br><br>Current Math.sign is a new, and unexpectedly complex API that doesn’t solve the common use case.<br></div></blockquote></div><br><div><br></div><div>It's just a matter of IEEE floats and consistency among the ESMath functions</div><div><br></div><div>Consistant handling of NaN requires that Math.sign(NaN) produces NaN.  So that means there needs to be at least four possible different return values from Math.sign. </div><div><br></div><div>The fifth possible returned value derives from the handling of +/- 0.  If you look at the other Math function you will see the all of them(except for Math.abs) that map 0 to 0 preserve the sign of the 0 input.</div><div><br></div><div>Note that Java uses an identical definition for its signum function: <a href="http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#signum(float)">http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#signum%28float%29</a> </div><div><br></div><div>Finally, +0 and -0 compare as equal using both == and ===, so the impact of propagating -0 is small in mormal usage.?</div><div><br></div><div>Allen</div></body></html>