On Oct 29, 2013, at 8:54 PM, Oliver Hunt wrote:
> 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.
>
> What is the rational for this behaviour?
>
> Current Math.sign is a new, and unexpectedly complex API that doesn’t solve
> the common use case.
It's just a matter of IEEE floats and consistency among the ESMath functions
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.
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.
Note that Java uses an identical definition for its signum function:
http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#signum%28float%29
Finally, +0 and -0 compare as equal using both == and ===, so the impact of
propagating -0 is small in mormal usage.?
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
