Claude Pache wrote:
> `Math.sign` is expected to represent the mathematical sign
> function, which has a precise definition, see [1], [2].
> Please note that `+0` and `-0` are the same value as far as
> maths is concerned, and that value is neither positive nor
> negative. (Or both nonnegative and nonpositive, if you prefer.)

I don't think it's quite that cut and dry.  For one thing, the Wolfram resource you linked to states (at the very bottom):

    sgn(0) can also be interpreted as an unspecified point on the unit circle in the complex plane (Rich and Jeffrey 1996).

Since ES is (currently) limited to the Real numbers, that would make the only possible choices on the unit circle +1 and -1.  It wouldn't be such a leap to choose +1 for +0 and -1 for -0, given that IEEE/ES has both forms of 0.

Furthermore, +0 and -0 can have two different meanings.  They're used to represent the mathematical concept of 0 but they're also used to represent +ε and -ε respectively.  Since, sgn(+ε) = 1 and sgn(-ε) = -1, I think it would be a valid interpretation mathematically for `Math.sign(+0)` to be 1 and `Math.sign(-0)` to be -1.

At the very least, I think Oliver has a point in that it'd be very useful to have a sign function which would return 1 for +0 and -1 for -0.  I've needed this in the past.  If it shouldn't be `Math.sign`, perhaps there should be a `Number.sign` which would match the other use-case (one that I think would be more useful for meta-programming than what we have for `Math.sign`).

Nathan

Claude Pache wrote:
> `Math.sign` is expected to represent the mathematical sign
> function, which has a precise definition, see [1], [2].
> Please note that `+0` and `-0` are the same value as far as
> maths is concerned, and that value is neither positive nor
> negative. (Or both nonnegative and nonpositive, if you prefer.)

I don't think it's quite that cut and dry.  For one thing, the Wolfram resource you linked to states (at the very bottom):

> sgn(0) can also be interpreted as an unspecified point on the unit circle in the complex plane (Rich and Jeffrey 1996).

Since ES is (currently) limited to the Real numbers, that would make the only possible choices on the unit circle +1 and -1.  It wouldn't be such a leap to choose +1 for +0 and -1 for -0, given that IEEE/ES has both forms of 0.

Furthermore, +0 and -0 can have two different meanings.  They're used to represent the mathematical concept of 0 but they're also used to represent +ε and -ε respectively.  Since, sgn(+ε) = 1 and sgn(-ε) = -1, I think it would be a valid interpretation mathematically for `Math.sign(+0)` to be 1 and `Math.sign(-0)` to be -1.

At the very least, I think Oliver has a point in that it'd be very useful to have a sign function which would return 1 for +0 and -1 for -0.  I've needed this in the past.  If it shouldn't be `Math.sign`, perhaps there should be a `Number.sign` which would match the other use-case (one that I think would be more useful for meta-programming than what we have for `Math.sign`).