Re: Math.sign vs ±0

Allen Wirfs-Brock allen at
Wed Oct 30 08:47:12 PDT 2013

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: 

Finally, +0 and -0 compare as equal using both == and ===, so the impact of propagating -0 is small in mormal usage.?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list